Claude Opus 5.5: cheaper per token, unproven per task

A cheaper Opus that refuses some of your existing requests

Claude Opus 5.5 is Anthropic's replacement for Opus 5 in the same tier, announced today, API-only, no weights. For someone running Opus 5 in production, two things change at once and they pull in different directions.

The first is the invoice. By the vendor's table, input drops from $5 to $4 per million tokens, output from $25 to $20, and cache reads from $0.50 to $0.20. Anthropic's announcement states the headline this way:

It costs less per token than Opus 5 and uses fewer tokens per task, which nets out to a 40% drop in costs.

Two claims are packed into that sentence. The price per token is a fact you can read off the table. The tokens per task is a measurement, and whose workload it was measured on matters more than the percentage.

The second change is that the API no longer accepts requests Opus 5 accepted. Anthropic's What's new page lists four breaking changes: thinking can't be disabled, forced tool use returns an error, thinking blocks are tied to the model and the conversation, and the earlier computer_20251124 computer-use tool is not accepted on the Claude API and Google Cloud.

The first two are the ones most Opus 5 integrations will hit. Any request that sends thinking: {"type": "disabled"} or a manual thinking budget gets a 400. Any request that sends tool_choice of any or a named tool gets a 400. The vendor's recommended replacements are the effort parameter for the first and tool_choice: auto with strict tool use or structured outputs for the second. If you were forcing a tool call to get schema-valid JSON, that is a code change, not a config change.

A fifth change fails nothing and is easier to miss:

text between tool calls comes back in thinking blocks

At the default display setting those blocks have empty text, so an application that streams the model's progress notes to users goes silent between tool calls, with no error to catch.

The cost claim and the effort default are the same sentence

The cause is the release, and what makes it urgent is that for a good share of Opus 5 integrations migration is not optional in the way a new model usually is. The vendor's own page says code already running on Opus 5 with thinking on needs no change. Code that runs thinking disabled, forces a tool call, uses the older computer-use tool, or edits a conversation's earlier context on an account created since August 31 cannot be pointed at Opus 5.5 and left alone. Anyone on Opus 5 has to decide, and the vendor's argument for deciding yes is cost.

The qualifier on that argument is on the same page as the headline:

at default settings it will cost 40% less than Opus 5 on typical workloads

"Default settings" is doing more work than it looks. Anthropic's effort documentation says Opus 5.5 defaults to medium effort where Opus 5 defaulted to high:

a request that omits effort runs one level lower than it did on Claude Opus 5

So the vendor's 40% compares Opus 5.5 at medium with Opus 5 at high. That is a legitimate comparison of defaults. It is not a comparison of the same effort level, and the vendor's own prompting guide says what happens if you hold effort constant:

At a given level, Claude Opus 5.5 tends to think more per turn than Claude Opus 5, especially at xhigh and max.

Put those two lines together and the migration has a shape. Move and take the new default, and you are running one effort level lower than before, on a model the vendor says is stronger at that level. Move and keep your Opus 5 effort value, and the vendor itself tells you to expect longer turns and more output tokens, at a per-token price only 20% lower. The 40% is the first path. Nothing on the announcement page claims it for the second.

Three independent reports, and nobody has tested the default

The vendor's strongest evidence for per-task cost is a chart, and the vendor published it with the axis labelled.

By Anthropic's account, Opus 5.5 at default effort beats Opus 5 at max effort on Terminal-Bench 4.0 for about a fifth of the cost per attempt. That is the vendor's benchmark, the vendor's runs and the vendor's chart, and it is the strongest version of its case because it is per attempt, not per token. The announcement also names roughly two dozen launch partners who report good results. Those are vendor material. None of them published a token count.

Three parties outside Anthropic did publish something on launch day. None of them is a like-for-like test of the vendor's default-settings claim, and each shows something narrower than the headline it tends to get: a pipeline-wide token increase against a production mix, one request that hit the output cap at max, and a max-versus-max index run.

CodeRabbit ran Opus 5.5 inside its code-review pipeline and reported higher token usage in every configuration: +49.2% and +57.6% on 80 open-source bug patterns, +40.6% and +60.1% on 13 harder cases. Two conditions travel with those numbers. The baseline is CodeRabbit's own production model mix, not Opus 5, and "Standard" and "Max" are its pipeline-wide configurations, not API effort values. CodeRabbit says the first part itself:

The token increase is also a different comparison from the price reduction relative to Opus 5.

The figures come from a run summary that does not isolate input from output tokens, and they establish neither dollar cost nor latency. The post does not say whether CodeRabbit had pre-release access. What it does say is where the burden sits:

Its efficiency remains an open question, so teams should verify whether its lower token prices actually translate into lower production-review costs.

It is not a hostile review. The same post's reason to try the model is capability, not price:

The strongest reason to try Opus 5.5 is that it finds a different mix of bugs.

Simon Willison hit the other edge of always-on thinking. Asking for an SVG at max effort:

it hit the limit of 128,000 cap for output tokens while it was still reasoning about the question!

So that failed attempt on max cost me $2.56.

This is documented behaviour, not a bug. Anthropic's effort page tells you to

set a large max_tokens at the higher levels: it's a hard limit on total output (thinking plus response text)

and the migration guide confirms the cap stayed at 128k. On Opus 5 you could turn thinking off and make that ceiling irrelevant. On Opus 5.5 you cannot, so at the top effort levels a request can spend its whole budget reasoning and return nothing, and you pay for the reasoning.

