You may still say none

There is a line in Anthropic's tool-use documentation that most people integrating the API will have skimmed past, because it read as an implementation detail. When tool_choice is set to any or to a named tool, it says, "the API prefills the assistant message to force a tool to be used."

That sentence now explains a breaking change. Claude Opus 5.5, launched on 22 September, rejects tool_choice of type any or tool with a 400 error. So do Claude Sonnet 5.5, launched six days later, and Claude Fable 5.1 and Mythos 5.1. Opus 5.5 and Sonnet 5.5 also reject an assistant prefill, and both return a 400 for thinking: {"type": "disabled"}. I read the three refusals as one. Forcing a tool meant writing the opening of the model's reply for it, and a reply that must begin by thinking cannot also begin with a tool call somebody else wrote. The documentation states the consequence on the models that still accept forcing: "a forced call skips thinking: the response starts with the tool call and has no thinking block."

Claude Haiku 5.5, released on 7 October, makes the line visible, because it is on the other side of it. Haiku 5.5 still accepts a forced tool_choice, and the response it returns starts with the tool call and carries no thinking. The model tuned for high-volume work can still be made to act. The flagship ones can only be asked.

Half of a guarantee

Here is the narrow claim. The replacement the documentation names everywhere is tool_choice: {"type": "auto"} with strict: true on the tool. Strict tool use applies grammar-constrained sampling to the tool's input, so a call that is made matches the schema. That is a real guarantee and it survives. What does not survive is the guarantee that the call is made. The Sonnet 5.5 migration guide is candid about it: "The model can then answer without calling the tool, so say in the prompt when to use it." The tool-use page itself still describes the combination that no longer exists on these models: any plus strict "to guarantee both that one of your tools is called and that the tool inputs strictly follow your schema." Both was the point. On Opus 5.5 and Sonnet 5.5 you get one.

In pipeline terms, that removes a control-flow guarantee and keeps a type guarantee. A type guarantee tells you what a value will look like if it arrives. A control-flow guarantee tells you which branch the program takes. Forced tool use was how a great many systems that call a model without being agents got their control flow from an API parameter instead of from hope. The extraction step that must return a record. The router that must emit exactly one of five classification tools. The planner step in an orchestration graph whose next edge depends on which tool was called. In each of these the caller did not want the model to decide whether to act. It wanted the model to decide how. tool_choice was the one place in the request where that split could be written down and enforced by the server.

Now the split is a sentence. The Opus 5.5 migration guide's after-example rewrites the user message from "What's the weather in Paris?" to "What's the weather in Paris? Use the get_weather tool." The parameter that used to compel the call has become a request appended to the user's words. I do not doubt that it works almost every time. Almost every time is a probability. A parameter was a contract.

Where the branch goes

The architectural consequence is that "the model replied in text instead" is now a reachable state at every step that used to force a tool, and somebody has to own it. The migration guides do not hide this. On Amazon Bedrock, structured outputs, strict tool use included, are not available for Opus 5.5, Sonnet 5.5 or Haiku 5.5. There the guidance for replacing forced tool use is to "send auto without strict, say in the prompt when the tool applies, and validate the tool input in your code." On that platform both guarantees have left the server. The model ID is the same one you would send to the Claude API. The contract is not. A team that runs the same model on two clouds has, for this one feature, two different systems. Only one of them can promise anything about the shape of a call, and neither can promise that a call happens.

So the validator, the retry and the fallback branch move into every caller. That is not unusual work. Nobody serious trusted a model's output without checking it. What changes is the kind of check. Validating the shape of a value is local and cheap. Handling the absence of an expected action means deciding what the step does when it gets prose: re-prompt with a firmer instruction, retry on a model that can still be forced, fail the job, or hand the text to a parser. Each choice has a cost the old request never incurred, and each is a design decision that used to be made once, by the platform, and is now made separately in every codebase that called the endpoint.

There is a quieter cost in the schedule. The release notes record that Claude Sonnet 4.5 retires on the Claude API on 30 November, with Sonnet 5.5 the recommended replacement. Sonnet 4.5 accepts forced tool choice. A team whose pipeline depends on it, and which follows the vendor's advice, is migrating to a model on which that dependency is a 400 error. The migration guide spells out the edit to the request. It cannot write the new branch in the code that reads the response.

The case for asking

The opposing view is strong, and on the model's side of the boundary I think it is correct. A forced call was a worse call. It skipped thinking, by the documentation's own account, so the model committed to a tool and to arguments before it had reasoned about either. Making the model think first and then choose is the better way to get a good tool call, and a prefill that bypasses the reasoning works against the thing these models are now built around. The documentation has long recommended the softer route anyway: when you want an explanation alongside the call, use auto and say in the user message which tool to use. Seen this way, Anthropic has removed a footgun that made its best models answer worse.

For the most common reason people forced a tool, there is also a better instrument. Structured outputs with output_config.format constrain the final response itself to a JSON schema through constrained decoding. An extraction step that forced a single tool only to get a typed record should never have been a tool call, and on the Claude API it can now be a schema on the response, with the guarantee stronger than before. And Haiku 5.5, the model built for the high-volume work where deterministic routing usually lives, still accepts forcing.

I accept most of that. I part company at two points. First, structured outputs do not replace a forced tool in the step where the choice of tool is the output: the router choosing among five handlers, or the orchestrator that must act before it may speak. A schema on the final text can approximate that by turning the choice into an enum, but only by taking tool calling out of the loop that was built around it. Second, the stronger guarantees are exactly the ones a platform can withdraw. Structured outputs are absent for all three 5.5 models on Bedrock. Even where they exist, the documentation lists the cases they do not cover: a refusal "takes precedence over schema constraints," and a response cut off at max_tokens "may be incomplete and not match your schema." The guarantee was always conditional. It is now conditional by cloud as well.

Nor does the Haiku exception reassure me. It shows the line being drawn by capability rather than by use. The model you can compel is the one you would least like to put in charge of a hard decision. The one you would put in charge can only be persuaded.

What the request can still say

What the change reveals is a shift in what a model API is. For most of its short history the request was a set of instructions the server would enforce: this temperature, this opening, this tool. One by one, on the frontier models, those have become 400 errors or hints. Haiku 5.5 rejects any temperature other than 1. Prefill is gone. Thinking cannot be disabled on Opus 5.5, and effort, which the Opus 5.5 migration guide calls "the only request parameter that controls" thinking depth, is a level rather than the token budget it replaced. The pattern is consistent and, from a model-quality standpoint, defensible. Its effect on the systems around the model is that the caller has fewer ways to compel and more to request. The responsibility for determinism moves outward, into code the caller writes and the vendor does not see.

The Monday consequence is concrete. Inventory every call that sets tool_choice to any or tool. For each, decide whether it is really an extraction, in which case move it to structured outputs where your platform offers them, or a control-flow decision, in which case write the branch for the reply that does not call the tool, and test that branch on purpose, because it will not show up in a happy-path suite. Write down, per cloud, which guarantees your model actually has. They are no longer the same everywhere.

One option survives intact, and it is the one that says the most. tool_choice: {"type": "none"} is still accepted on every one of these models. A caller can still tell the most capable model it buys that it may not act. It can no longer tell it that it must.

This piece argues from one party's record: Anthropic's documentation and release notes, read in this session. Other providers' treatment of forced tool calls was not examined, and nothing here should be read as a claim about them.