What do the tool_choice modes auto, required and none control in LLM tool calling?
answer
- A per-request switch, not global config
- Four shapes: choose, must, this one, never
- Force the first turn, close the last
- Naming differs across providers, semantics do not
- Forcing does not make the call good
basics
~20 sThey constrain what the model may emit on that one request: auto lets it choose between text and a tool call, required (called any by some providers) forces some tool call, a named tool forces that specific one, and none forbids tool calls entirely.
solid answer
~50 s`tool_choice` is a per-request control surface, not a property of the conversation. The four shapes are consistent across providers even though names differ slightly: **auto** — the model may answer in text or call a tool; **required** (or **any**) — it must emit a tool call, though it picks which; **a named tool** — it must call that one; **none** — tool calls are forbidden and it must answer in text. Because it is per-request, you can vary it turn by turn: force a lookup with `required` on the first turn of a support flow so the agent never answers a stock question from memory, then set `none` on the final summarizing turn so it cannot start a new investigation instead of writing the answer. Note that `none` usually leaves the tool definitions in the prompt — the model still sees them, it just may not call them.
go deeper
Know the four shapes and what each permits: auto lets the model decide, required makes it call something, a named tool pins the choice, none forbids calls for that request.
Explain that the setting is per request and show the two useful edges — forcing a lookup on the first turn so nothing is answered from memory, and forbidding calls on the last turn so the agent writes its answer.
Demonstrate the traps: a forced call is still unvalidated model output, none does not free the schema tokens, and required removes the loop's natural exit so you must supply one deliberately.
Treat it as loop policy rather than a flag. Define where in the agent's lifecycle grounding is compelled, where judgment is allowed, and how budget exhaustion converts into a final forced answer instead of a truncated run.
## A per-request switch, not a setting `tool_choice` accompanies a single model request. Nothing about it persists into the conversation, which is precisely what makes it useful: the same agent, over the same message history, can be governed differently at different points in its loop. Treating it as global configuration you set once at startup throws away most of its value. ## The four modes - **auto** — the default. The model decides whether this turn is text or a tool call. This is what you want for open-ended agents where the right move genuinely depends on the state. - **required** / **any** — the model must emit a tool call this turn, but chooses which tool and with what arguments. Provider naming differs here; the semantics do not. - **a named tool** — the model must call the tool you name. You have taken the selection decision away and left only argument extraction to the model. - **none** — the model must not call a tool. It answers in text. ## Where each one earns its place **Forcing a first call.** A restaurant-chain inventory assistant should never answer "do we have umbrellas in Brighton?" from parametric memory. Setting `required` on the first turn after a user question makes grounding structural rather than hopeful — no prompt wording is needed to insist the model look things up, because text is not an available output. **Closing the loop.** The mirror case is the last turn. An agent that has gathered enough and should now write the answer will sometimes start another investigation instead. Setting `none` on that final call makes summarizing the only thing it can do. This is also the clean way to end a loop that has hit its iteration or budget cap: one more turn with `none`, producing the best answer available from what was gathered. **Named-tool extraction.** Forcing one named tool turns the model into a structured extractor: you have already decided what happens, and you only want the arguments filled from natural language. Classification into an enum, or pulling a date range out of a sentence, is often better expressed this way than as free tool selection — though when extraction is all you want, provider structured-output modes may be a more direct fit than tool calling at all. ## What it does not do `tool_choice` does not validate arguments. A forced call is still a model-generated arguments object that can be wrong, incomplete or hostile, and it still passes through your validation and authorization checks. `none` does not remove the tool definitions from the request in most implementations. The schemas are still in the prompt, still costing tokens, and still influencing the model's language. If your goal is to stop paying for definitions the model cannot use, you have to drop the definitions, not set `none`. Forcing a call does not make it a *good* call. If the model had no sensible tool to reach for, `required` compels it to pick one anyway — typically the closest match with invented arguments. Forcing turns "I do not know" into a confidently wrong invocation, which is why blanket `required` across a whole loop is a bad default. ## Interaction with the loop A loop that forces a call every turn cannot terminate on its own, because termination is signalled by a turn with no tool call. If you use `required`, you must own the exit condition explicitly — usually by switching to `none` or `auto` once a stop signal is reached, or by giving the model an explicit finish tool that your loop recognizes as the end. `required` also composes with parallel calls: the constraint is that at least one call is emitted, not exactly one. ## Choosing a policy The practical pattern for a task-shaped agent is: `required` on entry to force grounding, `auto` through the middle where judgment is genuinely needed, `none` on exit to force an answer. The practical pattern for an open assistant is `auto` throughout, with `none` reserved for budget exhaustion. The anti-pattern is a static setting chosen once and never varied, which either lets the agent skip the lookups you needed or prevents it from ever finishing.
- Does setting none save you the token cost of the tool definitions?Usually not. In most implementations the definitions still travel in the request and still occupy context; none only forbids the model from emitting a call. If the aim is to stop paying for schemas the model cannot use, omit the tool definitions from that request instead. Setting none is about controlling output shape, not about trimming input, and conflating the two leads to surprise at the token bill.
- What breaks if you set required on every turn of an agent loop?Termination. The loop normally ends when an assistant turn arrives with no tool call, and required makes that turn impossible, so the agent runs until it hits an iteration or budget cap. You either switch to none or auto once a stop condition is met, or give the model an explicit finish tool whose invocation your loop treats as the end.
- When would you force one named tool rather than let the model choose?When the action is already decided and only the arguments are in question — classifying a message into a fixed enum, or extracting a date range from a sentence. You are using the model as a structured extractor, not as a planner. If the whole task is extraction with no side effect, a provider's structured-output mode is often a more direct fit than dressing the extraction up as a tool call.
saying these in an interview costs you the question
- Thinking tool_choice is a conversation-wide setting
- Believing none strips tool definitions from the prompt
- Assuming a forced call has valid arguments
- Forcing every turn and wondering why the loop never ends
- Expecting required to pick the right tool