Opus 5.5: 40% cheaper to run, 20% off per token

On September 22, 2026, Anthropic released Claude Opus 5.5. The first sentence of the official announcement says it is the first model in the Claude 5.5 family, performs at the level of Claude Fable 5.1 on most work, and costs 40% less to run than Opus 5.

This site’s September 23 version was written the day after launch and focused on price and a time-limited usage reset. For this rewrite I reread the announcement, the help center page on the reset, and the developer migration guide. The old version’s main numbers were broadly right, but three things need adding or changing. Its results table listed only three tests that Opus 5.5 won, while the full table has nine, and GPT-6 Astra leads on two. I could not find an official source this time for the quote about subscription limits going “25% further” or for the pledge not to retire the model before September 2027. And the old version’s explanation of where the 40% comes from was incomplete.

What does the full results table look like?

Figure 1: The full table in the announcement; the two grey cells are where GPT-6 Astra leads (source: Anthropic)

The old version listed only Terminal-Bench 4.0, FrontierCode and GDPval-AA, which happen to be three that Opus 5.5 tops. I put all nine into one table, keeping only the comparison with Fable 5.1 and GPT-6 Astra.

Figure 2: Who is ahead on each of the nine tests (data: Anthropic)

Opus 5.5 leads on seven of the nine. The two it loses are AutomationBench for business workflows (40.0% against 41.4%) and Terminal-Bench-Science 0.1 for agentic scientific research (58.7% against 64.6%).

Several caveats written by the company itself go with this table.

Directly below the table, Anthropic says that at these levels of capability, benchmark margins have become a less reliable guide to real-world differences, and that in its own use the gap between Opus 5.5 and Fable 5.1 is narrower than these scores suggest. It is unusual for a company launching a model to volunteer “do not trust my scores too much”.

Opus 5.5 was evaluated with its production safeguards enabled. When they intervened, cybersecurity tasks were completed by Claude Opus 4.8, and biology and frontier LLM development tasks by Opus 5, which the company says likely reduces the scores. AutomationBench was run by Zapier without fallback models, so a safeguard intervention counted as a failure, and that cell is lower than it would be in practice.

The standard error on Terminal-Bench 4.0 is plus or minus 2.6 points for Opus 5.5. Its lead over Astra is 8.5 points, well beyond the error. Several figures for GPT-6 Astra and GPT-5.6 Sol are as reported by OpenAI and were not rerun by Anthropic in the same setup.

This reads more clearly next to the scorecard of the previous Fable 5.1. Back then Fable 5.1 led Opus 5 by only a few points outside the science benchmark. Three weeks later the lower-positioned Opus 5.5 has passed Fable 5.1 on most rows.

How is the 40% arrived at?

Figure 3: Prices per million tokens, side by side (source: Anthropic)

There are three numbers for the change in unit price. Input falls from $5 to $4 and output from $25 to $20, both down 20%. Cache reads fall from $0.50 to $0.20, down 60%. The glossary covers the basics of token pricing.

On the 40%, the announcement says tests show that at default settings it will cost 40% less than Opus 5 on typical workloads. Another passage gives the reason: it costs less per token and uses fewer tokens per task, which nets out to a 40% drop.

So the 40% has two sources, the price cut and token savings. The old version covered only the first and attributed the remainder to caching and speed. I worked out how much the price cut alone delivers.

Figure 4: How far the bill falls from the price change alone, assuming exactly the same number of tokens (calculated for this article; prices from Anthropic)

The arithmetic is simple. Suppose cache reads make up a share c of your old bill, and the rest is input, output and cache writes. On Opus 5.5 the cache part becomes 40% of what it was and the rest becomes 80%, so the new bill is 0.8 minus 0.4c. The reduction is 20% plus c times 40 percentage points.

Two things can be read off the table. If you hardly use caching, as with single question-and-answer calls, you get 20% and not 40%. To reach 40% on price alone, cache reads would have to be half of your old bill. The announcement says cache reads make up the majority of agentic and coding work costs, so heavy users of coding agents may see 40% or more from price alone, and with the “fewer tokens” the announcement mentions, the real reduction could be larger.

