Which Task Type Should You Pick?

Start from the output, not the input. If the answer is one of a fixed set of labels, pick classification. If it is a function call, pick tool calling. If it is free text, pick a question-answering variant and let the source of the knowledge decide which one.

Which task type matches the output you need?

The decision table from the task selection guide, with the config value you will actually type:

If you need to…	Pick	base.task
Assign one of a fixed set of categories	Classification	classification
Generate a targeted answer from a text-based problem	Question answering	question-answering
Answer from a passage you supply at query time	Open-book QA (RAG)	question-answering-open-book
Answer from knowledge learned during training	Closed-book QA	question-answering-closed-book
Turn one request into one structured call	Tool calling	tool-calling-closed-book
Do that across a conversation	Multi-turn tool calling	multi-turn-tool-calling-closed-book

Read the rows top to bottom and stop at the first one that describes your output exactly. If two describe it equally well, the next section is for you.

What do you pick when two task types both fit?

Take the more constrained one. A tighter task specification gives the teacher less room to drift during synthetic generation and gives you a metric that actually discriminates.

Classification versus question answering. Classification, whenever the label set is closed and known. Sentiment, ticket routing, moderation verdicts, and topic tagging are all classification even if you currently prompt an LLM for them in prose. You gain a per-class breakdown of errors, which a free-text metric will not give you.

Open-book versus closed-book QA. Provenance decides it. If an answer has to be traceable to a document, you need retrieval and therefore open-book — a closed-book model cannot point at a source. If your corpus changes weekly, open-book also wins, because reindexing is faster than retraining. Choose closed-book when the knowledge is stable and you would rather ship one artefact than operate a retriever. The full comparison is in open-book vs closed-book QA.

Tool calling versus classification. If the downstream system needs arguments as well as a name, it is tool calling. If it only needs the name, classification is cheaper to prepare and easier to evaluate — a routing decision with no parameters does not need a JSON schema.

Single-turn versus multi-turn tool calling. Multi-turn as soon as any request can refer to an earlier one. “Cancel that one instead” is unanswerable without history.

Which choices lock you out of a model?

Both tool-calling tasks do. The supported models catalog restricts tool-calling-closed-book and multi-turn-tool-calling-closed-book students to the Qwen3, Qwen3.5, Llama 3, LFM2/LFM2.5, FunctionGemma, and Gemma 4 families, and teachers to those marked in the tool-calling column.

Task type	Student models available	Teacher models available
Classification, all QA variants	All catalog students	All catalog teachers
Tool calling, multi-turn tool calling	Qwen3, Qwen3.5, Llama 3, LFM2/LFM2.5, FunctionGemma, Gemma 4	Only those with tool calling marked

The trap sits inside the DeepSeek family: deepseek.v3.2 qualifies as a tool-calling teacher, while deepseek.r1 and deepseek.v3.1 do not. For new work zai.glm-5 is the safest teacher across all six tasks — it is what recent distil labs runs use and it supports tool calling. Reasoning teachers, which is most of the catalog, require synthgen.teacher_temperature between 0.5 and 0.7:

base:
  task: classification
  student_model_name: Qwen3-1.7B
  teacher_model_name: zai.glm-5
synthgen:
  teacher_temperature: 0.6

More on the trade-offs in which teacher model should you pick.

What do people get wrong most often?

Four mistakes, roughly in order of how expensive they are.

Framing a closed-label problem as generation. The model returns “This looks like a billing issue” instead of billing, and now you are parsing prose in production. Use classification and the label is the whole output.

Picking closed-book QA to avoid building a retriever. Closed-book works, but it makes every knowledge update a retraining job, and it cannot cite. If the reason for choosing it is that retrieval is inconvenient rather than that the knowledge is stable, you have chosen the harder operational path.

Training single-turn tool calling for a conversational product. The evaluation looks fine because each test line is independent. Then per-turn errors compound in production: at 90% per call, a five-turn conversation completes correctly about 59% of the time.

Ignoring the model restriction until upload. Choosing a student first and a task second can leave you with a model that is not eligible. Pick the task, then the student.

How do you confirm the choice before training?

Run teacher evaluation on a small dataset. It scores a large model on your test set with your job description, and it costs a fraction of a training run.

distil model create triage-classifier
distil model upload-data <model-id> --data ./data
distil model run-teacher-evaluation <model-id>
distil model teacher-evaluation <model-id>

A low teacher score usually means the task is under-specified rather than that the task type is wrong — the docs list sharpening the task description and fixing inconsistent labels as the first fixes. But it also surfaces genuine mis-framing: if a classification task scores badly because half your examples have two defensible labels, the taxonomy is the problem, and no task type will rescue it. If you are working open-book and retrieval returns several candidate chunks, note that distil labs can train against distractor contexts too, an approach introduced as RAFT and exposed as synthgen.num_distractor_context_blocks in the config reference. For a broader tour of the six options, see the six task types.