Claude Opus 5.5 Is Out: The Real Cost and What Breaks

Anthropic shipped Claude Opus 5.5 on Tuesday, September 22, 2026. It's the first model in the Claude 5.5 family, the API ID is claude-opus-5-5, and it costs $4 per million input tokens, $20 per million output, and $0.20 per million cache reads. Anthropic says it performs at roughly Claude Fable 5.1's level on most work while costing 40% less than Opus 5 at default settings. Should you switch? For most agentic coding and knowledge work, yes. But your saving will land somewhere between 20% and 60%, not automatically at 40%, and four API changes will return HTTP 400 errors on code that runs fine on Opus 5 today.

That's the answer. The rest of this post covers how to work out your number before the invoice does it for you, what to fix before you flip the model ID, and the two benchmarks where GPT-6 Astra is still ahead.

Two days ago I published a breakdown of the Opus 5.5 leak and told you not to move a single budget line on it. Nothing had shipped, and every number was a rumor. Now the model is real, so it's time to check how the leak held up. I'm grading myself as well as the leakers.

One note on how this post was made. I haven't run Opus 5.5 through my own task backlog yet. It's been live for about 24 hours, and I don't publish benchmark numbers I haven't earned. What I did do: read Anthropic's announcement, the What's New page, and the migration guide line by line; re-ran the cost model from my leak post with the official prices; and wrote and tested a small script that finds the breaking changes in a codebase. Anything below that sounds like a measurement came from Anthropic or from that math, and I'll say which.

The Leak Scorecard: What the Rumors Got Right

Here's the ledger from Monday's post, updated against what Anthropic actually published.

So the pricing leak was accurate down to the cache-read line. The context-window rumor, the one that would have hurt anyone sending whole repositories, was wrong. Opus 5.5 keeps the full 1M window.

Does that make my "wait" advice wrong? I don't think so. Waiting cost you 48 hours. If you'd rebuilt client quotes around an 872K context limit, you'd be rebuilding them again this morning. Right on price and wrong on context is exactly why you check the primary source before you act.

The part the leak never covered is the part that decides your bill: how the 40% is calculated.

Where the "40% Cheaper" Number Actually Comes From

Anthropic's exact wording is that Opus 5.5 "will cost 40% less than Opus 5 on typical workloads" at default settings. Look at the price sheet next to that claim:

Every line drops by 20% except one. Cache reads drop by 60%.

That gives you a clean formula that I haven't seen anyone else write down:

Your Opus 5.5 saving = 20% + (40% × the share of your Opus 5 bill that was cache reads)

If cache reads were 0% of your bill (short one-shot prompts, long answers), you save 20%. If they were 100%, which never happens in practice, you'd save 60%. Anthropic's "40% on typical workloads" works out to a workload where cache reads make up about half the bill. That fits the announcement, which says cache reads "make up the majority of agentic and coding work costs."

This formula holds token volume constant. It covers the price change only. Effort defaults also change token volume, and I'll get to that below, because it can push your number either way.

The same math on two real session shapes

In the leak post I priced one session: 2M input tokens, 80% cached, 150K output. Here it is again with official prices, next to a second shape that looks more like a long Claude Code run: 8M input, 95% cached, 60K output. That's a big context re-read on every turn and relatively little written.

Same model, same price sheet, and the saving differs by 16 points. Session A is output-heavy, so most of its bill sits in the lines that only fell 20%. Session B is the classic agent loop: the model reads the same repo context over and over and writes comparatively little, so the 60% cache cut dominates.

Here's the formula as code, so you can run it on your own usage export instead of trusting mine:

# Estimate your Opus 5 -> Opus 5.5 price saving from last month's usage.
# Prices in USD per 1M tokens, from Anthropic's pricing page (Sept 22, 2026).
OPUS_5  = {"input": 5.00, "output": 25.00, "cache_write_5m": 6.25,
           "cache_write_1h": 10.00, "cache_read": 0.50}
OPUS_55 = {"input": 4.00, "output": 20.00, "cache_write_5m": 5.00,
           "cache_write_1h": 8.00, "cache_read": 0.20}

