Rohit Ghumare · September 22, 2026 · 11 min read

Opus 5.5 Always Thinks. The Price Cut Has a Break-Even.

Anthropic shipped Claude Opus 5.5 on September 22 at $4 per million input tokens and $20 per million output, down from Opus 5's $5 and $25, with cache reads at $0.20 instead of $0.50. The launch post says it costs "40% less than Opus 5 on typical workloads" and writes output "more than 30% faster." The API release notes carry the line that matters more for anyone with code in production: thinking: {"type": "disabled"} now returns a 400. Every Opus 5.5 request thinks, and thinking is billed as output.

A cheaper token and a mandatory one

Two things changed on September 22, and the headline blends them. The first is a price. Input fell 20%, output fell 20%, cache writes fell 20% to $5, and cache reads fell 60%. Per the models overview, a cache read on Opus 5.5 costs 5% of the base input price, against the 10% that applies to most of the lineup. For an agent loop that rereads the same long prefix every turn, that last number moves the bill more than the other three.

The second is a contract. On Opus 5, thinking was a switch you could turn off at low, medium, and high effort. On Opus 5.5, adaptive thinking is always on, and effort is the only request parameter that controls how much of it happens. The same release forbids a handful of other settings, so a request body that worked on Friday fails on Monday with the model ID as the only edit.

The model itself is a straightforward upgrade: 1M tokens of context by default with no beta header, 128K tokens of maximum output, and a retirement date no sooner than September 22, 2027. Anthropic's own benchmark table has it at 66.4% on Terminal-Bench 4.0 and 81.8% on OSWorld 2.0, and the launch post describes a code audit of a 200,000-line codebase in under three hours where Opus 5 took more than twenty. Those are vendor numbers. The request contract is the part you can check yourself today.

What the request has to satisfy

The migration guide opens with a list titled "What every request to Claude Opus 5.5 must satisfy." Read it as a linter spec. Send no thinking field, or send {"type": "adaptive"}, which means the same thing. Manual budgets ({"type": "enabled", "budget_tokens": N}) are rejected with "thinking.type.enabled" is not supported for this model. Forced tool use is gone: tool_choice of type any or tool returns tool_choice: type "tool" and "any" are not supported for this model., including on the token counting endpoint, and the replacement is auto with strict tool use or structured outputs. Non-default temperature, top_p, and top_k are rejected, and so is a prefilled assistant turn at the end of messages. Those last two already failed on Opus 4.6 and later, so they only bite teams jumping several generations at once.

Computer use is the platform-shaped exception. On the Claude API and Google Cloud, the tool must be declared as the computer_toolset_20260801 toolset, and the older computer_20251124 tool returns a 400. On Amazon Bedrock, the old tool keeps working. One codebase deployed to two clouds now needs two tool declarations, or a flag that picks one.

The figure below takes a request as it might sit in a repository today and lints it against those rules. Pick where the code is coming from and where it runs. Click a red line to apply the fix the guide gives for it.

Adaptive thinking, mechanically

"Adaptive" describes who decides. On older models you set budget_tokens and the model thought up to that budget. On Opus 5.5 the model decides whether a turn needs thinking and how much, and effort biases that decision. The effort docs are specific about the reach of the parameter: it "affects all tokens in the response," including text, tool calls and their arguments, and thinking. Lower effort means "fewer and terser tool calls." At lower levels "Claude can skip thinking entirely for simpler problems," and in a tool loop, "follow-up requests that only process tool results can still skip thinking at any level." So always-on is a floor on the mode, not on the volume. A trivial turn at low effort can produce zero thinking tokens. A hard turn at medium can produce thousands.

Three response-side changes come with it, and they break code that never touched the thinking parameter at all.

Responses begin with thinking blocks. The guide warns that code which reads the reply by position, such as content[0].text, or a stream handler that treats the first content_block_start as text, "breaks on these responses." Select blocks by their type.

The thinking is empty by default. thinking.display defaults to "omitted", so a thinking block arrives with an empty thinking field and a signature. You pay for the tokens and see none of them. Set display: "summarized" for readable summaries. If your product streams reasoning to users, the guide notes the default "appears as a long pause before output begins."

Progress notes moved. On Opus 5, the short text the model writes between tool calls came back as text blocks. On Opus 5.5 it comes back as a progress-update thinking block, at most one before each tool call, and at the default display it is empty. No request fails. An agent UI that showed "Reading the config, then running the tests" between tool calls just goes quiet. The fix is display: "updates" (beta, behind the thinking-display-updates-2026-08-18 header), which returns the progress notes while keeping reasoning hidden, or "summarized", which returns both mixed together.

And one rule that turns a UI bug into a hard failure: in a tool loop, thinking blocks must go back to the API "complete and unmodified," including empty ones. The API "rejects edited, reordered, or partially dropped thinking blocks with a 400 error." A harness that rebuilds the assistant message from its text and tool calls, which is a common way to strip what the UI does not need, now fails on the second request of every loop.

The default moved down a notch

There is a quieter change inside the effort docs. Most Claude models default to high. Opus 5.5 defaults to medium. The guide spells out the consequence: "a request that omits effort runs one level lower than it did on Claude Opus 5." Claude Code made the same move on the product side. Its v2.1.280 changelog says an effort level saved before /effort became per-model "no longer applies to newly released models such as Opus 5.5; they start at their default until you pick a level." The same release switched the default model on Pro and Team Standard plans from Sonnet to Opus.

