Claude Opus 5.5 vs Opus 5: what changed, measured

Anthropic released Claude Opus 5.5 on September 22, 2026, two months after Opus 5. The announcements are full of percentages, so I did what I do for my harness essays: read the release docs, then ran both models side by side. Every claim in this essay that could be tested on my machine was: live probes of the API changes, the same agent task run on both models with a deterministic verifier, and the same cached prompt billed on both meters.

Claude Opus 5.5 vs Opus 5: the spec sheet

Claude Opus 5.5 is the successor to Claude Opus 5 in Anthropic’s Opus line: the same 1M-token context window, the same 128K output ceiling and the same tokenizer, at a 20% lower price and — per Anthropic’s own measurement — with output over 30% faster. It is not a new capability tier. It’s the same tier with a cheaper meter, a newer knowledge cutoff, and a few developer controls removed.

Everything else carries over: prompt caching, batch at half price, PDF and vision input, structured outputs, strict tool use, task budgets. Both models stay available on the Claude API, AWS, Google Cloud and Microsoft Foundry, and Opus 5 isn’t retired.

The headline claim from the launch post frames the rest: Opus 5.5 costs about 40% less to run for typical workloads — more than the 20% list-price cut, with the deeper cache-read discount and fewer tokens per task making up the difference. A second claim comes from Anthropic’s cost-optimization docs and got amplified in launch coverage: on a SWE-bench Pro subset, 5.5 at medium effort matched Claude Fable 5.1, Anthropic’s top model, at a fraction of the cost per solved task. The 40% claim is testable on a small scale, and I test it below. The Fable comparison isn’t, not on my budget, so treat that one as vendor benchmark talk.

The price cut targets re-reading, not writing

The API is stateless. Every turn of an agent session resends the entire conversation so far: the system prompt, the tools, every earlier message, every tool result. Turn 50 re-reads 49 turns of history to write one new step. I measured this pattern in my agent loop essay: the number of turns is the cost of a task, because each turn pays for all the turns before it.

Anthropic published the aggregate version of that observation with the 5.5 launch. Between March and September 2026, context per request across their developer traffic grew 2.6×, and the ratio of tokens read to tokens written went from 189:1 to 324:1. Read that literally: for every token the model writes, it reads 324, and almost all of them are the same history it read last turn.

That’s what prompt caching exists for: the unchanged prefix is served from cache at a fraction of the input price instead of being reprocessed. At a 324:1 read-to-write ratio, cache reads aren’t a line item on the bill. They are the bill. Which explains the lopsided pricing: input and output dropped 20%, cache reads dropped 60%, from $0.50 to $0.20 per million tokens. Anthropic repriced the exact line the traffic shift inflated. (This isn’t vendor-specific economics: OpenAI and Google discount cached input too, at 50–90% depending on the model. The shape of the bill is industry-wide; 5.5 just leans into it harder than anyone.)

I ran the numbers on my own meter. Same request on both models: a 21,559-token system prompt (a station ops manual with raw sensor data) marked with cache_control, then three short questions in a row. Call 1 writes the cache; the follow-ups read it.

claude-opus-5    call 1: input=22 cacheWrite=21559 cacheRead=0     out=122  $0.1379
claude-opus-5    call 2: input=21 cacheWrite=0     cacheRead=21559 out=7    $0.0111
claude-opus-5    call 3: input=24 cacheWrite=0     cacheRead=21559 out=23   $0.0115
claude-opus-5-5  call 1: input=24 cacheWrite=21559 cacheRead=0     out=75   $0.1094
claude-opus-5-5  call 2: input=23 cacheWrite=0     cacheRead=21559 out=7    $0.0045
claude-opus-5-5  call 3: input=26 cacheWrite=0     cacheRead=21559 out=23   $0.0049

The first call tracks the 20% list-price cut ($0.138 against $0.109). Every call after it costs 2.4× less on Opus 5.5, and that multiplier applies to the bulk of a long session. This is the “40% cheaper for typical workloads” claim, mechanically: the deeper your session, the more of your bill is cache reads, the closer your saving gets to 60% rather than 20%.