def bill(tokens: dict, prices: dict) -> float:
    return sum(tokens.get(k, 0) / 1e6 * p for k, p in prices.items())

# Replace with your real token counts (Console usage export or /usage in Claude Code)
my_month = {"input": 40e6, "output": 6e6, "cache_write_5m": 30e6, "cache_read": 900e6}

old, new = bill(my_month, OPUS_5), bill(my_month, OPUS_55)
print(f"Opus 5: ${old:,.2f}  Opus 5.5: ${new:,.2f}  saving: {1 - new/old:.1%}")
print(f"cache-read share of old bill: {my_month['cache_read']/1e6*0.50/old:.0%}")

The token counts in my_month are placeholders to show the shape. Put your own numbers in. Your saving will print within a rounding error of the formula above.

The volume lever: effort defaults changed

Anthropic's 40% figure is "at default settings," and the defaults moved. According to the What's New page, Opus 5.5 defaults to medium effort, where Opus 5 defaulted to high. A request that doesn't set effort now runs at medium.

That cuts two ways, and the docs say so plainly:

1. Lower default, fewer tokens. If your harness never set effort, you automatically drop a tier. That's part of how "at default settings" gets to 40%.
2. More thinking per turn at the same setting. The docs also say Opus 5.5 "tends to think more per turn than Claude Opus 5" at the same effort level, "most of all at xhigh and max." So if you pinned effort: "high" for Opus 5 and carry that over, you may spend more output tokens per turn than before. That eats into the 20% output discount.

To make the stakes concrete, I reran Session A while varying only output tokens. These are hypothetical scenarios, not measurements:

• Output unchanged at 150K: $4.92 (−25%)
• Output down a third to ~100K: $3.93 (−40%)
• Output up 20% to 180K because you pinned a high effort and it thinks more: $5.52 (−16%)

The same model can save you 40% or 16% depending on one config line. The right move, and Anthropic's own recommendation in the migration guide, is to re-run your effort sweep instead of carrying Opus 5 settings over. I made the same argument about Fable 5.1 in my Fable 5.1 price-cut breakdown. With these models, the effort setting has become a bigger cost lever than the list price.

Anthropic's blog post on what a task costs on Opus 5.5 puts one number on it: going from medium to high adds roughly 20K thinking tokens per task, about $0.40, which they compare to the cost of a single retry loop. That's a useful rule of thumb. If high effort saves you even one failed attempt per task, it pays for itself.

Price is only half of the decision, though. The other half is whether Opus 5.5 is good enough to replace what you're using now.

Claude Opus 5.5 Benchmarks: Where It Leads and Where Astra Wins

Here's Anthropic's published table, reproduced in full:

Opus 5.5 leads seven of nine rows. Here's how I read the three that matter most to me.

Terminal-Bench 4.0 is the headline. 66.4% against Fable 5.1's 55.8% is a 10.6-point lead over Anthropic's own more expensive model, and 8.5 points over Astra. This is the benchmark closest to my daily work, an agent driving a shell through multi-step tasks without drifting. In my leak post, I kept agentic coding on Claude precisely because of Terminal-Bench. That call looks even safer now.

GDPval-AA is the widest gap on the chart. An Elo of 1846 against Astra's 1542 is a 304-point lead. On knowledge-work tasks, that's a large margin, and it matches the research test in the announcement (more on that below).

FrontierCode is nearly a tie. 54.4% against Astra's 53.3% is 1.1 points. The interesting claim is the cost: Anthropic says that at default effort, Opus 5.5 beats Astra on FrontierCode "at roughly 20% of the cost per task." Astra lists at $10/$50, which is 2.5× Opus 5.5's per-token price, so a 5× per-task gap also implies Opus 5.5 uses noticeably fewer tokens per task. That's a vendor claim I'd want to confirm independently.

The two rows where GPT-6 Astra wins

AutomationBench: Astra 41.4%, Opus 5.5 40.0%. A 1.4-point gap is small enough that I wouldn't pick a model on it. Opus 5.5 did jump 13.1 points over Opus 5's 26.9% in the same table. Still, 40% means the best model on the chart fails business-workflow tasks more often than it succeeds.