This matters for reading the "40% less on typical workloads" claim. Anthropic does not publish the breakdown in the launch post. A 20% cut in the per-token price alone cannot produce a 40% cut in cost unless fewer tokens are spent, and a lower default effort is one lever that spends fewer tokens on every request that never set the parameter. That is an inference from the docs, not a number Anthropic states. The practical reading is the same either way: the comparison you care about is your workload at the effort you choose, measured, and the guide says as much when it asks you to "re-baseline cost and latency at your chosen effort level."

Subscribers get a different lever. The launch post says Anthropic is increasing five-hour usage limits on Pro, Max, Team, and seat-based Enterprise plans, and adds a rate-limit reset "which you can now save and use whenever you choose." The plan meters count the tokens a session spends, thinking included, which is the mechanism behind the Fable 5.1 meter complaints earlier this month. One commenter on the 1,779-point Hacker News thread put it plainly: Opus 5.5 "fills up the limit way too fast, even though they increased it."

Where the price cut runs out

For workloads that already ran Opus 5 with thinking on, Opus 5.5 is cheaper on every token class, and the comparison is easy: same tokens, lower prices. The interesting case is the other one. Plenty of production traffic ran Opus 5 with thinking: {"type": "disabled"} on purpose: extraction, classification, routing, tool-argument filling, anything where a fast, terse answer was the goal. On Opus 5.5 that traffic now thinks whenever the model judges it should, and the thinking is billed at the output rate.

The arithmetic has a clean shape. Write the request as I uncached input tokens, C cached input tokens, V visible output tokens, and T thinking tokens. With thinking disabled, Opus 5 costs 5I + 0.5C + 25V per million. Opus 5.5 costs 4I + 0.2C + 20(V + T). Set them equal and solve for T:

T_break_even = (I + 0.3 C + 5 V) / 20

Every price cut shows up in that numerator, and the output rate sits in the denominator. For a request with 6,000 uncached and 24,000 cached input tokens and 1,500 visible output tokens, the break-even is about 1,035 thinking tokens. If Opus 5.5 thinks more than that on the request, the cheaper model costs more than the old one did with thinking off. Drag the sliders to your own shape.

The rail makes the point without any claim about how much Opus 5.5 actually thinks, because that depends on your prompts, your effort level, and the task. Two practical consequences follow. First, if you disabled thinking on Opus 5 for cost, you now need a measurement before you can say whether the upgrade saved money on that route. Run a sample at low effort, read the output token counts, and put them on the rail. Second, heavy caching raises the break-even. Cheap cache reads move a lot of money into the numerator, so a long-prefix agent loop has far more room for thinking than a short, uncached classifier call does.

Routers, fallbacks, and the thinking that does not travel

Always-on thinking also changes what a conversation carries between models. The guide says that if a router or fallback moves a conversation from Opus 5.5 to another model, that model runs without Opus 5.5's thinking blocks, with Fable 5.1 and Mythos 5.1 on the Claude API as the exception. In the other direction, Opus 5.5 reads thinking from Opus 5 and earlier Opus, Sonnet, and Haiku models, but not from Fable or Mythos. A router that hops between tiers mid-conversation loses reasoning context on some hops and not others, and the table is directional.

Refusals widen too. Opus 5.5 can return stop_reason: "refusal" with a stop_details.category, and the guide lists "bio" and "reasoning_extraction" alongside "cyber". Server-side fallback exists, but it does not retry requests declined as "reasoning_extraction"; those come back to you. And one capacity note for larger customers: Priority Tier is not supported on Opus 5.5.

The same release added two things that soften the contract. Effort can change mid-conversation with a per-message output_config under the mid-conversation-output-config-2026-07-01 beta, and on Opus 5.5 that form keeps the prompt cache, where changing the top-level value restarts it. And tools can now be defined inside a mid-conversation system message under the inline-tools-2026-09-15 beta. Together they let a harness drop to low for a routine tool-result turn and climb back for a hard one, without paying to rebuild a cached prefix.

A migration order that works

1. Fix the parser before the request. Read blocks by type, echo assistant turns as received, and render non-empty thinking blocks if your UI shows progress. These changes are safe on Opus 5 too, so they can ship first.
2. Lint the request. Remove thinking, forced tool_choice, sampling parameters, and prefills. Swap the computer tool per platform. Anthropic ships a /claude-api migrate skill in Claude Code that applies these edits and produces a checklist.
3. Set effort explicitly on every route. The default moved to medium. Silence is now a choice you did not make.
4. Raise max_tokens where thinking is new. It is a hard limit on thinking plus text, and a limit sized for terse answers truncates them.
5. Measure routes that ran with thinking off. Put their real thinking counts on the break-even rail. Keep them on Opus 5 until the numbers say otherwise; it remains available as a legacy model, and the deprecations page is where its end date will appear.

Opus 5.5 is a cheaper, faster model with a longer default context, and for most agent workloads the upgrade is a clear win. The price table is the part of the launch that everyone quoted. The request contract is the part that decides the bill: a model that always thinks has turned "how much should it think" from an API switch into a measurement you own.