Claude Opus 5.5 is cheaper and breaks four things agents use

Claude Opus 5.5 shipped on 22 September 2026 at $4 and $20 per million input and output tokens, below Claude Opus 5's $5 and $25, with a 1M-token context window by default, 128k maximum output and always-on adaptive thinking. It also breaks four things code already running on Claude Opus 5 depends on. Three of them return HTTP 400.

The count is not ours. Anthropic's What's new in Claude Opus 5.5 page opens by naming four breaking changes and lists each under its own heading; the migration guide gives the before-and-after code for the same four. A fifth change alters the response shape without failing anything, which is the one most likely to reach your users before it reaches your error log.

What breaks	Symptom	Fix
thinking disabled or budgeted	400 invalid_request_error	Omit thinking; set effort
tool_choice any or tool	400 invalid_request_error	auto plus strict tool use
computer_20251124	400 on Claude API and Google Cloud	computer_toolset_20260801
Replayed thinking blocks	Dropped, or 400 on newer accounts	Keep conversations append-only
Text between tool calls	None — the UI just goes quiet	Set thinking.display

Thinking can't be disabled on Claude Opus 5.5

On Claude Opus 5, thinking: {"type": "disabled"} was accepted at effort high or below. On Claude Opus 5.5 it is rejected, and so is a manual budget:

"thinking.type.disabled" is not supported for this model. Use
"thinking.type.adaptive" and "output_config.effort" to control
thinking behavior.

Remove the field, or send thinking: {"type": "adaptive"}, which is equivalent. Depth is then controlled by the effort parameter — five levels, low through max, defaulting to medium. Where you disabled thinking to save tokens, drop the effort level instead; it is not the same lever, and the token count will not match what you had.

Two second-order effects catch integrations that were never touching the thinking field at all. Every response can now begin with thinking blocks, so code that reads content[0] and expects text breaks silently. And max_tokens still caps thinking plus response text together, so a request that used to fit no longer does. Anthropic's checklist suggests starting at 64k for xhigh or max.

Forced tool use returns 400

tool_choice set to {"type": "any"} or {"type": "tool", "name": "..."} now returns a 400:

tool_choice: type "tool" and "any" are not supported for this model.

The same validation applies on the token-counting endpoint, which is worth knowing if you pre-flight requests there. auto and none still work. If you were forcing a tool to get schema-valid JSON, keep auto and set strict: true with strict tool use, or move the schema to structured outputs. If you were forcing a call so the model acted instead of replying in prose, that is now a prompting problem: say in the prompt when the tool applies.

This one costs the most engineering time of the four, because forced tool use is often load-bearing in a router or a classifier, and the replacement is a different mechanism rather than a renamed parameter. Budget a day for the prompt work and a rerun of your eval suite, not an afternoon of find-and-replace.

Thinking blocks are tied to the model and the conversation

This is the change with no error code to grep for. Every thinking block records which model produced it, and models only read some others' blocks. Claude Opus 5.5 reads thinking from Claude Opus 5 and earlier Opus, Sonnet and Haiku models. Going the other way, only Claude Fable 5.1 and Claude Mythos 5.1 read Claude Opus 5.5's blocks on the Claude API. When a request carries a block the target model cannot read, the API drops it before the model sees it — the request succeeds, the dropped blocks are not billed, and the turn simply runs without the earlier reasoning.

If you run a router or a cost-tiered fallback, that is a quality change you will not see in your logs. It is the same class of problem we wrote about in what does and does not carry over between agent turns, and the answer is the same: know what your harness is dropping.

There is also a prefix check. If the system prompt, the tools, or an earlier message changed after a Claude Opus 5.5 thinking block was produced, replaying that block returns 400 — enforced by default for accounts created on or after 31 August 2026. The documented way out is to keep the conversation append-only and change instructions with mid-conversation system messages rather than edits; Preserved thinking has the beta header that drops the blocks instead.

Computer use needs the new toolset, except on Bedrock

On the Claude API and Google Cloud, Claude Opus 5.5 accepts computer use only as the computer_toolset_20260801 toolset. Declaring the earlier computer_20251124 tool returns:

'claude-opus-5-5' does not support tool types: computer_20251124.

On Amazon Bedrock, computer_20251124 keeps working on Claude Opus 5.5 exactly as it did on Claude Opus 5. That divergence is the trap: a team running the same agent on Bedrock in production and the Claude API in development gets a green build in one place and a 400 in the other, from identical code. The migration is not just a string swap either — you drop the beta header, replace the tools entry, and update the agent loop for member tool_use blocks, batch actions and toolset_name on results. If you are weighing computer use across vendors, our notes on what a computer-use model can actually automate apply to either one.

The change with no error: your progress updates go quiet

Text the model writes between tool calls used to arrive as text blocks. On Claude Opus 5.5 it arrives as progress-update thinking blocks, and at the default display: "omitted" the thinking field is empty. Nothing fails. An interface that streamed those notes as progress simply stops showing anything between tool calls. The fix is to set display: "updates" (beta) or "summarized" and render the non-empty blocks.

Alongside it sits a behaviour change worth re-baselining for: the default effort is now medium, where Claude Opus 5's was high, and at a given effort level the model tends to think more per turn. A request that omits effort is not the request you were sending last week. Re-run the sweep rather than carrying a setting over — and score the whole run, not the final answer, as we argue in scoring the trajectory rather than the output.

Is Claude Opus 5.5 actually cheaper in practice?

Per token, yes: $4 and $20 against $5 and $25 is 20 per cent off both sides. Cache reads are $0.20 per MTok, five per cent of base input rather than the usual ten, and batch is half price at $2 and $10. Fast mode, in research preview on the Claude API only, is $8 and $40.

Per request is a different question. Thinking cannot be disabled, thinking tokens land in the output budget, and the model thinks more per turn at a given effort. A workload that ran on Claude Opus 5 with thinking off can produce more output tokens per request here, and output is the expensive side. The honest answer is that you find out by measuring at your chosen effort level, which is exactly what Anthropic's own checklist asks for. Our line-by-line breakdown of agent costs has the shape of that calculation.

One limit on all of the above: this is what the documentation said on 23 September 2026, the day after release, and we have not run production traffic on the model. Model line-ups and prices move fast enough that the version of this page you are reading may already be stale — check the release notes before you quote a figure. If the migration is on your desk and you would rather not discover the Bedrock divergence in a customer's environment, that is the sort of thing our AI engineering practice is hired for.