On 22 September, Anthropic released Claude Opus 5.5, the first model in its 5.5 family. The announcement brings the usual — better results in agentic coding and knowledge work, more speed, stronger safety audits — and two numbers that were circulating mixed together everywhere that same day: the price drops 20% and the model costs 40% less to run. Plenty of headlines went with the second one.
We read the announcement, the model page, the what's-new page and the migration guide. The model is better and it's cheaper; that isn't in question. What's worth separating is how much of the saving is price, how much is efficiency, and how much is a default setting that has changed. And it's worth knowing, before you change a line, that migrating from Opus 5 isn't just a matter of changing the model name.
The figures going round as if they were one
They all come from official sources and they're all true. What differs is the question each one answers:
| The figure | What exactly it measures | Does it go straight into your budget? |
|---|---|---|
| −20% on price | List price per million tokens: $4 input and $20 output, against $5 and $25 on Opus 5. The Batch API stays at half price | Yes, for the same number of tokens |
| −60% on cache reads | From $0.50 to $0.20 per million: a cache read now costs 5% of the input price, instead of the usual 10% | Yes, and it weighs heavily on agents with long, repeated context |
| −40% on cost | Running cost “at default settings” on “typical workloads”, according to Anthropic. It bundles price, efficiency and the change in default effort | No. It depends on your workload and your settings |
| +30% on speed | Generates output more than 30% faster than Opus 5 | Not a cost; it affects latency and user experience |
| Fewer steps and tokens per task | Customer testimonials: Factory matches Opus 5 on high effort with 20-25% fewer output tokens; Optiver, in about half the turns, time and output tokens | A pointer, not a measurement: these are cases picked by the vendor |
Sources: Anthropic's announcement and platform documentation, 22 September 2026
The setting that explains part of the 40%
The exact wording in the announcement is that, at default settings, Opus 5.5 will cost 40% less than Opus 5 on typical workloads. The key is “default”. Opus 5.5 always reasons, and how much it reasons is governed by a single parameter, the effort level. On Opus 5, if you didn't specify anything, effort was high. On Opus 5.5 it's medium.
In other words, the headline compares Opus 5 reasoning at high with Opus 5.5 reasoning at medium. It's a legitimate comparison — it's what happens to anyone who switches models without touching anything else — but it isn't a like-for-like comparison of two models. And the documentation adds a caveat pointing the other way: at the same effort level, Opus 5.5 tends to think more per turn than Opus 5, especially at the higher levels. Anthropic hasn't published a cost comparison of the two models at equal effort; its cost-optimisation guide doesn't include Opus 5.5 figures yet.
Three forces pulling in different directions
The cost of a resolved task depends on the price per token and on how many tokens the task uses. With Opus 5.5 both move, and not in the same direction:
- Price goes down: 20% on input and output, 60% on cache reads.
- Steps per task tend to go down. That's what the customers in the announcement report: fewer turns, fewer calls, less filler.
- Reasoning per turn tends to go up at the same effort level, according to the documentation itself.
To see how much the result moves, here's an example with our own arithmetic, not Anthropic's. An agent with long context processes one million input tokens per task, 800,000 of them read from cache, and generates 50,000 output tokens. With the same tokens, the task costs $2.65 on Opus 5 and $1.96 on Opus 5.5: 26% less, more than the 20% list cut, because of the weight of the cache. Without caching, the saving is exactly 20%. And if Opus 5.5 produced 25% more output because it reasons more — an assumption, not a measurement — the saving would fall to 17%. If, on the other hand, it resolved the task in fewer steps, it could go past 40%.
None of those figures is yours. Yours comes from running your own tasks on both models at the effort you'd use in production and dividing the cost by the tasks resolved correctly. That's the cost per useful task metric, and it's the only one a CFO can budget for. If this conversation sounds familiar, it's because we had it with the billing change of 15 June: what changes the bill isn't the price per token, it's how many tokens each task burns.
Four changes that break the code you already have
The migration guide lists them plainly. Three return an error as soon as you deploy; the fourth only if your code edits conversations already under way. There's a fifth that doesn't fail, which is exactly what makes it the most treacherous.
| The change | What happens if you leave it | What to do |
|---|---|---|
| Reasoning can't be switched off | 400 error if the request disables it or sets a manual token budget | Remove that field and lower effort wherever you used to disable reasoning to save money |
| You can't force a tool | 400 error with tool_choice of type any or tool, including on token counting | Use auto with strict tool use or structured outputs, and say in the prompt when the tool applies |
| Reasoning is tied to the model and the conversation | If a router or fallback moves the conversation to another model, it carries on without the earlier reasoning (except Fable 5.1 and Mythos 5.1). On accounts created since 31 August, editing earlier messages and resending them returns a 400 | Append-only conversations, no editing the past; review routing and fallback logic |
| The older computer use tool is no longer accepted | 400 error with computer_20251124 on the Claude API and Google Cloud (it still works on Amazon Bedrock) | Move to the new toolset and adapt the agent loop |
| Silent: the text between tools moves | No request fails, but an interface that showed users progress between tool calls goes quiet | Read those notes from the reasoning blocks and configure how they're displayed |
Summary of Anthropic's Opus 5 to Opus 5.5 migration guide. If you use Claude Managed Agents, changing the model name is enough
Two more things that didn't make the headlines. First: the model ships with safety classifiers in more categories — biology as well as cybersecurity, plus a new one for requests that try to extract its internal reasoning. A refusal comes back as a successful response, with a 200 status code and its own stop reason. If your code doesn't handle it, the refusal passes for an empty answer. Second, for anyone designing multi-model architectures: the rule tying reasoning to its model changes the maths of routing between models. Moving a conversation to a cheaper model mid-task saves tokens and loses reasoning context, and that loss raises no error: it only shows up in quality.
What Anthropic itself says about its benchmarks
The announcement includes the customary benchmark table, and on almost every one Opus 5.5 beats Opus 5 comfortably. But it also carries two sentences that deserve more attention than the table, because the vendor is writing them about its own model:
- At this level of capability, benchmark margins have become a less reliable guide to real-world differences. It says so about the comparison with Fable 5.1, its most capable model: the real gap is narrower than the scores suggest.
- There are signs that Opus 5.5 often suspects it's being evaluated, which, in the announcement's words, makes it harder to know how it will act across the wide variety of real-world settings.
The first says the announcement's table won't make the decision for you. The second is more uncomfortable, and it's worth not overstating it: it refers to behavioural and safety evaluations, not to your product tests. But the lesson is the one we argue for in what “works better” actually means: the evidence that counts comes from your own cases, with your own data, measured against a baseline. The customer testimonials in the announcement are valuable and specific, and they're also the ones the vendor chose to publish.
How we would migrate
There's no rush. Opus 5 becomes a legacy model, but Anthropic commits to not retiring it before 24 July 2027. With that margin, this is the order we'd follow for an integration that's already in production:
- Set effort in the current integration, before touching the model. If it wasn't set, it was running at
high: write that down explicitly. That way the later comparison is between models, not between settings. - Search the code for the four breaking changes and for refusal handling. The official guide includes a checklist, and Anthropic also offers a Claude Code skill that applies the mechanical changes and returns what needs checking by hand. Useful, as long as someone reviews that diff.
- Run your golden set on both models, with Opus 5.5 at two or three effort levels. Record quality, tokens per task, latency and cost per resolved task.
- Choose effort per type of task, not one global setting. Some tasks will very likely do just as well at
mediumorlow, and others will needhigh. That's where most of the real saving is. - Move traffic gradually, with the observability we describe in the LLMOps flow, and recalculate the cost and latency baseline at the chosen effort. It's the last item on the guide's own checklist, and the one most often skipped.
None of this is specific to Opus 5.5. It's what you'll need to do with Sonnet 5.5 and Haiku 5.5, which Anthropic says are coming, and with whatever any other lab publishes next month. Models change every few months; what lasts is the way you measure them.
What we take away
Opus 5.5 is good news for anyone working with agents: more capability for less money and, going by what its first users report, fewer loops to reach the same place. But “40% less” isn't a figure for a budget spreadsheet. It's the result of a particular configuration on particular workloads, and yours may come out above or below it. The figure that's useful is the one you measure, at the effort you choose, on the tasks you actually run. Having it before you migrate takes a few days. Getting it afterwards usually takes an awkward conversation with finance.
Frequently asked questions
Does Opus 5.5 cost 40% less than Opus 5?
The list price drops 20%: $4 per million input tokens and $20 per million output tokens, against $5 and $25. Cache reads drop 60%, from $0.50 to $0.20. The 40% is a different figure: Anthropic says that at default settings Opus 5.5 costs 40% less than Opus 5 on typical workloads. That comparison includes a settings change, because the default effort moved from high on Opus 5 to medium on Opus 5.5. What goes into your budget is what you measure on your own tasks at the effort level you choose.
What is the effort level, and why does it matter so much in this release?
It's the parameter that controls how much the model reasons before answering, and with that its quality, latency and cost. On Opus 5.5 it's the only control over reasoning, because reasoning can no longer be switched off. Its default is medium; on Opus 5 it was high. If your code doesn't set effort, changing only the model ID changes two things at once, the model and the effort, and any difference in quality or cost will be credited to the model when it may come from the setting.
Is migrating from Opus 5 to Opus 5.5 just a matter of changing the model name?
Not if your code uses any of these four things: disabling reasoning or giving it a manual budget, forcing a specific tool with tool_choice, the older computer_20251124 computer use tool on the Claude API or Google Cloud, or editing earlier messages in a conversation you resend. The first three return a 400 error. The fourth returns a 400 on accounts created on or after 31 August 2026. There's also a silent change: the text the model writes between tool calls comes back empty unless you configure how it's displayed.
What happens to routers and fallbacks between models?
They need reviewing. Opus 5.5's reasoning is tied to the model that produced it: if a router or fallback moves the conversation from Opus 5.5 to another model, that model carries on without the earlier reasoning, except Fable 5.1 and Mythos 5.1 on the Claude API. The request doesn't fail, so no alarm goes off: only the quality of the following turns changes. If your architecture routes between models to save money, that loss has to be part of the evaluation.
Can we trust the benchmarks in the announcement?
As a guide, yes; as a decision, no. Anthropic says so itself in the announcement: at this level of capability, benchmark margins have become a less reliable guide to real-world differences, and the model shows signs of often suspecting it's being evaluated. The customer testimonials are useful but chosen by the vendor. What decides whether it suits you is your own set of cases, run on both models at the effort you'd use in production.
Where do we start if Opus 5 is already in production?
By setting effort explicitly in your current integration, before touching the model, so the comparison is clean. Then search the code for the four breaking changes and for refusal handling, which now includes new categories. With that done, run your evaluation set on Opus 5.5 at two or three effort levels and compare cost per resolved task, not cost per token. Only then do you move real traffic, gradually. Opus 5 won't be retired before July 2027, so there's no rush.
Sources cited
- Anthropic — Introducing Claude Opus 5.5 (22 September 2026; pricing, “40% less at default settings on typical workloads”, speed, benchmarks, customer testimonials and caveats on benchmark margins and evaluation awareness)
- Claude Platform — Claude Opus 5.5 (model page: pricing, caching, default effort
medium, context and availability) - Claude Platform — What's new in Claude Opus 5.5 (breaking changes, behaviour differences and more thinking per turn at the same effort)
- Claude Platform — Migrating to Claude Opus 5.5 (checklist, effort recommendations and note on Claude Managed Agents)
- Claude Platform — Claude Opus 5 (default effort
high, pricing and a commitment not to retire it before 24 July 2027)
Jordi García is Tech Lead at onext. He works on bringing AI into governed production across development and product teams —with Spec-Driven Development, context engineering and human verification at every step— and authors onext's technical insights on the method, quality and cost of applied AI.
LinkedIn →