Porting tool_choice "required" from OpenAI to Mistral — which value do you use?

## Why this is the classic Mistral porting bug Mistral's chat completions endpoint is deliberately OpenAI-shaped: same `messages` array, same `tools` array of `{"type": "function", "function": {name, description, parameters}}`, same `tool_calls` on the way back. That similarity is exactly what makes the `tool_choice` vocabulary dangerous — you copy a working OpenAI request, change the base URL and the model id, and every field looks familiar. But the forcing mode has a different name, and "OpenAI-compatible" never means "every value string is identical". ## The four settings **`"auto"`** — the default whenever `tools` is present. The model decides, per request, whether to answer in prose or emit `tool_calls`. This is what you want for a general assistant, and it is what you must return to after a forced turn. **`"any"`** — the model *must* return a tool call. Use it when the tool is the point of the request: a structured-extraction step where prose is never an acceptable output, a router that must select one of N handlers, a first hop that must always fetch data before reasoning. The consequence is that a response under `"any"` never terminates a loop on its own — there is no path to a final text answer while the setting is in force. **`"none"`** — the tools stay in the request and therefore still occupy input tokens, but the model is barred from calling them and answers in text. This is the setting for a summarize-what-you-found turn at the end of an agent loop, or for a debugging comparison where you want the same prompt with and without tool access. Note the difference from simply omitting `tools`: with `"none"` the schemas are still visible to the model and still billed; with the array removed the model does not know the tools exist at all. **A specific-function object** — passing an object that names one declared function pins the call to that function. It is the narrowest form of forcing: not "call something" but "call this one". Useful when your application already knows which tool is required and only needs the model to fill in the arguments from natural language. ## The mapping table you should carry in your head | Intent | Mistral | OpenAI | |---|---|---| | Model decides | `auto` | `auto` | | Must call some tool | **`any`** | **`required`** | | Must not call | `none` | `none` | | Must call one named tool | object naming the function | object naming the function | Only one row differs, and it is the row people copy most often. ## Operational consequences of forcing Forcing changes the termination properties of your loop. Under `"auto"`, the loop ends naturally when the model decides it has enough information and returns `finish_reason: "stop"`. Under `"any"`, that never happens: every round trip yields another call. The correct pattern is per-request rather than per-conversation — set `"any"` on the specific request where a call is mandatory, then rebuild the next request with `"auto"` (or `"none"` if you want a guaranteed final prose turn). Since `tool_choice` is a request-level parameter, not conversation state, this costs you nothing but the discipline of not hard-coding it in a client wrapper. Forcing also interacts with quality. A model compelled to call a tool when no tool actually fits will pick the closest match and invent plausible arguments rather than say "I cannot help with that". If your tool surface does not cover the whole input distribution, `"auto"` plus a well-described fallback tool is usually safer than `"any"`. ## Cost notes Tool schemas are prompt content. Whatever `tool_choice` you set, every declared tool's name, description and JSON Schema is serialized into the input and counted in `usage.prompt_tokens` on each request. Setting `"none"` suppresses calling, not billing. If a long agent loop only needs three of your twenty tools after the first hop, pruning the `tools` array for later requests saves real money; flipping `tool_choice` does not. ## What a strong answer sounds like Name the values, name the rename against OpenAI, and then say something operational: that `"any"` is a per-request switch you flip back, that `"none"` still costs tokens, and that pinning a specific function is available when you already know the target. Candidates who only recite three strings without the porting trap or the termination consequence sound like they have read the docs but not run the loop.