Skip to content

Teams and research groups

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

Tensor Cortex Studio is under active development. The public beta is available to download from the website as of 22 September 2026. It starts with a strong local workflow for one technical builder. Team registries, shared review, roles, and audit remain later directions while the desktop project stays authoritative.

Source reviewed:

Current boundary

First target
Individual local workflow
Team features
Planned after local product evidence
Shared workflows
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 resources it used 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 / Collaborate deliberately

Share evidence without changing the project contract.

The planned collaboration model keeps experiment identity, revisions, evaluation results, and known limits stable between reviewers.

One product direction. Four explicitly different stages.

Architecture intent is not availability. Each collaboration mode must earn its own compatibility, security, and recovery 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.

Team review

Future collaboration layer

Shared registries, review roles, 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 impact, 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.