Artificial Analysis ran its Intelligence Index on both models at max effort, with fallback on for Opus 5.5. Retrieved on launch day, the two pages read:

When evaluating the Intelligence Index, it generated 260M tokens, which is very verbose in comparison to the median of 88M.

When evaluating the Intelligence Index, it generated 140M tokens, which is very verbose in comparison to the median of 88M.

Opus 5.5 scored 58 to Opus 5's 51 on that index, and the same pages, as read on launch day, put the full run at $8,708.20 against $7,274.74, or $5.98 per task against $5.86. Twenty percent cheaper per token, 86% more tokens, two percent more per task. Two caveats: this is max against max, so it says nothing about the medium-effort default the vendor's claim rests on, and fallback was on, so some tasks may have been answered by another model. The same page lists output speed for Opus 5.5 as not available. Anthropic's announcement says the model generates output more than 30% faster than Opus 5. As of today no one outside Anthropic has measured that.

What has not been tested by anyone independent: the default-settings comparison itself, Opus 5.5 at medium against Opus 5 at high on a real workload. That is the one measurement that would settle the vendor's number, and it is the one you can run yourself.

There is one more disagreement, and it is between two of Anthropic's own pages. The announcement describes the new safeguards on cybersecurity, biology and distillation as

all of which fall back to another model transparently

The refusals-and-fallback documentation names Opus 5.5 in its first sentence and then describes something the caller has to set up. A decline is not an error:

When that happens, you receive a normal response, not an error, with stop_reason: "refusal".

Getting an answer from another model means opting into one of three routes: server-side fallback, SDK middleware, or a retry you write yourself. Of the first, the same page says:

Server-side fallback is in beta on the Claude API.

It goes on to say the fallbacks parameter is not supported on the Message Batches API and is not available on Amazon Bedrock, Google Cloud or Microsoft Foundry, where the SDK middleware is the route instead. Billing is written down too:

An attempt that declined before producing any output is not billed: its tokens are reported on its usage.iterations entry but not charged.

Every attempt that did produce output, including one that declined partway through, is billed at the rates of the model that ran it, and usage.iterations is the per-attempt record. When a fallback runs, the response names the model that served it. So "transparently" means visible, not automatic. A pipeline that opts into nothing and checks only for errors will read a safeguard decline as a successful call with no answer in it.

Measure tokens per finished task, then decide

The migration is a two-part job, and the order matters. First make the requests valid: drop the thinking field, replace forced tool_choice with auto plus strict tool use or structured outputs, switch to the newer computer-use toolset if you use one, and set display to updates if you stream between tool calls. Set effort explicitly rather than inheriting the new default by accident, and set max_tokens high enough at the upper levels that the reasoning has room.

Then, before any of that reaches production, run the comparison the vendor's own effort page recommends: an effort sweep on your evals rather than settings carried over. The number to record is not price per token. It is total tokens, split into input, output and cache reads, per task that actually completed, at each effort level, on your prompts. Cache reads matter more than they look: Anthropic says they make up the majority of agentic and coding costs, and they are the line that fell 60%, so a cache-heavy workload can come out ahead even if output tokens rise. A workload with little cache and long reasoning can come out behind. You will not know which you are until you count.

That comparison is a small workflow, and it is the kind of thing Latenode is built for whether or not the model under test is the point. Take the thirty prompts your product actually sends, run each through two configurations, Opus 5 at the effort you use today and Opus 5.5 at medium, and have a JavaScript node, which can install any NPM library, make both calls through the vendor SDK and record input tokens, output tokens, cache reads and wall-clock for every one. A paid plan includes 5 parallel execution workers, so the sweep runs at something like the concurrency you serve rather than one prompt at a time. The meter cooperates with the experiment: Latenode bills the CPU-seconds a run actually consumes, not per node or per API call and with no per-execution minimum, so a few hundred short comparison runs cost the seconds they take. The bill that matters is the model bill, and the sweep exists to produce that number before you commit to it.

Migrate this week if your workload is cache-heavy and you can count

Move now if three things are true: you run Opus 5 with thinking on, your traffic is agentic or coding work where cache reads dominate, and you have a way to measure tokens per completed task before and after. In that regime the vendor's price table does most of the work on its own, the default-effort drop is a bonus you can take or refuse, and the breaking changes cost you an afternoon. Take medium first. Only climb if your evals say to.

Do not move this week if any of these apply. You run Opus 5 with thinking disabled: that configuration no longer exists, and the closest substitute is a lower effort level you have not calibrated. You force tool calls to get valid JSON: that path is gone and the replacement needs testing. You run at xhigh or max: the only independent measurements at that end show more tokens, and the 128k ceiling now includes reasoning you cannot switch off. Your API account was created on or after August 31, 2026 and your pipeline edits the system prompt or tools mid-conversation: preserved thinking will reject the replay. Your traffic touches security tooling or biology: a safeguard decline comes back as a normal response with a refusal stop reason, not an error, and getting an answer from another model means opting into a fallback route, of which the server-side one is in beta on the Claude API and not offered on batches or the cloud platforms. Build the retry before you need it.

And do not move on the 40%. It is the vendor's figure for its own workloads at its own defaults, and today nobody outside the vendor has reproduced it on anything. The first independent measurement of the default-versus-default comparison on a production workload will be worth more than every benchmark on the announcement page. Until it exists, the number that decides your migration is the one you produce yourself.