Claude Opus 5.5 vs Claude Opus 5: The Effort Levels Do Not Mean the Same Thing

The first thing to know before comparing Claude Opus 5.5 against Claude Opus 5 is that the two models do not share an effort scale, and almost every head-to-head you will read this week ignores that. Opus 5 defaults to high effort. Opus 5.5 defaults to medium, and at the same named level it thinks more per turn than its predecessor did. So "Opus 5.5 at default versus Opus 5 at default" is not a controlled experiment — it is a comparison between two different amounts of thinking. The vendor says as much in its own migration guide: test multiple effort levels, and do not reuse Opus 5 settings, because the same-named levels do not map to the same thinking budget. Once you control for that, the gap between the two models narrows in some places, widens in others, and the upgrade decision turns on something other than raw capability — cost per finished task, and four API changes that will break code that runs on Opus 5 today.

What actually differs, spec for spec

The two models are closer on paper than the version numbers suggest:

• Price — Claude Opus 5.5 at $4.00 input / $20.00 output per million tokens vs Claude Opus 5 at $5.00 / $25.00

• Cache read — $0.20 per million vs $0.50 per million, a 60% cut on the line item that dominates agentic runs

• Cache write — $5 per million for the 5-minute window and $8 for the 1-hour window on 5.5, against $6.25 on Opus 5

• Context and output — 1M tokens of context and 128K of output on both; both reach 300K output on the Batch API behind the output-300k-2026-03-24 beta header

• Default effort — medium on Opus 5.5 vs high on Opus 5

• Thinking — adaptive and always on in both, but on Opus 5.5 it can no longer be disabled at all

• Knowledge cutoff — June 2026 vs May 2026

• Latency — Anthropic rates Opus 5.5 "moderate" against the current lineup, and says it generates output more than 30% faster than Opus 5

• Retirement — not sooner than September 22, 2027 for Opus 5.5, and not sooner than July 24, 2027 for Opus 5

Note what is not different: context window, output ceiling, batch discount, and the always-on adaptive thinking model. Opus 5.5 is not a bigger-context or longer-output model. It is a cheaper, faster, more token-efficient one on the same envelope.

Benchmarks, and the effort asterisk on every one of them

These figures are from Anthropic's launch material — vendor-reported, run against its own models — and the effort setting matters more here than the model name:

• Terminal-Bench 4.0 — 66.4% vs 52.3%, with the Opus 5.5 run at xhigh effort rather than the default

• FrontierCode v1.1 (Main) — 54.4% vs 48.0%, and 54.6% for Opus 5.5 at the default medium effort

• CursorBench 4.0 — 57.8% vs 46.6%, and 52.5% at medium

• GDPval-AA v2.1 — 1846 Elo vs 1708

• AutomationBench — 40.0% vs 26.9%

• Humanity's Last Exam, with tools — 67.7% vs 63.6%

• Terminal-Bench-Science 0.1 — 58.7% vs 29.0%, the widest gap in the set

• OSWorld 2.0 — 81.8% partial vs 74.0%

• Chartography, with tools — 89.0% vs 83.4%

The FrontierCode result is the one to study. Opus 5.5 scores 54.4% at xhigh and 54.6% at medium — statistically the same number, at a fraction of the thinking budget. Whatever improvement Anthropic made, on that benchmark it is not coming from thinking harder. CursorBench moves the other way: 57.8% at xhigh against 52.5% at medium, a five-point spread that says effort still buys real accuracy on some tasks. The lesson is not "use medium" or "use xhigh"; it is that the right effort level is now a per-workload measurement, and the old habit of leaving Opus 5 on its high default no longer tells you anything about the new model.

Anthropic adds a caveat worth repeating: at this capability level, benchmark margins are "a less reliable guide to real-world differences," and the company says its internal gap to Claude Fable 5.1 is narrower than the published scores imply. That is a vendor telling you not to over-read its own table.

Cost per finished task is the comparison that decides it

Per-token price is the wrong unit for an agent, and this matchup is where that shows. Anthropic's own worked example: a merger analysis that took Opus 5.5 63 minutes and cost 50% less than the same task on Opus 5, which took 93 minutes. The rate card explains part of that — a 20% cut on input and output, 60% on cache reads — but not all of it. The rest is the model using fewer tokens and fewer turns to reach the same place. Customer quotes published with the launch point the same direction: Box reports a third of the tokens and answers around 40% less verbose, Kiro roughly half the tokens with 40% fewer calls, Factory 20–25% fewer output tokens, GitHub among the fewest tokens and steps it has measured.