Terminal-Bench-Science: Astra 64.6%, Opus 5.5 58.7%. This gap is real, 5.9 points. If you run long agentic research loops (literature pipelines, data analysis that runs experiments), Astra has the better published number. Opus 5.5 more than doubled Opus 5's 29.0%, but it isn't the leader.

Is Claude Opus 5.5 better than Fable 5.1?

On Anthropic's benchmarks, yes. Opus 5.5 scores higher than Fable 5.1 on all nine published benchmarks. Anthropic itself hedges, though: "the gap between Opus 5.5 and Claude Fable 5.1 is narrower than these scores suggest," and benchmark margins have "become a less reliable guide to real-world differences." My read: treat Opus 5.5 as roughly Fable 5.1-class at about 40% of Fable's per-token price ($4/$20 against $10/$50). It shouldn't replace Fable 5.1 outright on your hardest problems until your own tasks show it can.

One thing in this table bothers me, and I haven't seen anyone else point it out.

The Benchmark Versions Moved Under Your Feet

Three weeks ago I wrote up Anthropic's Fable 5.1 launch table. Put those numbers next to today's, for the same model:

GDPval and CursorBench changed versions between launches, so those scores aren't comparable, and you can see that from the labels. The OSWorld 2.0 partial rows are stranger. The label is the same, yet Fable 5.1 went up 2.8 points and Opus 5 went down 1.4. Different harness settings, a re-run, or a quiet revision to the suite could each explain it. Anthropic doesn't say which, and I won't guess.

Why does this matter to you? Don't mix benchmark numbers across announcements. If you made a spreadsheet in early September putting Fable 5.1 at 73.4% on CursorBench and now add Opus 5.5 at 57.8%, it will tell you Opus 5.5 is 15 points worse at agentic coding. It isn't. It's 6 points better on the new suite. Compare models only within one table.

The same caution applies to the cost claims in the text. Anthropic says Opus 5.5 "matches" Astra on Terminal-Bench 4.0 for about 40% of the cost at default effort, yet the table shows it leading Astra by 8.5 points. Both can be true if the table was run at a higher effort than the default, but the announcement doesn't state the table's effort setting. Keep that in mind when someone quotes you "beats Astra by 8.5 points at 40% of the cost." That exact combination isn't in the source.

Benchmarks are the lab's framing. The early-tester stories come closer to real work, so here's what they say.

What Early Testers Actually Did With It

These come from Anthropic's announcement. They're vendor-selected, so read them as the best cases, but the numbers are specific enough to be useful:

• A 680,000-line code migration in under a day. Anthropic says an engineering team would have needed weeks for it.
• A 200,000-line codebase audited and fixed in under three hours. Opus 5 took over 20 hours on the same job and used 2.5× as many tokens.
• HAProxy rewritten from C to Rust (internal test). Opus 5.5 and Fable 5.1 both passed nearly all of HAProxy's own regression tests. Opus 5.5 finished in 9.5 hours against Fable's 12, at 51% lower cost.
• Page load times cut across a whole web app: Opus 5.5 succeeded 39 out of 40 times. Opus 5 made smaller improvements that also changed the app's behavior.
• Grounded research reports: 16 of 18 Opus 5.5 reports cleared a grader that failed any report with an invented figure or quote. Neither Fable 5.1 nor Opus 5 cleared it on any attempt.
• Walleye Capital, an investment firm, said Opus 5.5 largely solved its evaluation suite on the lowest effort setting. On higher settings it caught an error in the evaluation instructions that no earlier model had noticed.

The 200K-line audit is the one I keep coming back to. 2.5× fewer tokens on top of a 20% price cut means that job cost roughly a third of what it did on Opus 5, before counting the cache discount. That's the volume lever from the section above, and it's why the formula alone understates the saving on long jobs. It's also why I don't trust per-token price comparisons on their own. In my Opus 5 vs Fable 5 test, the model with half the token price didn't produce half the bill, because it burned more tokens getting there.

The research-report result matters more than it looks. "Any invented figure or quote fails" is the exact failure mode that makes me reread every AI-written summary before sending it to a client. Sixteen of eighteen isn't perfect, and you still need to check the output. But the other two models went zero for everything. That gap is big enough to change whether a model's research is worth delegating at all.