“Fewer tokens” so far rests on statements by the company and early customers. Several testimonials in the announcement give figures: Box says it used a third of the tokens Opus 5 did, Optiver says about half, and another says 20% to 25% fewer output tokens. The spread is wide, which suggests the saving depends on the kind of work. I have not tested it.

One thing pushes the bill the other way, and it shows up in the migration guide in a later section: thinking cannot be turned off on Opus 5.5, and thinking tokens are billed as output. A workload that used to run with thinking disabled may produce more output tokens after the switch.

The announcement also says Opus 5.5 generates output more than 30% faster than Opus 5. There is a fast mode at up to 2.5 times the speed, priced at $8 per million input tokens and $40 per million output tokens. Sonnet 5.5 and Haiku 5.5 are to follow in the coming weeks.

What did subscribers get?

The announcement states two things: higher five-hour usage limits on Pro, Max, Team and seat-based Enterprise plans, and a rate limit reset for subscription users that can be saved and used whenever they choose. It gives no figure for how much the limits rise. The glossary explains what usage limits are.

Here the old version quoted a line about limits going “25% further”, described as the words of the official developer account, and explained it as 1 divided by 0.8 equals 1.25. I could not find a source for that quote this time. The arithmetic only holds if subscription limits are measured in cost, and I have not seen that premise stated on an official page either. So this time I do not treat 25% as an official figure. For the background to the mid-September change in Claude Code’s weekly limits, this site has a separate write-up.

The rules of the reset are set out clearly on the help center page.

Figure 5: The help center article “What is a limit reset?”, captured October 13, 2026 (source: Claude Help Center)

Using it takes three steps: open Usage under Settings on the web or in Claude Desktop, click “Reset for free” in the Resets section, and click once more to confirm. The same button appears on the message you see when you reach a limit.

Some rules that are easy to miss:

• Depending on the reset shown, either the five-hour limit or the weekly limit goes back to full. The weekly limit itself still resets on its usual day and time.
• You do not have to wait until you reach a limit, but once you use it you cannot undo it.
• The button is not currently available in the mobile app or in Claude Code in a terminal or IDE, so you have to use a browser or Claude Desktop. Limits are shared across your account, so after resetting on the web they are back to full on mobile and in Claude Code too.
• A reset does not refund extra usage already billed or change your usage credit balance.
• If you downgrade or cancel before using it, the reset is no longer available.

The wording on the expiry date needs correcting. The old headline said “use it before October 22”. What the help center says is that if your reset has an expiry, the date is shown in Settings under Usage, and that an unused reset expires on the day and time listed on the offer. I saw a screenshot of the interface in third-party coverage showing “Expires Oct 22”, but the official page does not fix that date. So go by what your own account shows. If it is indeed October 22, nine days remain from October 13, when I rewrote this piece.

What do API developers have to change before switching?

The old version listed five changes that return a 400 error. I checked them against the official migration guide. All five are there, and I added some details the old version left out.

Figure 6: The request conditions listed in the migration guide (source: Claude Platform Docs)

Thinking cannot be turned off. thinking: {"type": "disabled"} and manual thinking budgets both return a 400. Adaptive thinking is always on, and you can only send no thinking field or send {"type": "adaptive"}.

Effort is the only control, and its default changed. The five levels are low, medium, high, xhigh and max. The default is medium, where Opus 5’s is high. If you relied on the default, thinking depth quietly becomes shallower after the switch. The guide recommends setting it explicitly and running a fresh sweep on your own evals instead of carrying over a setting tuned for an earlier model.

Tool calls cannot be forced. A tool_choice of any or a named tool returns a 400. The guide recommends auto with strict tool use or structured outputs, and saying in the prompt when the tool applies.

The computer use tool changed. On the Claude API and Google Cloud you must declare computer_toolset_20260801, and the earlier computer_20251124 is rejected. The old version missed an exception: on Amazon Bedrock you keep the earlier one.

Thinking blocks must be returned unmodified. In a tool-use loop, the thinking blocks from each assistant response must be passed back complete and unmodified, including blocks whose content is empty. The API rejects edited, reordered or partially dropped blocks.

Three more things raise no error but change how your program behaves.

