Anthropic's Claude Opus 5.5 arrived on September 22 at $4 per million input tokens, a fifth cheaper than Claude Opus 5. It also rejects four request patterns that Opus 5 accepted, and each one comes back as an HTTP 400 rather than a quiet fallback. Anthropic's own migration notes list them together; The New Stack was among the first to point out that a price cut this size ships with a migration attached.
Key takeaways
- Four patterns now return a 400 invalid_request_error on
claude-opus-5-5: disabling thinking, forcing tool use, replaying a thinking block after the prompt prefix changed, and declaring thecomputer_20251124computer use tool on the Claude API or Google Cloud. - The first three also apply to Claude Fable 5.1, so a single migration pass covers both models.
- A fifth change raises no error: the text a model writes between tool calls now arrives inside thinking blocks that are empty under the default
display: "omitted"setting, so applications streaming those notes as progress updates simply go silent.
What now returns a 400
Thinking is no longer optional. On Opus 5, thinking: {"type": "disabled"} was accepted at effort high or below. On Opus 5.5 adaptive thinking is always on, and both that setting and a manual budget_tokens allocation return an invalid request error. The documented replacement is the effort parameter β lower it where thinking used to be switched off.
There is a second-order effect worth catching early. The default effort on Opus 5.5 is medium, where Opus 5 defaulted to high. A team that never set effort explicitly is therefore changing two variables at once: the request shape and the amount of reasoning behind every answer.
Forced tool use goes with it. tool_choice values of {"type": "any"} and {"type": "tool", "name": ...} both fail, and the same validation runs on the token counting endpoint, so a pre-flight count will not warn you ahead of the real call. Only auto and none remain. Where the goal was a guaranteed JSON shape, Anthropic points to strict tool use or structured output; where the goal was simply to make the model reach for a tool, that now belongs in the prompt.
Thinking blocks now carry a model and a prefix
The third change is the subtlest, because it fails in two different ways. Every thinking block records which model produced it, and each model reads only part of the family tree. Opus 5.5 reads blocks from Opus 5 and earlier Opus, Sonnet and Haiku models, but not from Claude Fable or Claude Mythos models. On the Claude API, only Fable 5.1 and Mythos 5.1 can read blocks that Opus 5.5 produced.
Cross the wrong boundary and nothing breaks: the API strips the unreadable block before the model sees it, the request succeeds, and the dropped block is not billed. A conversation quietly continues without its earlier reasoning. The only signal is the top-level input_transformations array, which requires the thinking-binding-controls-2026-08-01 beta header to appear at all.
The 400 comes from a separate check. The API verifies that nothing preceding a thinking block β the system prompt, the tool definitions, an earlier message β has changed since the block was produced, and it enforces that by default for accounts created on or after August 31, 2026 on the Claude API and on cloud platforms. Rewriting a system prompt mid-conversation is now a failure mode rather than a habit. The documented fix is to keep conversations append-only, changing instructions through mid-conversation system messages instead of edits.
Computer use loses its older tool on two platforms
On the Claude API and Google Cloud, Opus 5.5 accepts computer use only as the computer_toolset_20260801 toolset; a request declaring the earlier computer_20251124 tool is rejected outright. Amazon Bedrock is the exception, where the older tool keeps working exactly as it did on Opus 5.
That asymmetry matters for anyone running the same AI agent across providers, because the identical payload will pass on Bedrock and fail on the Claude API. Migrating means dropping the computer-use-2025-11-24 beta header, swapping the tools entry, and updating the agent loop for member tool_use blocks, batch actions and the toolset name on results. The browser use tool is unaffected.
The change that breaks nothing and hides the most
None of the above is the change most likely to be noticed by end users. Opus 5.5 returns the short notes it writes between tool calls as progress-update thinking blocks rather than text blocks. Under the default display setting those blocks arrive with an empty text field, so a product that streamed those notes into a chat window or a build log now shows nothing between tool calls β with no error, no status code, and no log line to trace.
For a long-running agent session, that is the difference between a user watching work happen and a user watching a spinner. Restoring it takes one setting, thinking.display, but only if someone notices the silence in the first place.
Which integrations actually have to change
The blast radius is narrower than four breaking changes makes it sound, and it falls unevenly. Three profiles carry almost all of the work. Latency-tuned pipelines that disabled thinking to shave seconds off a classification or routing call have to pick an effort level and re-measure, because there is no longer a zero-reasoning setting to fall back to. Extraction services that leaned on forced tool use as a cheap schema guarantee need a different mechanism, not a different value.
The third group is the one likely to be surprised. Multi-model routers that switch mid-conversation to manage cost now have a compatibility matrix to respect, and because incompatible reasoning is dropped rather than rejected, a router can degrade answer quality for weeks without a single failed request to point at. Anything that merely calls Opus 5 with thinking already on, on the current computer use toolset, is untouched.
What to re-test before shipping
Two more behaviour shifts throw nothing. Opus 5.5 tends to think more per turn at the same effort level, most of all at xhigh and max, so an effort sweep carried over from Opus 5 will be miscalibrated and max_tokens needs headroom for the reasoning. The model also runs a biology safeguard classifier alongside the cybersecurity one, and can decline requests that push it to restate its internal reasoning.
Refusals are the last trap for error handling: they return HTTP 200 with stop_reason: "refusal" and a stop_details object naming the policy area, so code that branches on status codes will read them as successes. Between that, the silent thinking-block drops and the muted progress updates, the pattern across this release is consistent β the loud failures are the easy ones. The pricing that led most of the launch coverage, including the safeguard that routes some tasks to older models, only pays off once the requests parse.
FAQ
Does Claude Opus 5.5 support forced tool use?
No. Setting tool_choice to {"type": "any"} or {"type": "tool", "name": ...} returns a 400 invalid_request_error on claude-opus-5-5. Only auto and none are accepted, and the same validation applies to the token counting endpoint.
Are dropped thinking blocks billed?
No. When a request carries a thinking block the target model cannot read, the API removes it before the model sees it and does not bill it. The request still succeeds, so the drop is only visible through the input_transformations array returned with the thinking-binding-controls-2026-08-01 beta header.
Does the computer use change affect Amazon Bedrock?
No. The computer_20251124 tool continues to work on Opus 5.5 through Amazon Bedrock as it did on Opus 5. The restriction applies to the Claude API and Google Cloud, where only the computer_toolset_20260801 toolset is accepted.