Those are vendor-published customer statements, not audited results, and the aggregate "about 40% cheaper on typical workloads" is Anthropic's characterisation of an average across workloads it selected. The honest version for your own planning: assume the 20% sticker cut is real and bankable, treat the extra 20% as a hypothesis you can test in an afternoon by running the same task on both models and counting tokens.

One structural note on why the cache cut punches above its weight. An agent that re-sends a long system prompt and a file tree every turn pays cache-read rates on the bulk of its input, not fresh-input rates. Dropping that from $0.50 to $0.20 per million changes the economics of long-running sessions far more than the headline rate does — and it is the reason a workload that was marginally viable on Opus 5 can become clearly viable on Opus 5.5 without any change to your prompts.

The four breaking changes, as a migration checklist

Opus 5.5 is a new model, not a renamed Opus 5, and Anthropic's migration notes list four changes that will break code already running in production:

• Thinking cannot be disabled. Any code path that turned thinking off will error or change behaviour, and depth is now controlled only through the effort parameter.

• Forced tool use returns an error. A tool_choice that forces a named tool is not supported.

• Thinking blocks are tied to the model that produced them and to the conversation, so they cannot be replayed across models the way some pipelines assume.

• The earlier computer_20251124 computer-use tool is not accepted on the Claude API or on Google Cloud.

There is a fifth change that fails nothing and is therefore more dangerous. Text between tool calls now returns inside thinking blocks whose text is empty at the default display setting. If your application streams that text to users as progress updates, it goes quiet between tool calls until you set a display value that returns the text. Every test passes; the interface just stops narrating.

The first three also apply to Claude Fable 5.1, so a team that has already migrated to that model has done part of this work. A team still on Opus 5 has not.

When Opus 5 is still the right call

The upgrade is not automatic, and there are four real reasons to stay:

• Cost predictability. Opus 5 is a model you have already characterised. If your budget is modelled on its token consumption, moving to a model that thinks a different amount at the same named effort level invalidates the model until you re-measure.

• Compatibility. If any part of your stack depends on disabling thinking, forcing a tool, or the older computer-use tool, the migration is code work, not a string swap.

• Safeguard routing. Opus 5.5 ships with Fable 5.1-class safeguards, which means most cybersecurity requests are re-routed to Claude Opus 4.8 and biology work falls back to Claude Opus 5 unless your account is verified. If your product is in either domain, "upgrading" can mean your users get answers from a smaller model. Opus 5 does not have that routing.

• Longevity. Opus 5 is not going anywhere soon — Anthropic lists retirement as no sooner than July 24, 2027, which is ten months out.

For everyone else the arithmetic is straightforward: more capability, lower price, fewer tokens, and a migration checklist that a single engineer can work through in a day.

Running both during the switch

The awkward part of any flagship migration is the middle: you want Opus 5.5 on new traffic without betting the production path on a model you have not characterised at your own effort settings, and you want to keep Opus 5 serving while you find out. That is a routing problem rather than a re-platforming one, and it is worth being precise about what sits where. Claude Opus 5 is on OrcaRouter today at Anthropic's own list price with 0% markup — provider list price passed straight through, so a vendor rate change is live on our side the same day rather than after a sync. Claude Opus 5.5 is not one of our routes yet; it is available through Anthropic's own API and the major clouds. When it lands it becomes one more route on the same key instead of a second contract and a second SDK, which is what lets you put a percentage of traffic on the new model while automatic failover keeps the rest on the one you have already characterised. Composing a call across both — a draft from one and a verification pass from the other — is a routing-DSL line.

Be precise about what that buys you. It does not give you an independent benchmark of Opus 5.5; nothing does yet, because the only published head-to-heads are Anthropic's own and the independent trackers are still settling on effort configurations. What it gives you is the one measurement that is actually predictive of your bill, on your prompts, at the effort level you will ship.

The decision rule

If you are starting something new, use Claude Opus 5.5 and start at medium effort, then measure whether low holds up on your task — Anthropic reports that low approaches its higher settings on several coding evaluations at much lower cost, and the FrontierCode numbers above suggest the default is not leaving much on the table.

If you are running Claude Opus 5 in production, the trigger to migrate is not the benchmark table. It is whether you can absorb four API changes and whether your workload sits in cybersecurity or biology, where the safeguard routing will quietly hand some of your traffic to a smaller model. Everything else about this upgrade is a price cut wearing a model release's clothes, and those are worth taking.