Claude Opus 5.5 vs Opus 5: Same Answers, Half the Output Tokens

Claude Opus 5.5 lists 20% below Claude Opus 5, at $4 per million input tokens and $20 per million output against $5 and $25. That 20% arrives whatever the model does, so the only interesting question is how much of a saving is left after you take it out. On 13 single-shot tasks at each model’s default setting, Opus 5.5 billed 65% less, and at identical prices it is still 56% cheaper. In a multi-hop tool loop the subtraction is far less kind: 37% off the invoice, 22% once the rate card is held constant.

TL;DR

• Across 468 graded calls, Opus 5.5 billed $0.0072 per task against Opus 5’s $0.0204, both correct on every task.
• Priced identically, Opus 5.5 still ran 56% cheaper on those tasks: it wrote 341 output tokens on average against 799.
• In a four-question tool loop the gap shrinks to 22% at equal prices, because input tokens dominate and both models read the same files.
• At max effort Opus 5.5 cost 3.3x its own default in that loop and solved nothing extra.
• tool_choice set to any or a named tool now returns HTTP 400; Opus 5 accepts both.

Anthropic released Opus 5.5 on 2026-09-22 claiming it “costs 40% less to run than Opus 5” on typical workloads. Only the second half of that claim, fewer tokens per task, depends on what the model does, so that is the half worth measuring.

What actually changed in Claude Opus 5.5?

The price drop is the smaller change. The bigger one is that the thinking switch is gone. Adaptive thinking means the model decides how long to reason before it answers, and those reasoning tokens are billed as output whether or not the API shows them to you. On Opus 5.5 that mode is always on, and the only control left is effort, a request parameter with five levels from low to max that sets how much thinking the model is willing to spend.

Opus 5 accepted thinking: {"type": "disabled"}, which was the single setting that brought its bill to parity with Opus 4.8 in our Opus 5 measurements. That lever no longer exists.

Two rows matter beyond the table. The default effort moved down a notch, from high to medium, so a request that sends no effort field is not running the same depth it ran on Opus 5. And the progress-update change is silent: short notes the model used to write between tool calls now arrive as thinking blocks whose text is empty unless you ask for it, so a user interface that streams those notes goes quiet with no error to catch.

What do the release benchmarks say?

Anthropic published Opus 5.5 ahead of Fable 5.1 on every coding and knowledge-work benchmark in its release table, and ahead of GPT-6 Astra on most of them. The numbers below are Anthropic’s, run with adaptive thinking at max effort, with the Terminal-Bench rows at xhigh.

Anthropic attaches an unusual caveat to its own table: at this level “benchmark margins have become a less reliable guide to real-world differences”, and the gap to Fable 5.1 is narrower in practice than the scores suggest. Two footnotes matter before anyone quotes these numbers. The AutomationBench run was done by Zapier without fallback models, so every safeguard intervention counted as a failure, and the whole table ran with production safeguards on, with cybersecurity tasks handed to Opus 4.8 and biology tasks to Opus 5 when a classifier intervened.

None of that tells you what a task costs, so we measured that.

Does the cheaper claim hold on single-shot work?

Yes, and most of it is real efficiency rather than the rate card. Single-shot means one request, one answer, no tools: arithmetic and counting puzzles such as a 200-step iteration rule or a path count on a grid with blocked cells. We ran 13 of them, 3 repeats each, at all five effort levels plus the default, on Opus 5.5 and Opus 5, which is 468 graded calls. Every answer key was brute-forced in Python before the run, and every prompt carried a unique random string so that no layer between us and the model could answer from a cached duplicate. Cost per task is computed from Anthropic list prices over the tokens each call billed, thinking included, rather than read back from the response.

Accuracy was 100% for both models at default, and 97% or better at every other level, with the three misses scattered across different tasks and levels rather than concentrated at the bottom of the ladder. On this task set there is no accuracy cliff to find, so the entire difference is spend.

The ladder behaves differently on the two models. Opus 5’s spend is flat, $0.0197 to $0.0220 from low to max, a 12% spread. Opus 5.5 spans 4x, from $0.0060 to $0.0240. Effort is a real dial on Opus 5.5 and close to a no-op on Opus 5, so a migration that copies the setting across can land somewhere quite different from where it started.

On the five hardest tasks the gap widens. Opus 5.5 at default cost $0.0113 per task against Opus 5’s $0.0375, and the median output was 585 tokens against 1,145.

What happens in a tool loop, where agent bills accumulate?

The savings survive into a loop, at a smaller multiple. A tool loop is the honest test of Opus 5.5 against Opus 5. One turn is one request: the model asks for a tool, your code runs it, and you send the whole transcript back, so a conversation of five turns pays for the growing transcript five times. Turn count, not price per token, drives that bill. We gave both models three tools (list files, read file, search) over a small synthetic service and four questions whose answers require following a call chain across three or four files, then ran 12 runs per arm on the same surface with the same tools and prompt.

Opus 5.5 at default cost 37% less per run than Opus 5 at default, with 12% fewer turns and 30% fewer output tokens. Per question solved the gap is wider, 43%, because Opus 5 missed one run. That is close to the vendor’s “40% less to run” figure, and it is the number your invoice shows.

It is also the workload where the rate card does most of the work, for a reason worth understanding: a loop re-sends the transcript every turn, both models read the same files, and total tokens fell only 19% while output tokens fell 30%. Writing less helps least exactly where you spend most. The next section puts a number on that.