The flip side: when cache reads are that cheap, a cache miss hurts relatively more. Breaking the cache means re-reading the whole history at $4 instead of $0.20, a 20× penalty per token. Everything in my context engineering essay about ordering, stable prefixes first, changing content last, gets more valuable on this model, not less.

Four request shapes that stop working

Code running on Opus 5 can hit four hard breaks on 5.5. Three of them make the API reject the whole request with an error — an HTTP 400; the transcripts below show two of them live — instead of running the model. I probed the two most likely to bite — the thinking switch and forced tool choice — on both models and kept the transcripts (plus budget_tokens, which both models reject); the computer-use rejection and the thinking-block rules below are from Anthropic’s docs, which I didn’t independently probe.

thinking-disabled    claude-opus-5    OK   stop=end_turn  blocks=[text]
thinking-disabled    claude-opus-5-5  400  "thinking.type.disabled" is not supported for this
                     model. Use "thinking.type.adaptive" and "output_config.effort"
                     to control thinking behavior.
forced-tool-choice   claude-opus-5    OK   stop=tool_use  blocks=[tool_use]
forced-tool-choice   claude-opus-5-5  400  tool_choice: type "tool" and "any" are not
                     supported for this model.
auto-tool-choice     claude-opus-5    OK   stop=tool_use  blocks=[text,tool_use]
auto-tool-choice     claude-opus-5-5  OK   stop=tool_use  blocks=[tool_use]

The thinking switch is welded on

On Opus 5 you could turn reasoning off entirely for latency-sensitive routes. On 5.5 you can’t: thinking is always on, and effort is the only depth control. The practical consequences are small but real. Size max_tokens for the thinking plus the reply, because thinking counts against the limit even though its text isn’t returned by default. And read response content by block type, never by position, because every response can open with thinking blocks.

Forced tool calls are gone

tool_choice: {"type": "any"} and {"type": "tool", "name": ...} were the API’s way of saying “you must call this tool right now”. 5.5 rejects both. The replacement is auto plus an instruction in the prompt, with strict: true on the tool so the arguments stay schema-valid — the pattern I use throughout my tool design essay. The hard guarantee is gone though: auto means the model can decide not to call, so the harness has to check whether the call happened and retry if not. My probe shows the behavioral gap is small in the easy case. Asked for Paris weather with a weather tool available, both models called it. Opus 5 wrote a sentence first; 5.5 went straight to the call. If what you actually wanted from a forced call was JSON in a fixed shape, that use case didn’t get harder: structured outputs still guarantee schema-valid responses.

Thinking blocks stop being portable

Every thinking block now records which model produced it, and the API enforces who can read whose. Anthropic calls it preserved thinking.

The failure mode to design for: any architecture that switches models mid-conversation, a router, a retry on another model, a fallback on refusal, now continues without the reasoning that got the conversation to that point. The request succeeds. Nothing errors. The follow-on model just knows less than you think it does. There’s a second half: the API also checks that nothing before a thinking block was edited after the fact. Accounts created on or after August 31, 2026 get that check enforced by default; older accounts keep the lenient behavior until they opt in. If your harness rewrites history, injects reminders and deletes them, swaps system prompts mid-session, it breaks on this model. Append-only histories were already the right call for cache hit rates; now they’re load-bearing.

The old computer-use tool is rejected

Narrowest of the four: the computer_20251124 tool is rejected on the Claude API and Google Cloud (Bedrock still accepts it), and the computer_toolset_20260801 toolset is the only path. This is a real migration, not a rename. The toolset changes the agent loop: actions arrive as separately named tool calls, several per turn, and every result must echo toolset_name. If you run computer use, do that migration on Opus 5 first, where both forms work, then flip the model ID.

Effort is the only lever left, and its default dropped