Anthropic also says Opus 5.5 "communicates more naturally," puts the most important information first, and is easier to follow over long sessions. If you set up the workarounds from my Opus 5 output-style fixes for the jargon-heavy walls of text, re-test without them. You might not need them anymore.

So the model is good and the price is lower. Now for what will break when you switch.

What Breaks When You Switch to Claude Opus 5.5

The model ID swap is one line. Everything else in this section is what the migration guide calls "breaking changes for code already running on Claude Opus 5," plus one silent change the guide calls out separately.

Breaking change 1: thinking can't be disabled

On Opus 5, thinking: {"type": "disabled"} was accepted at effort high or below. On Opus 5.5, thinking is always on. Both of these now return a 400:

"thinking.type.disabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.
"thinking.type.enabled" is not supported for this model. Use "thinking.type.adaptive" and "output_config.effort" to control thinking behavior.

Fix: remove the thinking field and set output_config={"effort": "low"} wherever you had disabled thinking to save tokens. Every response can now start with thinking blocks, so read content blocks by type, never by position. Code that grabs response.content[0].text will break without a 400, because the first block won't be text anymore.

Breaking change 2: forced tool use returns 400

tool_choice: {"type": "any"} and tool_choice: {"type": "tool", "name": "..."} are rejected, including on the token-counting endpoint:

tool_choice: type "tool" and "any" are not supported for this model.

This one hurts extraction pipelines. Plenty of us force a tool call to get guaranteed-shape JSON out of an invoice or a form. Fix: keep tool_choice: {"type": "auto"}, set "strict": true on the tool definition (or move the schema to structured outputs), and say in the prompt when the tool should be used. Then handle the case where no tool gets called. With forced tool use gone, that branch can actually happen.

Breaking change 3: thinking blocks are tied to the model and the conversation

This is the subtle one, and it's what the "your agent calls might get routed to an older model" headlines are pointing at.

Every thinking block now records which model produced it. Per the docs, Opus 5.5's thinking blocks can be read by Fable 5.1 and Mythos 5.1 on the Claude API, and by no other model. If your router or fallback moves a conversation from Opus 5.5 down to Sonnet, Haiku, or even back to Opus 5, the API drops those blocks before the next model sees them. The request succeeds and you aren't billed for the dropped blocks, but the next model continues without Opus 5.5's reasoning.

Two more details:

• For accounts created on or after August 31, 2026, 00:00 UTC, replaying an Opus 5.5 thinking block after you've edited the system prompt, the tools, or an earlier message returns a 400. Keep conversations append-only. Claude Code, claude.ai, Managed Agents, and the Agent SDK already work that way. Custom harnesses that rewrite the system prompt mid-session don't.
• Opus 5.5 can read thinking blocks from Opus 5 and from earlier Opus, Sonnet, and Haiku models. Moving onto 5.5 from Opus 5 keeps your context. Moving off it, except up to Fable 5.1, loses it.

That lines up neatly with Anthropic's own routing advice in the cost blog: run daily work on Opus 5.5 and escalate to Fable 5.1 after two failures. The upward path keeps the reasoning. Downward fallbacks start fresh.

Breaking change 4: the old computer-use tool is gone on the API and Google Cloud

A computer_20251124 tool now returns 'claude-opus-5-5' does not support tool types: computer_20251124. on the Claude API and Google Cloud. Switch to {"type": "computer_toolset_20260801"} with no beta header, name, or display dimensions, and update your agent loop: the action comes back as the tool_use block's name, several actions can arrive per turn, and every result has to echo toolset_name. On Amazon Bedrock, the old tool still works.

The silent change: your progress updates go quiet

No request fails here, which is why it's the easiest one to miss. On Opus 5, the short notes the model writes between tool calls ("Reading the config now…") came back as text blocks. On Opus 5.5 they come back as thinking blocks, and at the default display: "omitted" their text is empty.

If your product streams those notes to users as a live progress feed, it will go silent between tool calls after you switch. Fix: set thinking.display to "updates" (beta, header thinking-display-updates-2026-08-18) to get the progress notes without the full reasoning, or to "summarized" to get both. Then render each non-empty thinking block before the tool_use block that follows it.

