Changelog

The platform now has three task types: question-answering, chat-completion and chat-completion-agentic. The classification, tool-calling-closed-book and multi-turn-tool-calling-closed-book tasks are gone, and a config that names one of them is rejected with the replacement to use.

The chat-completion tasks are a more flexible version of tool-calling, and mutators support all features of the standalone classification tasks.

Classification is question answering whose answer is the label. Put the labels and their definitions in the task description and add one mutator with a value per label, so the synthetic data covers every label. Scores come from binary, the exact match on the label.

Tool calling is chat completion. Declare the tools in the job description and train on whole conversations, text and tool calls together. If your conversations feed tool results back to the model, use chat-completion-agentic. The tool-call metrics are unchanged.

An existing dataset on one of the old tasks needs its config and job description updated before the next job. Migrating lists the changes.

Your small model can now follow the system prompt each request sends. Until now a model learned one fixed prompt, so every application, customer or policy with its own instructions needed its own model. With per-request system prompts, one model serves them all: each request states its rules, defaults or terms in the system message, and the model applies them.

To try it, set variable_system_prompt: true in the base section of your config, write the system message as the first message of your train and test rows, and add a mutator that tells the teacher what kind of system message to write for each generated example.

Mutators let you choose which situations your small model practices during training, including the ones that rarely show up in your production traces. Until now you had to list every value a mutator could take yourself, which meant knowing your data well before you started.

With auto mutators, you describe in one sentence what should vary, for example which part of the product the customer is asking about. The teacher reads your job description and a sample of your seed data, then proposes the values. They are printed in the run logs, so you can check them and pin down or edit any you disagree with.

Your small model can now reason through a task step by step before it answers. That matters for decisions the input doesn’t state outright, like whether an invoice total adds up, where a model answering in one pass hits a ceiling. During training, a larger teacher writes step-by-step examples, and your small model learns to work through new inputs the same way.

To try it, set enable_thinking: true before generating training data, and describe the reasoning format and length in synthetic_data_generation_instructions.

Fine-tuned Qwen3.5-4B got 98 of our 100 test invoices right with reasoning, against 84 when answering directly and 97 for GLM 5.3, the larger model that generated its training data.

Send your product’s traffic through a distil labs inference endpoint and we capture the requests and responses while your existing LLM keeps answering. You no longer need to prepare a trace export before getting started: sign up, create an endpoint and point your application at it.

Switching over means changing three strings: the base URL, the API key and the model name.

 client = OpenAI(
+    base_url="https://inference.distillabs.ai/v1",
-    api_key=os.environ["OPENAI_API_KEY"],
+    api_key=os.environ["DISTIL_API_KEY"],
 )

 client.chat.completions.create(
-    model="gpt-4.1-mini",
+    model="support-yeOdAS",
     messages=messages,
 )

The captured traffic is the starting point for your small model’s training data.

Mutators give you control over which situations your synthetic training data covers, including the ones your production traces barely contain.

The situations where a failure matters most are often rare in production, like a caller switching language halfway through a call or interrupting the agent mid-sentence. Training on your traces, or generating more of what they already contain, leaves your model with few examples of them. With mutators, you describe those situations and how often each should appear, and the teacher generates examples for your small model to learn from.

Sign up, point the platform at the production traces you already collect, and have a task-specific small model deployed behind an OpenAI-compatible endpoint in about 30 minutes. Most of that time is jobs running on our hardware while you do something else.

Training runs in six stages, from uploading traces to deployment, and each one returns a score, so you know whether the task is learnable before you spend anything on training. Drive it from the CLI, one command per stage, or install the skill and let your coding agent run it with you.

No production traces yet? A few dozen examples of the task are enough to try it, and the free tier covers two full training runs.

You can now fine-tune a small model on the whole conversation, text and tool calls together. We have trained multi-turn tool calling since June 2025, and two new task types cover the rest.

chat-completion is for an assistant that talks to the user and can fire tool calls in the same turn, so it can say “let me check that for you” and issue the lookup in one message. chat-completion-agentic adds the loop: the model reads what a tool returned, decides whether to call another, and then answers.

Your data goes in as OpenAI-style messages lists, and 10 to 50 seed conversations are usually enough.