Dropping Opus 5.5 to low in the loop saved nothing: the model asked for one more turn on average, and the extra re-sent transcript ate the token savings. The effort dial that works cleanly on single-shot tasks stops paying in a loop, because turns, not depth, set the bill.

How much of the saving is just the price cut?

From a seventh of it to two fifths, depending on the shape of the work. The middle column below reprices Opus 5.5’s measured tokens at Opus 5’s rates, so it shows what Opus 5.5 saves by writing less, with the rate card held constant against Opus 5.

The single-shot rows are a genuine efficiency gain: the price cut supplies only 14% of the saving, and the rest is the model writing less. The tool-loop row is the one to plan around, because it is the shape most agent traffic takes, and there the price cut supplies 41% of the headline.

Is a higher effort setting ever worth it?

Not on this workload, and the penalty is steep. Opus 5.5 at max cost $0.1087 per run in the tool loop, 3.3x its own default, and solved exactly the same 12 questions. It spent the extra budget on tool calls: a median of 12 against 5 at default, along with 3,124 output tokens against 427. On single-shot tasks max was the only level where it cost more than Opus 5, $0.0240 against $0.0220.

Reasoning is where that budget goes. Thinking was 98.4% of Opus 5.5’s output tokens at default and 99.6% at max on these single-answer tasks. You are billed for all of it at the output rate, and at the default display setting you never see it. Anthropic’s own guidance says to reserve max for frontier problems. The measured version: on tasks a model already solves, every step up the ladder is pure cost.

What breaks when you change the model ID?

Two request shapes that work on Opus 5 return 400 on Opus 5.5. Both are easy to hit in existing code.

Forced tool use is rejected. Any client that pins a tool call, which is the common way to get structured JSON out of a chat model, gets this:

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

That error arrives through an OpenAI-compatible client as well, where the same request is written as tool_choice: "required" or as a named function. auto and none still work, so the migration is to describe in the prompt when the tool applies, and to use strict tool schemas or structured outputs for schema-valid JSON.

Thinking cannot be turned off. thinking: {"type": "disabled"} and a manual budget_tokens both fail, and on an OpenAI-compatible surface the equivalent, reasoning_effort: "none", is refused too. The replacement is the effort parameter:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    messages=[{"role": "user", "content": "Summarize this incident report in five bullets."}],
    output_config={"effort": "low"},   # low | medium | high | xhigh | max; medium is the default
)

# Thinking is billed as output whether or not you can read it.
print(response.usage.input_tokens, response.usage.output_tokens)

low is the closest thing to the old thinking-off behaviour, and on our single-shot set it was both the cheapest level and accurate. It is not free, though: the model still thinks, and the thinking is still billed as output.

Do prompt budgets carry over?

Token budgets carry over exactly. The same four inputs counted the same on both models: 1,277 tokens against 1,275 for an English passage, 583 against 581 for Python, 482 against 480 for a JSON tool-argument blob, and 500 against 498 for Chinese prose. The constant two-token offset is request framing, not text, so a context budget or a chunking threshold tuned on Opus 5 needs no re-baselining on Opus 5.5.

When should you switch?

For cost, move to Opus 5.5 as soon as the two request shapes above are fixed. Even with the price cut taken out, equal accuracy at 56% less on single-shot work and 22% less in a tool loop is not a marginal difference, and default against default is the comparison most deployments will actually experience.

Treat effort as the thing to re-tune rather than carry over. The default moved from high to medium, the dial has four times the range it had on Opus 5, and the winning level depends on shape: low was cheapest and accurate on single-shot tasks, while in the tool loop the default beat both low and max.

FAQ

Is Claude Opus 5.5 really 40% cheaper than Opus 5? On the invoice, close to it: Opus 5.5 cost 37% less per run than Opus 5 in our tool loop and 65% less per single-shot task. Twenty of those percentage points are the lower rate card, which arrives no matter how the model behaves. The efficiency left after that is 22% in the loop and 56% on single-shot tasks.

Can I still disable thinking on Opus 5.5? No. thinking: {"type": "disabled"} and manual token budgets both return 400 on Opus 5.5. Use output_config.effort instead, where low is the cheapest setting. Thinking tokens are billed as output at every level.

What replaces forced tool use? Keep tool_choice: {"type": "auto"} and make the tool’s trigger explicit in the prompt, then use strict tool schemas or structured outputs when you need schema-valid JSON. On Opus 5.5 the any and named-tool forms are rejected with a 400 rather than downgraded silently, so this shows up as a failed request rather than a wrong answer.

Do I need to re-measure my prompt sizes? No. Identical text billed identical token counts on Opus 5 and Opus 5.5 across prose, code, JSON, and Chinese, so context budgets carry over unchanged.

Is Opus 5.5 a replacement for Fable 5.1? On Anthropic’s own benchmark table, Opus 5.5 scores above Fable 5.1 on every listed benchmark at 40% of its token price. Anthropic still positions Fable 5.1 for demanding reasoning and long-horizon agentic work, and says the real-world gap is narrower than the scores suggest, so the honest answer is to re-run your own evals rather than read the table.

Related measurements: Claude Opus 5 vs Opus 4.8, the GPT-6 Astra effort ladder, and thinking controls across vendors.

Measured 2026-09-23, one day after release, through a gateway to the Claude API and an OpenAI-compatible surface. 468 graded single-shot calls (13 tasks with locally brute-forced answer keys, 3 repeats, 6 effort settings, 2 models) plus 48 tool-loop runs (4 multi-hop questions, 3 repeats, 4 arms). Prompts salted; each model driven through the surface that carried its effort parameter; costs computed from Anthropic list prices rather than read from responses.

← Back to blog