The refusal fallback

Opus 5.5 runs a biology safety classifier alongside the cyber one, and it can decline requests that try to extract its internal reasoning (stop_details.category: "reasoning_extraction"). A declined request comes back as HTTP 200 with stop_reason: "refusal". If you enable server-side fallback with fallbacks: "default" (beta), the request is retried on whatever model Anthropic recommends for that category. That's reasonable behavior, but it means a response in your logs may have come from a different model than the one you asked for. Log the model field on every response. Also note that server-side fallback doesn't retry reasoning_extraction refusals; those come back to you.

A 60-Second Audit Before You Change the Model ID

I don't like doing migrations from memory, so I wrote a small script that greps a codebase for the four breaking patterns. I tested it on a fixture with one planted example of each pattern across Python and TypeScript files. It returned six hits across the five planted lines, because one line trips two checks.

#!/usr/bin/env bash
# Flags Opus 5 -> Opus 5.5 breaking changes. Usage: ./opus55-audit.sh [dir]
dir="${1:-.}"
check() {  # $1 = label, $2 = extended regex
  hits=$(grep -rnE --include='*.py' --include='*.ts' --include='*.js' \
    --include='*.php' --include='*.go' --include='*.rb' "$2" "$dir" 2>/dev/null)
  [ -n "$hits" ] && printf '\n[%s]\n%s\n' "$1" "$hits"
  return 0
}
check "thinking disabled/manual budget -> 400" '"?type"?[:=] *"(disabled|enabled)"|budget_tokens'
check "forced tool_choice -> 400"              '"?type"?[:=] *"(any|tool)"'
check "old computer-use tool -> 400 (API/GCP)"  'computer_20251124|computer-use-2025-11-24'
check "model id still on Opus 5"                'claude-opus-5"|claude-opus-5'\''|ClaudeOpus5[^_]|CLAUDE_OPUS_5[^_]'

Here's the output against the fixture:

[thinking disabled/manual budget -> 400]
fixture/app/computer.ts:2:const cfg = { thinking: { type: "enabled", budget_tokens: 8000 }, tool_choice: { type: "any" } };
fixture/app/agent.py:3:    thinking={"type": "disabled"},

[forced tool_choice -> 400]
fixture/app/computer.ts:2:const cfg = { thinking: { type: "enabled", budget_tokens: 8000 }, tool_choice: { type: "any" } };
fixture/app/agent.py:4:    tool_choice={"type": "tool", "name": "extract_invoice"},

[old computer-use tool -> 400 (API/GCP)]
fixture/app/computer.ts:1:const tools = [{ type: "computer_20251124", name: "computer", display_width_px: 1024 }];

[model id still on Opus 5]
fixture/app/agent.py:2:    model="claude-opus-5",

Know its limits. A grep can't find a tool_choice built dynamically from a config file, and the type: "any" pattern will produce the occasional false positive in unrelated code. It won't catch the silent progress-update change or a position-based content[0] read either. Treat it as a first pass that finds the obvious cases in about a minute, not as proof that you're done.

If you use Claude Code, Anthropic's own tool goes further. The migration guide documents a bundled skill:

/claude-api migrate this project to claude-opus-5-5

According to the docs, it swaps the model ID, applies the breaking parameter changes, calibrates effort, and hands you a checklist of things to verify manually. It asks you to confirm the scope before editing any files. I'd run my grep first so you know what it should find, then let the skill do the edits, then diff. Two independent passes catch more than one.

The rollout order I'd use

1. Run the audit (the grep, then /claude-api migrate). Fix every 400 before anything else.
2. Pin effort explicitly. Don't rely on the new medium default without deciding to. Run your ten most common task types at low, medium, and high and log output tokens and pass rate for each.
3. Fix your cost tracker. On launch day, a bug was filed against New Relic's open-source preflight tool (issue #797): it recorded Opus 5.5 sessions at $0 with a 200K default context, because claude-opus-5-5 wasn't in its pricing table yet. Any tool with a hardcoded price map probably has the same gap this week. A dashboard showing $0 is worse than no dashboard.
4. Check your fallback chain. If anything downstream falls back from Opus 5.5 to a non-Fable model, accept that it will lose the reasoning, or change the order.
5. Move traffic in slices. Start with work where a bad output is cheap to catch, such as tests, docs, and internal tools, before production agents.