On Opus 5 you had two dials: whether to think, and how hard. On 5.5 the first dial is gone, so effort carries everything: thinking depth, latency and cost. OpenAI’s reasoning_effort and Gemini’s thinking budgets are the same lever under other names; Anthropic already runs Fable this way, and 5.5 brings the same always-on posture to the Opus line.

The default change is the sneakiest line in the release notes: a bare model-ID swap quietly lowers how hard the model works. Anthropic’s defense is that the levels don’t map one to one: its docs say 5.5 thinks more per turn at any given level, and its published numbers put 5.5’s medium at the level of its top model’s default on a coding benchmark subset. Whether medium is enough for your work is the question — and it’s the one my runs below poke at. Whatever you find on your own workload, the advice is the same: set effort explicitly and re-run your sweep, don’t carry the old setting over on faith. One genuinely new convenience: a per-message effort change (beta) lets you raise or lower effort for a single turn without invalidating the prompt cache. Changing the top-level effort between requests invalidates the cache on any model; on one whose economics are built on cache reads, not paying that reset is worth having.

There’s one more response-shape change here, easy to miss and unpaid: the short notes the model writes between tool calls, “found the bug, checking the tests next”, arrive on 5.5 as progress-update thinking blocks instead of text blocks. At the default display setting their text is empty. A UI that renders only text blocks goes quiet for the whole length of an agentic turn, with no error anywhere. Set thinking.display to "updates" (beta) or "summarized" to get them back. My runs hit exactly this, next section.

Nine runs, same task, both models

Claims about “fewer tokens per task” are cheap to make and cheap to test. I reused the weather-station task from my agent memory essay: a small Node.js project whose sensor log records dropouts as -999 sentinel rows. The agent must write a monthly-rollup script that reports correct averages, which requires noticing the sentinels and excluding them. Miss the trap and the July mean comes out at -20.6°C instead of 18.4°C. A deterministic verifier checks the output against truth values computed outside the agent’s reach.

Same frozen harness, same six tools, same prompt, fresh project copy per run, max_tokens 16000. Three arms, three runs each, at list prices with no caching, so costs are upper bounds. Small samples; treat these as one measured data point, not a benchmark.

Both models solved the task every single time. The trap didn’t separate them; the meter did.

# excerpt — 4 of 9 runs; the other five are in the table's means
opus5-default-2    PASS turns=13 tools=20 in= 62798 out= 4538 $0.427 70s
opus5-default-3    PASS turns=11 tools=15 in= 46621 out= 4035 $0.334 63s
opus55-default-2   PASS turns= 6 tools=11 in= 17697 out= 2596 $0.123 31s
opus55-default-3   PASS turns= 6 tools=11 in= 19442 out= 2662 $0.131 33s

Three things fall out of the table:

The saving is 63%, and the price cut is the smaller half of it. Run Opus 5’s token counts through 5.5’s prices and the average run would cost $0.294 — that’s the 20% list-price cut. The actual 5.5 runs cost $0.135, because the model also used 54% of Opus 5’s turns and 64% of its output tokens. Fewer turns compound: every turn you don’t take is a whole history you don’t resend, which is why input tokens fell hardest, 52K to 20K. Anthropic promised 40% cheaper for typical workloads. On this task, at defaults, I measured better than that. One task, three runs per arm — but the direction and the mechanism both check out.

Where the turns went: same stumble, less ceremony. Reading the transcripts side by side, both models found the sentinel trap in the README and excluded it correctly — and both tripped over the same project quirk: the existing report.js is written as an ES module, so running it plainly errors, and one run of each model wrote its first draft the same way and had to fix and re-run it. The 5.5 run that hit it diagnosed the error and recovered in a single turn. The durable difference is what happened after the numbers were right. Opus 5 kept paying for verification: in every run it re-derived the averages with an independent shell one-liner and computed the sentinel-included mean for contrast, and one run checked the date range on top. That’s 16.7 tool calls per run against 11.3. The 5.5 runs did a quick sanity check and stopped. From one of them, verbatim, the entire mid-task narration:

