Skip to documentation

Local workflow

From your first dataset to an adapter you can use.

A practical guide to the current development build, with the same seven stages you see in Studio.

Status: development-build guide; no public app download yet

Reviewed:

1. Project — keep the experiment together

Create or open a local project. Its saved workspace, dataset revision, model identity, settings and results belong to that project. The local workflow requires no Tensor Cortex account.

This guide describes implemented development behavior, not a public release. Read the support and compatibility boundary before choosing hardware or models.

2. Data — prepare three separate splits

Prepare a folder containing UTF-8 train.jsonl, valid.jsonl and test.jsonl. Each line must be one complete JSON object. Do not wrap the file in an array or add commas between lines. Use distinct, representative examples in each split: training learns from train; validation informs training; test provides the held-out baseline and candidate comparison.

Prompt and answer

{"prompt":"Return the invoice total: 120.00","answer":"120.00"}

The expected answer is a string, including when it contains a serialized JSON answer.

Native conversations

{"messages":[{"role":"user","content":"Return the invoice total: 48.50"},{"role":"assistant","content":"48.50"}]}

Evaluation conversations end with the expected assistant answer, which is withheld from generation input. The selected model's native template must support the record's fields and options. Raw text is also available for full-sequence training, but evaluation still needs an input and expected answer. See formats and token budgets.

These examples demonstrate syntax only; they are not a useful training dataset. Use representative records you are entitled to use. In Data, View Format & Example opens offline guidance. Preview Records shows up to three records per split; display text can be shortened without changing the source. Preview content is temporary and stays on the Mac.

Run Inspect Data for full inspection and an immutable revision. Previewing a few records is not validation. Resolve the reported issues before continuing.

3. Baseline — choose a model and measure it first

Choose from the model list, inspect a public Hugging Face repository, or select a compatible local MLX model folder. The sequence is Choose → Inspect → Download if needed → Test Compatibility → Use This Model. Metadata inspection does not download weights; a download needs separate resource confirmation. Local models and the compatibility test can work offline.

You can close the model panel while its operation continues, then return through View Model Progress or Review Model. Work remains owned by its originating project. The small compatibility test is not proof of task quality or sufficient memory for a full training run.

Record the unchanged model's baseline on the held-out test split. Input and response token budgets are shared with candidate evaluation. Changing a setting must respect the selected model's declared context and your memory capacity.

4. Recipe — review and apply bounded settings

The first beta uses supervised fine-tuning with LoRA through MLX. Guided and Expert settings do not enable distillation, preference optimization or full-model training.

Review the training sequence budget and other exposed settings. Recipe and evaluation editors use Apply and Cancel, show the expected readiness impact before application, and reject invalid or stale changes. Editing settings without applying them does not invalidate evidence; applying relevant changes can require fresh workflow results. Historical files are preserved.

5. Train — follow progress and recover deliberately

Start the local run after its prerequisites are ready. Studio shows measured stages, iteration counts and metrics; totals or remaining-time estimates appear only when supported by available information. Switching projects does not transfer an operation to the new project.

Use the offered cancellation or recovery actions. Resume is available only when the saved run and artifacts support it. One operation runs per project; simultaneous training in several projects has no public memory or support guarantee. See troubleshooting for interruption and memory guidance.

6. Compare — read the answers behind the score

Compare baseline and candidate using the same evaluation context. Review Example Answers displays the expected answer beside baseline and after-training answers, with Previous and Next navigation. Original model responses are available separately where recorded.

Matches expected means exact equality under the evaluator's normalization, not a general judgment of usefulness, reasoning or tool behavior. JSON and reasoning wrappers may be normalized; inspect the original response when that distinction matters.

Example review reads existing local results without running generation or training. It requires the project's corresponding prediction files; imported evaluation summaries alone cannot supply the answers. Visible text may be shortened and is cleared when you leave the section; the evidence files remain intact.

Comparison does not automatically move you to Export. Choose Continue to Export when ready. Export eligibility checks workflow prerequisites, not a minimum quality gain or an automatic regression threshold. You decide whether the result is suitable for use.

7. Export — preserve the adapter and its evidence

Export a content-addressed LoRA adapter package after completing the required run, dataset revision and comparison. New packages include adapter weights, configuration, evaluation summary, source identities, provenance and a hash-verified USAGE.md.

The package does not include the base model, dataset, Python runtime, Studio application or every individual answer. It is not a fused model or a GGUF/Ollama export. Keep the original project and evaluation files if you need to reproduce the comparison.

Use your exported adapter

  1. Keep the package folder intact. Follow its USAGE.md for verification and setup. Hash verification detects changes; it does not establish publisher trust or usage rights.
  2. Obtain the exact base model separately. Match package.json → provenance → model_identity: the Hugging Face revision or local content hash matters. A newer revision or different quantization is not interchangeable.
  3. Use a separate compatible Python/MLX-LM environment on Apple Silicon. The exported guide records the reference setup. Installing dependencies or downloading a model requires internet access and storage; do not modify Studio's bundled runtime.
  4. Load the local base model with the package's adapter/ folder. Review the source and component licenses.
python -m mlx_lm generate \
  --model '/absolute/path/to/exact-base-model' \
  --adapter-path '/absolute/path/to/package/adapter' \
  --prompt 'Your prompt' --max-tokens 128 --temp 0

Replace both paths. This is an MLX-LM command, not the Studio CLI. The example response budget of 128 is not a product limit. Native templates, reasoning and tool options must match the selected model and task. Nothing runs from this page.

A new prompt is not a reproduction of the recorded evaluation. Preserve the exact model, original dataset, project settings, template options and baseline/candidate evidence for a like-for-like comparison.

Return to projects and review training history

Recent Projects reopens a closed project's saved workspace. Removing a shortcut does not delete its files or results. Multiple open projects retain their own state.

Training History lists saved attempts, including stopped and failed runs. Reviewing history does not replace the active model, comparison or run. States are saved snapshots, not live process checks; refresh after active work finishes. Custom CLI run locations remain available in Finder.