Which Claude Opus 5.5 changes break your code without an error?

Claude Opus 5.5 shipped on September 22, 2026, and the migration guide lists four changes that return a 400 error the first time your code hits them. Buried past that list is a fifth change that returns 200 and does something quieter: an application that streams Claude’s commentary between tool calls stops receiving any text to show, with nothing in the response that says so.

What did Claude Opus 5.5 ship on September 22, 2026?

A model priced at $4 per million input tokens and $20 per million output tokens, both about 20 percent below Claude Opus 5’s $5 and $25, while keeping the same 1M token context window and 128k max output tokens. Anthropic’s own framing draws a line between two kinds of change: four things that “affect code already running on Claude Opus 5” by returning an error, and one thing that “alters the response shape without failing any request.” That second category is the one worth reading closely, because a request that succeeds gives you no reason to go check what changed inside it. The launch post and the release notes cover the headline capability gains; the migration guide and the what’s-new page carry the behavior a running integration actually needs to handle before traffic moves. Opus 5.5 also picks up the on-demand compaction beta, which the docs note matters more here than elsewhere, because compacted turns need to stay valid against a model whose thinking blocks are tied to the specific conversation that produced them.

Which four changes return a 400 error before you ship?

Thinking can no longer be turned off. A request with thinking: {"type": "disabled"} or a manual budget_tokens now returns "thinking.type.disabled" is not supported for this model, and the fix is to omit the field and pick an effort level instead. Forced tool use is gone too: tool_choice types any and tool fail with the same error on the token counting endpoint as on a real request, so a router that forces the first tool by name needs auto plus strict tool use or structured outputs. computer_20251124 is rejected outright on the Claude API and Google Cloud, though Amazon Bedrock still accepts it unchanged. And a thinking block replayed after the system prompt, tools, or an earlier message changed returns a 400 on accounts created on or after August 31, 2026, unless the conversation stays append-only.

Which Opus 5.5 changes you will notice, and when

Show as text

Which Opus 5.5 changes you will notice, and when. Diagram: 7 ordered layers. thinking.type disabled or enabled, then tool_choice any or tool, then computer_20251124, API and GCP only, then thinking block after an edited turn, then No error returned (breakpoint), then Text between tool calls, then Effort default drops to medium.

#	Layer	Note
1	thinking.type disabled or enabled	400, invalid_request_error
2	tool_choice any or tool	400, also fails token counting
3	computer_20251124, API and GCP only	400, Bedrock keeps working
4	thinking block after an edited turn	400, accounts after Aug 31 2026
·	No error returned (breakpoint)
5	Text between tool calls	200, thinking field empty by default
6	Effort default drops to medium	200, no signal anything changed

Why does tool-call progress text go quiet after you upgrade to Opus 5.5?

Because the short notes Claude writes between tool calls changed content block type. On Claude Opus 5 that narration came back as a text block. On Claude Opus 5.5, as on Claude Fable 5.1, it arrives as a progress-update thinking block instead, and at the default display: "omitted", a progress-update block’s thinking field is empty. No request fails. A chat interface that streamed that narration to show a user what the agent is doing mid-task simply stops receiving anything for that slot, turn after turn, with nothing in the response to explain why. The documentation’s own table is blunt about it: under "omitted", both reasoning blocks and progress-update blocks carry an empty field. Getting the text back means setting display to "updates", gated behind the thinking-display-updates-2026-08-18 beta header, or to "summarized", which mixes the progress notes back in with full reasoning text.

Why does Claude Opus 5.5 quietly think less unless you set effort explicitly?

The default value of effort changed. Thinking itself did not weaken. Opus 5 defaulted to high; Opus 5.5 defaults to medium, so any call that never set effort picks up a shallower setting purely by upgrading the model string. Anthropic’s own guidance complicates a simple read of that: at a matched effort level, Opus 5.5 tends to think more per turn than Opus 5 did, most noticeably at xhigh and max. The two facts together mean a request run with no effort field set can land anywhere from more thorough to distinctly shallower than the same call on Opus 5, depending entirely on whether the caller ever specified the parameter. The same silence applies to Opus 5.5’s refusal handling: a declined request returns HTTP 200 with stop_reason: "refusal", now including a reasoning_extraction category alongside the existing cyber one, so a status-code check alone will not catch it.

Claude Opus 5.5 pricing against Claude Opus 5

Show data

Claude Opus 5.5 pricing against Claude Opus 5. Bar chart. Opus 5, input: 5 USD per million tokens. Opus 5, output: 25 USD per million tokens. Opus 5.5, input: 4 USD per million tokens. Opus 5.5, output: 20 USD per million tokens.

Item	Value (USD per million tokens)
Opus 5, input	5
Opus 5, output	25
Opus 5.5, input	4
Opus 5.5, output	20

What should you actually do before moving production traffic to Claude Opus 5.5?

Treat the four 400 errors as a pre-flight check and the two silent changes as a separate, deliberate review. The errors will surface in staging the moment a test suite exercises the affected code paths, because Anthropic’s error messages name the exact field at fault. The silent changes will not surface that way. Nothing about setting effort or thinking.display is optional work hiding behind a flag; both need someone to decide the value on purpose, because the old behavior, high-effort reasoning and visible progress text, does not come back just because the request still succeeds. Anthropic ships a /claude-api migrate skill that handles the model ID swap and the mechanical parameter changes across a codebase, which is worth running first, but it cannot watch your streaming UI go quiet and tell you that matters. Claude Code’s own system-prompt recording shipped the same shape of change: a successful response that silently carries different behavior than the caller expects, catchable only by someone who goes looking.

Does a lower effort default actually make Claude Opus 5.5 worse than Opus 5?

Not necessarily, and the documentation stops short of saying either way. Anthropic states that Opus 5.5 thinks more per turn than Opus 5 at a matched effort level, but does not publish a comparison of Opus 5 at high against Opus 5.5 at its new default of medium, which is the actual before-and-after an upgrading caller experiences if they never touch the parameter. Whether that specific pair nets out ahead, even, or behind is not answered in either the migration guide or the what’s-new page, and treating it as settled in either direction would be repeating a claim nobody has measured. The safer position is the one Anthropic’s own recommended change already implies: re-run an effort sweep rather than assume the new default matches the old one’s quality, and pick the level a measured test actually supports.