What changed on 22 September
Anthropic released Claude Opus 5.5 on 22 September 2026. The headline for most teams is not the model, it is the price line underneath it.
- API list price is $4 per million input tokens and $20 per million output tokens. That is 20% below Opus 5, which listed at $5 and $25 — a rate that had held across every prior Opus release.
- Cache reads are $0.20 per million tokens, which Anthropic describes as 60% cheaper than Opus 5 cache reads.
- Fast mode is available in Claude Code and on the Claude Platform, runs up to 2.5 times faster, and is priced at $8 and $40 per million tokens.
- Anthropic's framing is roughly 40% less to run on typical token-billed workloads — an effective-cost claim, not a list-price claim.
- Availability is broad from day one: the Claude Platform, Amazon Web Services, Google Cloud and Microsoft Azure.
- Anthropic says Opus 5.5 performs at roughly the level of Claude Fable 5.1 on most work.
The Opus line holding $5 and $25 across successive releases is the part worth pausing on. For most of the last two years, the pattern at the top of Anthropic's range was more capability at the same price. Opus 5.5 breaks that pattern in the direction buyers have been asking for, and it does so while the company is reported to be heading toward an IPO at around a $2T valuation. Make of that what you will; the pricing page is the only part you can act on.
The two numbers, and why they are not the same number
A 20% list cut and a 40% effective cut are both honest statements about different things, and conflating them is how a budget forecast goes wrong.
The 20% is contractual. It applies to every customer, on every call, from the day it takes effect, with no work on your side. If you change nothing at all — same prompts, same tools, same traffic — your token spend drops by a fifth. You can put that in a spreadsheet and defend it in a finance review.
The 40% is conditional. Anthropic attributes the gap to two behaviours of the new model rather than to price: Opus 5.5 uses fewer tokens per task, and it generates output more than 30% faster. Fewer tokens per task is the part that touches cost directly — you are billed per token, so a model that reaches the same answer with less generated text and fewer correction loops costs less to run even at an unchanged price. The speed figure mostly touches latency, and only touches cost indirectly, through things like shorter agent sessions and fewer timeouts.
The distinction matters because token efficiency is a property of the pairing between a model and a workload, not a property of the model alone. A tightly-scoped classification endpoint with a fixed output schema has very little slack to remove. A long-running coding agent that reasons, retries, reads files and corrects itself has a great deal. The same release can therefore deliver 20% to one team and something much closer to Anthropic's framing to the team sitting next to them.
Do not put an effective-cost claim into a budget as if it were a price change. Forecast the 20%, because that is the part the vendor has committed to. Treat anything beyond it as a measured improvement you report after the fact, with the measurement attached. Finance teams forgive a conservative forecast that comes in early. They remember the other kind.
The pricing table, side by side
All figures are per million tokens, in US dollars, at list.
| Model / mode | Input | Output | Cache read |
|---|---|---|---|
| Claude Opus 5 | $5.00 | $25.00 | $0.50 (implied by the stated 60% reduction) |
| Claude Opus 5.5 | $4.00 | $20.00 | $0.20 |
| Claude Opus 5.5 — fast mode | $8.00 | $40.00 | Not stated |
The Opus 5 cache-read figure in that table is arithmetic, not a quoted price: Anthropic has stated the reduction as 60%, and $0.20 is 40% of $0.50. We have marked it as implied rather than presenting it as a published rate, and you should treat it the same way in any document that leaves your team.
The cache line is the one most teams will underweight and should not. Cache reads dominate the input side of any system with a large stable prefix — a long system prompt, a fixed tool schema, a document held across turns. If that describes your architecture, a 60% cut on the cheapest line in your bill can move the total more than the 20% cut on the headline line, because of how much of your volume sits there. We went through the mechanics of this when the cache price moved on the previous generation, in Claude Fable 5.1's cache price change and the three things it broke.
A worked example, with the assumptions labelled
The numbers below are illustrative. The volumes are assumed, not observed, and they exist only to show the shape of the arithmetic. Substitute your own figures from your own billing export before making any decision.
ASSUMED VOLUME: 50 million input tokens and 10 million output tokens a month, with caching set aside.
The bankable case
On Opus 5, that volume costs 50 × $5 for input, or $250, plus 10 × $25 for output, or $250. Total: $500 a month.
On Opus 5.5 at the same volume, it costs 50 × $4, or $200, plus 10 × $20, or $200. Total: $400 a month. That is the 20%, and it arrives without you touching a line of code.
The conditional case
Now assume — again, illustratively — that the new model completes the same work using a quarter fewer tokens, so the volume falls to 37.5 million input and 7.5 million output. The bill becomes 37.5 × $4, or $150, plus 7.5 × $20, or $150. Total: $300 a month, which is 40% below the Opus 5 baseline.
That is the whole story in one line of arithmetic. Reaching Anthropic's framing on this assumed workload requires roughly a 25% reduction in tokens per task on top of the list cut. Whether your workload delivers that is an empirical question about your prompts, your retries and your tool loops. It is not something anybody can tell you from a pricing page, and it is precisely the question that cost per successful task, rather than cost per token exists to answer.
Where cache reads change the picture
Add caching and the ranking of your line items can invert. A team whose input is 80% cache reads is paying most of its input bill at $0.20 rather than $4, so the 60% cut on that line does more work than the 20% cut on the rest. A team with no cache hits at all sees none of it. Two teams, one release, two genuinely different outcomes — which is the recurring lesson of every price change in this market.
Before you model anything, pull last month's actual token split from your billing export: input, output, cache write and cache read, broken down by feature. Most teams discover their bill is shaped nothing like their intuition, and that a single unglamorous endpoint is carrying half the spend. Rebuild the forecast on that split, the way forecasting an LLM bill before launch sets out, rather than on an average price per call.
How to verify which number applies to you
This is a one-afternoon exercise, and it is the difference between quoting a vendor and knowing your own numbers.
Fix a representative task set
Take twenty to fifty real tasks from production — real tickets, real repositories, real documents, with known good outcomes. Generic benchmarks will not help here, because you are not measuring the model in the abstract, you are measuring the model against your prompts. Freeze the task list, the tool definitions and the retry policy so that the model is the only variable that changes between runs.
Measure tokens per completed task
Per-call token counts are close to meaningless for agentic work, because a run that takes nine cheap calls to fail is worse than one that takes three expensive calls to succeed. Record input tokens, output tokens and cache reads per completed task, and count the failures separately. A model that costs marginally more per success and fails half as often is cheaper, and a per-token comparison will tell you the opposite. Our walkthrough of benchmarking coding agents on your own repository covers the harness mechanics if you have not built one.
Measure wall-clock separately
Keep latency in its own column. The more-than-30% faster output generation shows up as wall-clock time per task, and it is worth real money in some places and nothing at all in others. For an interactive coding surface or a customer-facing chat, it is a product improvement. For an overnight batch job in a Manchester data team or a nightly reconciliation run in Pune, it is a rounding error. Mixing latency into a cost figure is how teams end up justifying fast mode for workloads nobody is waiting on.
Most articles here carry a Verified Builder byline. Want your name on the next one?
AI Tech Connect lists AI engineers, founders and researchers across India and the UK — and the people hiring browse it to find them. Adding your profile is free.
Become a Verified Builder →Fast mode is a latency purchase, not a cost decision
At $8 and $40 per million tokens, fast mode costs double standard Opus 5.5 and is priced above Opus 5 on both lines. Anthropic is not pretending otherwise: it is sold on being up to 2.5 times faster, and it is available in Claude Code and on the Claude Platform.
Treat it as a separate decision with a separate justification. The question is not whether faster is nicer — it always is — but whether you can name what a second of saved latency is worth on a specific surface. For a developer waiting on a coding agent, the answer is usually yes, because the cost of the wait is a salary. For a queue-backed pipeline, the answer is almost always no. The failure mode here is enabling fast mode globally because it felt like an upgrade, then discovering a doubled bill on workloads where nobody noticed the speed.
One migration caveat worth flagging
The New Stack has reported a caveat for teams moving to the new model: agent calls may end up silently routed to an older model. We have not independently verified this, and it is a reported caveat rather than established fact — but it is the kind of thing that is cheap to check and expensive to miss.
It matters more than a normal migration niggle for one specific reason. If some share of your traffic is quietly running on the previous model, every measurement in the section above is contaminated, and you will draw conclusions about token efficiency from a mixture of two models. Log the model identifier returned on every response, aggregate it by day, and confirm that 100% of the calls in your comparison ran where you think they ran. This is good practice regardless of whether the report holds up.
Assert the model in your evaluation harness, not just in your dashboard. A run whose responses came back from an unexpected model should fail loudly rather than quietly contributing a data point. Silent routing is not unique to any one vendor, and the cost of catching it is one line of code.
What this means for builders in India and the UK
Broad availability is doing quiet work in this release. Opus 5.5 landing on the Claude Platform, Amazon Web Services, Google Cloud and Microsoft Azure together means that for most teams in Bengaluru, Hyderabad, London or Edinburgh, the procurement conversation is a question of which existing commitment absorbs the spend, not whether a new vendor can be onboarded at all. If you already have committed cloud spend, running it through the cloud you are committed to may be worth more than the list cut itself.
Currency is the second thing worth attending to on both sides. These are dollar prices. An Indian startup settling in rupees and a UK scale-up settling in pounds both carry an exchange-rate line that moves independently of Anthropic's pricing page, and a 20% cut can be meaningfully eroded or amplified between the announcement and the invoice. Model the saving in the currency you actually pay in, and re-check it each quarter.
For teams in India serving high-volume consumer traffic, the token-efficiency question is usually the one that matters more than the list price, because volume multiplies every inefficiency in the prompt. For UK teams selling into regulated buyers, the more interesting consequence is procedural: a model swap is a change to a production system, and the evaluation evidence you gather while verifying the cost claim is the same evidence your assurance process will ask for. Run the comparison once and use the output twice.
Anthropic also says Opus 5.5 performs at roughly the level of Claude Fable 5.1 on most work, which is a capability statement worth testing rather than accepting, in exactly the way we treated the equivalent claim in our look at Opus 5 topping the intelligence index at half the cost. Roughly comparable on most work is not the same as comparable on your work, and your task set is the only instrument that can tell the difference.
What to do this week
- Forecast the 20% and only the 20%. Update the budget line with the list-price change, because it is the part that is committed. Leave the rest out of the forecast until you have measured it.
- Pull the token split by feature. Input, output, cache write, cache read. The cache-read cut is worth more than it looks to anyone running a large stable prefix, and worth nothing to anyone who is not.
- Run twenty to fifty real tasks on both models. Compare tokens per completed task and wall-clock per task, with failures counted separately. Assert the model identifier on every response so a silent route to an older model cannot contaminate the result.
- Decide fast mode per surface, never globally. Enable it where somebody is waiting and the wait has a cost you can name. Leave it off for batch.
The honest summary is unglamorous. A fifth off the top of the Opus line is a real, bankable improvement, and the first movement in that price across several releases. The rest is a claim about efficiency that may well be true of your workload, and the only way to find out is to measure it on your own tasks. Teams that can show the measurement will have something more durable than a cheaper invoice: a repeatable way to price the next model release, which is coming sooner than any of us are budgeting for.