At this point you know your saving and what will break, which is more than most migration threads cover this week. If you'd rather have someone run this migration for you, including the effort sweep, cost logging, and fallback routing, I take on exactly that kind of engagement. You can see what I've built on Fiverr.

Who Should Switch Today, and Who Should Wait

This is how I'd decide, based on what's published so far.

Switch now:

• You run long Claude Code or agent sessions on Opus 5. Your cache-read share is probably high, so you'll likely land near the 40% end of the range, and the Terminal-Bench lead is where Opus 5.5 is strongest.
• You're on Fable 5.1 for work that isn't your hardest. At $4/$20 against $10/$50, and ahead on every published benchmark, Opus 5.5 is the obvious default. Keep Fable 5.1 as the escalation tier, which conveniently is also the one model that can pick up Opus 5.5's reasoning mid-conversation.
• You build research or reporting features. The 16-of-18 grounded-report result is the single most interesting claim in the release for anyone who ships AI-written summaries.

Wait a week or two:

• You rely on forced tool use and can't refactor extraction pipelines this sprint.
• Your product shows progress updates to end users and nobody has budgeted time for the thinking.display change.
• Your workload is short prompts with long outputs. You'll get close to the 20% floor, and Sonnet 5.5 and Haiku 5.5 are due "in the coming weeks" with many of the same improvements. They could be a better fit for that shape of work.

Look elsewhere:

• Agentic scientific research loops. Astra's 64.6% on Terminal-Bench-Science against 58.7% is the clearest published gap in Astra's favor.

On subscriptions: Anthropic says it's raising five-hour usage limits on Pro, Max, Team, and seat-based Enterprise plans, and giving subscribers a rate-limit reset they can save and use when they choose. Some coverage described this as limits being "scrapped." The announcement says "increasing," so plan around that wording.

Security teams have one more reason to pay attention. Opus 5.5 ships with a classifier that screens every action before it runs, an open-source sandbox teams can audit, and code review aimed at catching vulnerabilities before merge. On a prompt-injection benchmark run by Gray Swan, it tied Fable 5.1 for the lowest attack success rate of any model tested. If you run agents unattended for hours, that matters as much as the price.

Where I Could Be Wrong

I haven't benchmarked it myself. Every performance claim in this post comes from Anthropic. The only numbers I produced are the cost formula, the session math, and the audit script output. My first real test run starts this week, and I'll report what my own tasks show, including if they contradict the table.

The formula ignores volume. It captures the price change exactly, but real bills also move with token counts, and Opus 5.5 changes those in both directions: fewer tokens on the 200K-line audit, more thinking per turn at the same effort. Your invoice after two weeks is the only number that settles it.

Vendor case studies are selected. A 680K-line migration in a day is what a lab picks for a launch post. The median task on your codebase will be less dramatic.

My unpopular opinion: the price cut isn't the biggest story here. Anthropic released an Opus that beats its own more expensive Fable on its published benchmarks and then told everyone not to read too much into those margins. A lab playing down its own lead is rare. I read it as a signal that the real differences between frontier models have moved into things benchmarks don't capture well: token efficiency, grounding, and how easy the output is to check. That's also where the most useful claims in this launch are.

Back to Monday's Advice

Two days ago the right move was to wait. The pricing leak turned out to be accurate, the context rumor was false, and anyone who waited lost 48 hours and nothing else.

Today the right move is different: find your cache-read share. Pull last month's usage, run the formula, and you'll know whether Opus 5.5 saves you 22% or 45% before you change a line of code. Then run the audit, pin your effort level on purpose, and move one slice of traffic over.

The leak told you what the price would be. Your own usage data tells you what you'll actually save.

Let's Work Together

Looking to build AI systems, automate workflows, or scale your tech infrastructure? I'd love to help.

• Fiverr (custom builds & integrations): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (enterprise solutions): ramlit.com
• ColorPark (design & branding): colorpark.io
• xCyberSecurity (security services): xcybersecurity.io