Why does a Claude agent loop with tool_choice any never terminate?

## The bug The loop looks correct. You build a request, check `stop_reason`, append results, and repeat while the model keeps calling tools. In testing with `tool_choice` omitted it terminates cleanly. Then someone adds `tool_choice={"type": "any"}` — often to fix a separate complaint that the model was answering from memory instead of calling the tool — and the loop runs until it hits an iteration cap, a token budget, or a bill. ## Why Two facts collide. First, `tool_choice` is a parameter of a single `POST /v1/messages` call. There is no notion of applying it "for the conversation": the API is stateless, so whatever you pass this time is what governs this response. A loop that builds its request from a constant re-applies the constraint on every iteration. Second, `{"type": "any"}` means Claude *must* emit at least one `tool_use` block; it is not permitted to answer with text alone. `{"type": "tool", "name": ...}` is the same constraint narrowed to one tool. So on the turn where the model has everything it needs and would naturally write the answer, it cannot. It must call something. It typically re-calls the tool it just called, perhaps with a slightly different argument, and returns `stop_reason: "tool_use"` again. Your loop condition sees a tool call, feeds the result back, and asks again. Nothing in the exchange can ever break the cycle, because the cycle is exactly what you configured. ## The tell in the transcript The symptom that identifies this rather than a genuinely confused model is *repetition without progress*: the same tool called with the same or trivially varied arguments, results that the model plainly already has, and no text block explaining a plan. A model that is genuinely stuck under `auto` usually varies its approach or emits explanatory text; a model under a forced choice looks like it is going through the motions, because it is. ## Fixes **Force the first turn only.** Pass the forced value on iteration zero and `{"type": "auto"}` from then on. This is the common pattern when you want to guarantee the agent starts by gathering data rather than guessing, but want it to stop on its own once it has enough. **Close with `none`.** When the loop hits its budget, send one more request with `{"type": "none"}` and the same accumulated `messages`. The definitions stay in the prompt, so the cached prefix is untouched, but the model is now forbidden from calling and must produce the final prose answer. This converts a hard cut-off into a graceful summary instead of an empty response. **Fix the real complaint properly.** Forcing is usually a workaround for a tool that was not being called when it should have been. The durable fix is a description that states trigger conditions explicitly — "Call this whenever the question concerns current stock, price or availability" — rather than removing the model's ability to decline. Forcing across several declared tools can also push the model into calling the wrong one when the honest answer was none. **Cap iterations regardless.** A counter alongside the `stop_reason` check is non-negotiable. Even under `auto`, a tool that returns an unhelpful error can produce a long retry spiral, and each iteration re-sends the entire conversation — so the cost of a runaway loop grows faster than the turn count. ## The cost profile of the failure This bug is expensive out of proportion to its subtlety. Every iteration resends the full history plus all accumulated tool results, so input tokens grow with each pass and the marginal cost of turn twenty far exceeds turn two. A forced loop left running against a fast tool can burn a large budget in minutes with no output to show for it. That is why the iteration cap and a token or wall-clock budget belong in the loop scaffolding from the first version, not added after the first incident.