Skip to content

Teams and research groups

A shared experiment language, from one Mac to a team.

Tensor Cortex Studio is under active development, and no public application build is available today. It starts with a strong local workflow for one technical builder. Team registries, shared compute, BYOC, roles, budgets, and audit come later—without turning the desktop project into a thin client for a mandatory cloud platform.

Source reviewed:

Current boundary

First target
Individual local workflow
Team features
Planned after local product evidence
Cloud and BYOC
Not currently available

Make experiments comparable before making infrastructure shared.

A common project contract lets a founder, engineer, or research group review what changed, what improved, what regressed, and what it cost across hardware and trainer choices.

01 / Reproduce

Carry the whole experiment, not just a checkpoint.

Dataset and model revisions, recipe, environment, eval suite, hardware measurements, and known limitations travel together.

02 / Compare

Review candidates against the same baseline.

Task metrics, protected holdouts, regressions, latency, memory, and package readiness stay attached to the decision.

03 / Scale deliberately

Add local or cloud compute without changing the project.

The planned compute fabric keeps the experiment identity stable across one Mac, trusted Macs, managed GPU jobs, and supported BYOC accounts.

One product direction. Four explicitly different stages.

Architecture intent is not availability. Each compute and collaboration mode must earn its own compatibility, security, recovery, and cost evidence.

Local Studio

First product target

Apple Silicon, text models, MLX, SFT and LoRA, dataset health, baseline eval, comparison, recovery, and portable export. No public build is available yet.

Multi-Mac

Planned local extension

Trusted local workers and explicit pairing are planned after the single-Mac workflow is stable and measurable.

Tensor Cortex Cloud

Planned managed compute

Future jobs are intended to expose region, estimated duration and cost, hard budgets, checkpoints, recovery, and provider identity before submission.

BYOC and teams

Future orchestration layer

Provider accounts, shared registries, roles, budgets, and audit are later capabilities, not promises of current service availability.

Start with one task whose success can be measured.

The best early Studio use case is narrow enough to evaluate automatically and important enough to justify a custom model.

  1. Choose the taskStructured extraction, classification, tool selection, format adaptation, or another bounded outcome.
  2. Define the evalAgree task success, format validity, failure cost, holdout boundary, latency, and memory targets before training.
  3. Prepare the datasetInspect schema, duplicates, contamination, class balance, provenance, license, and target-device constraints.
  4. Run and decideCompare baseline and candidate, inspect regressions, then package or reject the experiment with written evidence.

Bring one measurable model problem.

Tell us the task, data shape, Apple Silicon hardware, target model size, and current bottleneck. That signal helps shape the supported first-release matrix.