With Mistral tool_choice "any" on every turn, why does your agent never finish?

## The symptom An agent that always calls a tool, forever. Latency climbs, the token bill climbs with the growing history, and the user never sees an answer — often with the model re-calling the same tool with slightly reworded arguments because your history keeps telling it that it must call something and it has already learned everything the tool can tell it. ## The mechanism `tool_choice` in Mistral's chat completions request takes `"auto"`, `"any"`, `"none"`, or an object naming a specific function. `"any"` means the model must produce a tool call. It is not a hint, and it does not lapse once one call has been made — it applies to whichever request carries it. So if your client wrapper sets `"any"` on every call to the API, the exit condition your loop is watching for (`finish_reason: "stop"`, or an assistant message with no `tool_calls`) is structurally unreachable. You have written a loop whose termination test can never pass. This is easy to introduce because forcing genuinely is the right setting for the *first* request in many designs: a research agent that must always search before answering, a router that must always pick a handler, an extractor whose only acceptable output is a filled schema. The mistake is scoping the setting to the client or the conversation instead of to the request. ## The fix, in order of preference **Scope the parameter per request.** Build the request fresh each hop. Hop 1 sets `"any"`; every later hop sets `"auto"`. Nothing about the conversation state needs to change — the model reads the tool results already in the history and, freed from the constraint, answers when it has enough. **Close with `"none"` when you need a guaranteed final answer.** If your product cannot tolerate an nth tool call — say you are on a latency budget or you have hit your own iteration cap — send one last request with `"none"`. The tools stay declared, calling is barred, and the model must summarise what it has. This turns "ran out of iterations" into a coherent answer instead of an error page. **Cap iterations anyway.** Forcing is the deterministic cause of non-termination, but not the only one: a tool that returns unhelpful output can make an `"auto"` model retry indefinitely too. A hard cap (typically a handful of hops) with a `"none"` closing turn is the belt-and-braces version, and it also bounds worst-case cost per user request. ## Detecting it in production Instrument hop count per user request and alert on the tail. A distribution where the modal conversation uses one or two tool hops but a slice sits pinned at the cap is the signature. Correlate with `tool_choice` in your request logs; if the pinned slice is all `"any"`, you have found it in one query. Because each hop resends the entire growing history, cost per conversation grows superlinearly with hops, so this bug is expensive in a way a per-request cost dashboard hides. ## The related quality problem Even a single forced turn has a cost worth naming: a model compelled to call something when no declared tool fits will pick the nearest and invent arguments rather than decline. If your tool surface does not cover the whole input distribution, either keep `"auto"` and write tool descriptions good enough that abstention is natural, or declare an explicit no-applicable-tool function so that forcing still has a correct answer available. Combining that escape hatch with per-request scoping gives you determinism where you need it without manufacturing confident nonsense on the inputs you did not anticipate. ## What a strong answer sounds like State the mechanism in one line — forcing makes the terminating response unreachable — then show that you know `tool_choice` is request-scoped, that `"none"` is the closing move, and that an iteration cap belongs there regardless. Mentioning the cost shape (history resent every hop) and the forced-call quality risk marks someone who has operated one of these loops rather than read about one.