Opus 5.5 vs Opus 5: cheaper and faster, not more accurate
Opus 5.5 vs Opus 5 on reasoning tasks: identical answers, 20% off list price, 11% faster output. What an independent test found, and what it cannot tell you.
Opus 5.5 vs Opus 5 on hard reasoning, in one line: same answers, less money, less waiting. An independent test at The New Stack ran both models on three reasoning problems through the API with identical prompts, and neither model out-thought the other on any of them. What changed was the bill and the clock. If you are running Opus 5 today, that is the whole decision.
Here are the figures that matter, as of 27 September 2026:
- List price. Opus 5.5 is $4 per million input tokens and $20 per million output, against $5 and $25 for Opus 5 — a 20% cut on both sides.
- Accuracy. On the two problems either model solved, both got every answer right. On the third, both failed.
- Tokens. Opus 5.5 reached the same answers on fewer output tokens — 7,573 against 10,621 on the logic grid, 28,740 against 74,981 on the stone game.
- Speed. 103.4 output tokens per second against 93.1, about 11% faster, against a claimed 30%.
What the Opus 5.5 vs Opus 5 test actually did
Jessica Wachtel called both models through the Anthropic API with identical prompts, running adaptive thinking at the default effort level because Opus 5.5 does not let you turn thinking off. Each problem ran once per model. Three problems: a seven-engineer logic grid with 22 clues, a constrained-ordering counting problem, and a stone game with move-repetition rules. Input tokens, output tokens, list-price cost and wall-clock time were logged for every call, with thinking tokens counted as output because that is how they are billed.
| Problem | Opus 5.5 | Opus 5 |
|---|---|---|
| Logic grid | 28/28, 1:05, 7,573 out, $0.16 | 28/28, 1:48, 10,621 out, $0.27 |
| Constrained orderings (48k cap) | No answer, 8:09, 48,000 out, $0.96 | No answer, 9:13, 48,000 out, $1.20 |
| Constrained orderings (128k cap) | No answer (refusal), 18:56, 112,733 out, $2.26 | No answer, 25:24, 128,000 out, $3.20 |
| Stone game | 3/3, 3:35, 28,740 out, $0.58 | 3/3, 10:24, 74,981 out, $1.88 |
| Total | $3.95 | $6.55 |
The saving is real, and most of it is not the price cut
Anthropic's claim was 40% cheaper and more than 30% faster. The list price accounts for exactly half of the cost claim: $4/$20 against $5/$25 is 20%. The rest has to come from the model spending fewer tokens to reach the same place, and on this test it did. Opus 5.5 came in 43% cheaper on the logic grid and 69% cheaper on the stone game, where it used 62% fewer output tokens for the identical answer.
That distinction matters more than it looks. A list-price cut applies to every workload you have. A token-efficiency saving applies only where the model was doing extended thinking in the first place. If your production traffic is classification, extraction or short structured responses, you get the 20% and very little of the rest — the thinking was never the expensive part. We make the same point about where open-weight and frontier spend actually goes: the headline rate is rarely where the money is.
Does Opus 5.5 use fewer tokens?
On these three problems, yes, and by a wide margin on the hardest one it solved. But "fewer tokens" is a property of how the model chose to think about a specific problem, not a guaranteed ratio. The same test shows the ceiling: on the counting problem both models burned every token of a 48,000-token budget and then a 128,000-token budget without producing an answer. Fewer tokens on average does not mean bounded tokens.
The speed claim did not survive contact
Across every call, Opus 5.5 wrote 103.4 output tokens per second against Opus 5's 93.1 — about 11% faster, with a best single-problem lead of 19%. Anthropic's claim was more than 30%. Wall-clock time told a friendlier story, because Opus 5.5 finished sooner by writing less: 65 seconds against 108 on the logic grid, 215 against 624 on the stone game. Both things are true at once, and which one you care about depends on whether you are paying for latency or for tokens.
What one author with one run cannot tell you
Give this test its proper weight before you act on it. Three problems is not a benchmark. Each problem ran once per model, so there is no variance figure — on a model doing adaptive thinking, a rerun can differ from itself. The author states the intent to rerun any problem where the models disagreed, and they never disagreed, which is a reasonable protocol but not a sample. Only reasoning tasks were tested; Anthropic's own benchmarks covering coding and knowledge work were not rerun, so "not more accurate" means "not more accurate on these three reasoning problems".
Two more caveats that cut in different directions. Neither model had a code execution tool, which is why the counting problem — whose third answer is 159,019 orderings — was unreachable by reasoning alone. And on the 128,000-token rerun, the Opus 5.5 response ended with a "refusal" stop reason and no text on a prompt about counting job orderings, which the author reads as a safety filter misfiring. One incident is one incident. It is also the kind of failure that never appears in an accuracy score and shows up in your error budget.
What to do with this
If you run Opus 5 in production, moving to Opus 5.5 is the cheap decision: the same answers on hard reasoning, for less. Three things to do alongside the model swap.
- Set a hard
max_tokens. Both models can think for 19 to 25 minutes and return nothing while billing every thinking token as output. Uncapped extended thinking on an unsolvable problem is the most expensive way to get no answer. - Give the model a tool for the work it is bad at. A counting problem wants code execution, not more thinking budget. This is a prompt-and-tooling fix, not a model choice.
- Re-price your cached traffic. Cache reads on Opus 5.5 are $0.20 per million tokens, 5% of base input, where Opus 5 charges $0.50 at the usual 10%. For an agent replaying a long system prompt on every turn that is a 60% cut on the line item the reasoning tests never touch — worth modelling before you assume 20%. Our note on prompt caching as an LLM cost cut covers the mechanics.
Batch traffic follows the same 20% shape, at $2/$10 per million against $2.50/$12.50. Fast mode, in research preview, is $8/$40 against $10/$50.
The migration itself is not free of edges: we wrote up the four things Opus 5.5 breaks for agents separately, and that list, not the price, is what will cost you a day. Run your own eval on your own traffic before you switch — a three-problem test by one author is a reason to schedule that eval, not a substitute for it. In the AI systems we build, the eval that decides a model swap is the one built from the customer's own logged requests, and it is usually cheaper to assemble than the first week of a wrong choice. That is the work our AI engineering practice starts with, and it is the same reasoning we apply to what an AI agent actually costs to build.
Frequently asked questions
Not on the reasoning tests published by The New Stack. Both models solved the logic grid with all 28 cells correct and answered all three parts of the stone game correctly, and both failed the constrained-ordering problem. The test covered reasoning tasks only, with one run per problem.
Claude Opus 5.5 lists at $4 per million input tokens and $20 per million output, against $5 and $25 for Opus 5 — a 20% cut. The larger savings observed in testing, 43% and 69% on two problems, came from Opus 5.5 spending fewer output tokens.
On the published tests, yes. Opus 5.5 used 7,573 output tokens to Opus 5's 10,621 on the logic grid, and 28,740 to 74,981 on the stone game, reaching identical answers. Token efficiency varies by problem, though, and both models exhausted a 128,000-token budget on one task.
If you run Opus 5 today, Opus 5.5 gives the same results on hard reasoning for less money and less waiting. Set a hard max_tokens limit first, because both models can think for over twenty minutes and return nothing while billing every thinking token as output.
Not by output rate in this test. Opus 5.5 wrote 103.4 tokens per second against Opus 5's 93.1, roughly 11% faster, with a best single-problem lead of 19%. Wall-clock times were much better because Opus 5.5 wrote fewer tokens, not because it wrote them faster.
Three reasoning problems, one run per model, one author, no code execution tool, and no rerun of Anthropic's coding or knowledge-work benchmarks. It is a useful signal with published token counts, not a benchmark. Run your own evaluation on your own logged traffic before switching.