Responses begin with thinking blocks. Code that reads the reply by position, such as taking content[0].text directly, breaks. The guide tells you to select blocks by their type field.

Thinking text is omitted by default, so blocks arrive with an empty thinking field and a signature. The short notes the model writes between tool calls now also sit in thinking blocks. If your interface shows progress from that text, it will go quiet after the switch without any error. The guide’s fix is to set thinking.display to summarized.

max_tokens covers thinking plus response text. Workloads that ran with thinking disabled need this value rechecked, and the guide suggests starting at 64k for xhigh or max effort.

The context window is 1 million tokens by default with no extra header needed. The model ID is claude-opus-5-5, available on the Claude Platform, AWS, Google Cloud and Microsoft Azure. The old version gave an output limit of 128K and said the company promised not to retire the model before September 22, 2027. I did not find either in the pages I read this time, so both are removed.

How does this launch relate to “pacing the frontier”?

The announcement makes the link itself: Opus 5.5 is Anthropic’s first release since it called for pacing the frontier. This site has a write-up of that essay and the responses to it.

The announcement says the model was tested before release by external evaluators and names Frontier Design and METR. That is pre-release testing, which is a different thing from what Amodei’s essay promised, namely evaluators embedded long-term with employee-like access. On the latter the announcement says only that the infrastructure has started to be put in place and that more details will follow.

The most specific safety figure is this: in a new evaluation of a model’s propensity to cross containment boundaries, Opus 5.5 attempted to circumvent boundaries around 85% less often than Opus 5 or Claude Mythos 5.1, and every attempt it made was low severity and self-reported.

The announcement also includes a less comfortable sentence. The company sees signs that Opus 5.5 often suspects it is being evaluated, which makes it hard to assess how it will act across the variety of real-world settings. It expects this challenge to grow unless interpretability research makes progress.

The safeguards cover more than on earlier Opus models. This is the first Opus model to launch with safeguards in the same class as Fable 5.1’s: most cybersecurity tasks are re-routed to Opus 4.8, and biology research work requires applying to the Life Sciences Verification Program. Finding and fixing bugs during ordinary development is not affected.

My read, and what would change it

I think the significance of this launch for most people lies in price and not in scores. Anthropic itself says score margins no longer reflect real differences well. A model that is cheaper than its predecessor and no worse than the flagship on most work becoming the default on paid plans is a real change for people who use it every day.

Where I hold back is the 40%. It is a figure the company measured at default settings on typical workloads, and it mixes two factors, the price cut and token savings. Anyone can compute the price part. The token part is something you have to measure yourself.

What would change my view? If an independent evaluation at the same token budget reproduces Opus 5.5 completing the same work with fewer tokens, I would treat 40% as a dependable estimate. If many users report that bills did not fall after switching, or that output tokens surged because thinking cannot be disabled, then 40% applies only to particular usage patterns. If Sonnet 5.5 arrives with the same efficiency at a lower price point, the positioning of Opus 5.5 will shift again.

There are two things to do now. Subscribers: open Settings and Usage on the web, and check whether the reset is there and what its expiry date is. API users: before switching, search your code for thinking, tool_choice and content[0], the three places most likely to cause trouble.

What this rewrite corrected

• The results table was completed. The old version listed only three tests that Opus 5.5 led. The full table has nine, and GPT-6 Astra leads on AutomationBench and Terminal-Bench-Science.
• The source of the 40%. The old version attributed the gap between a 20% lower unit price and 40% lower cost to caching and speed. The announcement says it is the price cut plus fewer tokens per task.
• “25% further” is no longer treated as an official figure. I could not find the source of that quote, nor a statement that subscription limits are measured in cost.
• The wording on expiry. The help center says the expiry date is shown on your settings page. The October 22 date comes from an interface screenshot in third-party coverage.
• Two untraceable points were removed. The 128K output limit, and the pledge not to retire the model before September 22, 2027.
• New material. The company’s own reservations about how reliable the scores are, the effect of safeguards on scores, the bill calculation from price alone, the Bedrock exception for the computer use tool, the requirement to return thinking blocks unmodified, the model often suspecting it is being evaluated, and the difference between pre-release testing and embedded evaluators.