How it works
Every AutoTrainer request belongs to a task. Each task moves through three stages:1
Collecting
Requests route to the teacher model. Each successful teacher response is recorded as a training sample and counts toward your
minSamples target.2
Training
When
minSamples successful samples have accumulated (and autoTrain is enabled), the platform builds training and eval datasets from them and trains a distilled model on a pre-configured recipe. Your requests keep serving from the teacher in the meantime.3
Live
With
autoDeploy enabled, the trained model is deployed to a dedicated GPU, smoke-tested, and your traffic cuts over automatically — no code change required.📍 TODO:MEDIA
Lifecycle diagram: collecting → training → live, showing traffic on the teacher model until the distilled model takes over.
AutoTrainer never breaks serving. If anything fails — training, deployment, or routing — requests fall back to the teacher model and keep working.
Quickstart
The fastest way to use AutoTrainer iscreateAutoTrainClient from @inference/sdk, which scopes a task, teacher model, system prompt, and optional output schema into a single typed client.
1
Install the SDK
2
Create an AutoTrainer client
3
Call it like any other model
minSamples successful calls are served by the teacher model. After that, the platform trains and deploys the distilled model, and this exact call starts returning its responses instead.schema for free-form text tasks — run() then resolves to the raw response string.
Use the API directly
AutoTrainer works with any OpenAI-compatible client. Set the requestmodel to "auto-train" and pass the configuration as headers. The model value is only a marker — the teacher or the distilled model is chosen server-side.
All four x-inference-* configuration headers are required on direct API calls (the SDK fills in defaults for you).
Configuration reference
A few things to know when choosing values:
teacherModel— pick the model that already does the task well; the distilled model can only be as good as the samples the teacher produces. Models hosted on Inference.net are called directly by identifier (e.g.glm-5.2) with just your Inference API key. Provider models (OpenAI, Anthropic, etc.) also work, with the same provider headers as any gateway request.minSamples— set it high enough to cover the diversity of your real inputs. More diverse samples produce a better distilled model; a few hundred is a reasonable starting point for most tasks. Only successful teacher responses count toward the target — errors and refused requests are excluded.autoTrain/autoDeploy— independent gates.autoTrain: truewithautoDeploy: falsetrains a model but keeps serving from the teacher, which is useful when you want to review the trained model before switching traffic.
minSamples, autoTrain, and autoDeploy at any time — the latest values on incoming requests win.
Keep the task identity stable
The combination of task, system prompt, output schema, and teacher model identifies what AutoTrainer is distilling. Keep all four stable so samples accumulate toward the same model. Changing the prompt, schema, or teacher starts a new identity, and a task serves at most one distilled model at a time:- The new identity collects samples from scratch while its requests are served by the teacher. The previous model keeps serving requests that still use the old prompt or schema.
- When the replacement finishes training, the task’s deployment is swapped to the new model. The task briefly serves from the teacher during the swap (typically a few minutes), then traffic cuts over.
- Each retrain is recorded as a new version of the same deployment, so the version history is the task’s retrain audit trail.
- Reverting to a previously used prompt or schema does not resurrect its old model — a retired identity routes to the teacher permanently.
Structured output
Pass a Zod schema tocreateAutoTrainClient (as in the quickstart) and run() returns parsed, typed output. Under the hood the SDK sends an OpenAI structured-outputs response_format, and the schema becomes part of the task identity.
When calling the API directly:
- Use
response_formatwith typejson_schemaif you want structured output. Thejson_objecttype is not supported for AutoTrainer requests. - Every AutoTrainer request must include a
system(ordeveloper) message. - Requests with and without a schema are separate identities — don’t mix them within a task.
Monitor progress
Open the task in the dashboard and select the Auto-training tab to see samples collected toward the target, the train and deploy flags, and links to the resulting training job, model, and deployment as they’re created.📍 TODO:MEDIA
Screenshot of the task’s Auto-training tab in the dashboard.
Billing
There is no separate AutoTrainer fee — you pay for the pieces it orchestrates:- Teacher requests bill like any other inference through the gateway.
- The training run bills like a manual training run.
- The deployment bills like a dedicated deployment. Retrains reuse the task’s existing deployment rather than adding a new one.
Next steps
Tasks
How task tagging groups requests for metrics, evals, and training.
Manage deployments
Monitor, version, and scale the deployment serving your distilled model.