[opus55-default-2, turn 5 of 6]
Sentinel rows (-999) must be excluded, per the README and FAQ. I'll filter
per field, which is robust even if a future row has only some columns at -999.
→ write_file monthly.js · run_command node monthly.js (+ an awk check in the same command)
[turn 6] PASS · $0.123 · 31s

Raising effort to high bought nothing here. The medium default passed 3/3 already; high also passed 3/3 while costing 23% more. On this task, 5.5’s medium did everything Opus 5’s high did — one measured data point for the level shift — and a reminder that the right move after migrating is to sweep effort on your own workload rather than reflexively restoring the old default.

Where the between-tool narration went

The docs warn that 5.5 moves its running commentary into thinking blocks. My transcripts show the quieter version of that story: on this short task, both models mostly worked in silence. The three default-effort 5.5 runs carried 2–4 thinking blocks each whose text came back empty (the default display: "omitted" at work), and across all three runs the visible mid-task narration totalled three short text blocks. Opus 5 wrote a little more along the way — eight mid-task notes across its three runs — and about a quarter more final-summary text. If your UI streams the model’s between-tool commentary, the practical difference is real but this task was too short to make it dramatic; on long multi-minute turns, the docs’ warning stands: set thinking.display or go quiet.

One methodology note, in fairness to both models: my verifier initially flagged one run of each model as leaking sentinels into its output, when both had computed everything correctly and merely printed a label like “averages exclude -999 dropouts”. A poisoned average lands around -20 to -60, never at exactly -999, so I tightened the check to ignore the literal constant. The numbers above use the tightened verifier everywhere.

When to switch, and what to check first

The switch is worth it sooner than most model upgrades, because the price cut compounds with the efficiency gain on exactly the workloads Opus gets used for. But it’s a migration, not a model-ID swap. My checklist, in the order things will actually bite:

1. Grep for the removed request shapes: thinking.*disabled, tool_choice.*(any|tool), computer_20251124 — and budget_tokens if your code predates Opus 5, which already rejected it. Each has a mechanical replacement (shown above), and they all fail loudly, which is the good kind of breaking change. The fourth break — thinking-block portability — is silent and ungreppable; that’s item 4 below.
2. Set effort explicitly. The silent default drop from high to medium is the change most likely to alter your output quality without a single error. Sweep low/medium/high on your own tasks; on mine, the defaults verdict is in the table above.
3. Check your UI for the quiet-agent bug. If you stream text between tool calls to users, you’ll ship a model upgrade and get “is it frozen?” tickets. Set thinking.display before flipping the model.
4. Audit anything that switches models mid-conversation. Routers, refusal fallbacks, cost-based downgrades: on 5.5 they keep working but silently lose the accumulated reasoning. Either pin sessions to one model or accept the drop knowingly.
5. Know the new refusal surface. 5.5 adds biology and reasoning-extraction safety classifiers on top of cyber. Everyday health questions are unaffected, but if your workload touches dual-use bio research, or your prompts push the model to reproduce its internal reasoning as visible text (a common old workaround for thinking-off routes), expect stop_reason: "refusal" and handle it before reading content.

Who should stay on Opus 5 for now: computer-use integrations that can’t do the toolset migration yet, harnesses that rewrite conversation history and can’t go append-only quickly, and anything contractually pinned to forced tool calls as a hard guarantee. Opus 5 keeps being served; nothing forces the move this quarter.

For the official word: Anthropic’s what’s-new page is the closest thing to a first-party comparison of the two models, the migration guide has every breaking change with before/after code, and the Opus 5 announcement is the baseline the marketing percentages are measured against.

The one-line version: Opus 5.5 is Opus 5 with the meter rebuilt around what agent traffic actually does, re-read the same growing history hundreds of times, and with the developer overrides removed in favor of the model’s own judgment. The 60% cache-read cut is the release. The rest is migration homework.