24 September 2026 · 6 min read

Opus 5.5 is a cost story, not a leaderboard story

Anthropic says its new model costs 40% less to run than Opus 5, but the price list only explains half of that. The rest has to come from the model finishing the same work in fewer steps, and that's the part worth testing.

By Dr. Aki Wijesundara, TAI Labs

The usual way to judge a new model is to open the benchmark table, find the row closest to your work, and decide from there. It's the wrong first move. A leaderboard tells you how a model scores. Your invoice tells you whether an upgrade pays for itself, and with Claude Opus 5.5, which Anthropic released on September 22, the invoice is where most of the news is.

The 40% cut has two parts, and only one is on the price list

Anthropic says Opus 5.5 costs 40% less to run than Opus 5 on typical workloads, and that it generates output more than 30% faster. Open the pricing table and the change looks smaller. Input tokens go from $5 to $4 per million, output from $25 to $20, and cache writes from $6.25 to $5. That's a 20% cut. Cache reads fall further, from $0.50 to $0.20, which is 60% off, and it matters most to agents that re-read the same long context on every turn.

So where does the remaining saving come from? Do the arithmetic. Cost per task is price per token multiplied by tokens per task. If the price factor is 0.80 and the total is 0.60, the token factor has to be 0.75, which means the model finishing the same work with about a quarter fewer tokens. That's an inference from two of Anthropic's own numbers, not a measurement. It does tell you where to look.

Fig. 1. The list price fell 20%, and the cache-read price fell 60%Only cache reads beat the 40% headline on price alone. Everything else on the price list is a 20% cut, so the rest of the saving has to come from somewhere else.

Fig. 2. A 40% cost cut with a 20% price cut implies a 25% token cutThe dashed bar is arithmetic, not data. If both of Anthropic's headline figures hold on the same workload, the model has to be using about a quarter fewer tokens per task.

The benchmark gains are largest where agents spend their time

On Terminal-Bench 4.0, Opus 5.5 scores 66.4% against 52.3% for Opus 5. It also sits above Fable 5.1 at 55.8% and GPT-6 Astra at 57.9%, and the gap to Opus 5 is several times the 2.6 point standard error Anthropic reports. CursorBench 4.0 tells a similar story, 57.8% against 46.6%. On Terminal-Bench-Science 0.1 the score goes from 29.0% to 58.7%, though the error bars on that one run to 3.5 to 5 points.

It isn't a clean sweep. GPT-6 Astra scores higher on Terminal-Bench-Science at 64.6%, and it edges Opus 5.5 on AutomationBench, 41.4% to 40.0%. On Humanity's Last Exam with tools, the gain over Opus 5 is 4.1 points, small next to the coding results. The pattern is that the improvement concentrates in long, tool-heavy work, which is what agents do, and shrinks on one-shot reasoning.

Fig. 3. The gain over Opus 5 is biggest on agentic benchmarksRows are sorted by how far Opus 5.5 moved past Opus 5. The largest gains are on agentic and workflow benchmarks, and the smallest is a reasoning exam.

The customer evidence is about fewer steps, not smarter answers

Anthropic's launch page carries testimonials from around twenty companies, and the numbers that keep recurring are about effort saved. Kiro reports 40% fewer calls and half the tokens. Box says Opus 5.5 used a third of the tokens Opus 5 did. Rogo saw 60% fewer output tokens, and Lovable a third to a half fewer steps. Optiver reports a 40 to 50% cost reduction on agentic coding. One early tester audited and fixed a 200,000-line codebase in under three hours, where Opus 5 took more than 20 hours and used 2.5 times as many tokens.

Every one of those is measured on a different metric, workload and effort setting, and every one was picked by the vendor for the launch. Treat them as a hypothesis, not a result. The direction is at least consistent, and Factory's 20 to 25% fewer output tokens lands close to the 25% the arithmetic implied.

Fig. 4. Launch customers describe the saving as fewer tokens, calls and stepsThe metrics differ per customer, so the bars are not comparable to each other. Read the direction, then measure your own workload.

The safety changes reach your code

Three details matter if you run agents. First, thinking can no longer be switched off, so any latency-sensitive path that relies on turning it off is closed on Opus 5.5. Second, a preserved-thinking safeguard applies to Opus 5.5 and Fable 5.1 for API accounts created on or after August 31, 2026. Third, Anthropic says most cybersecurity tasks will be re-routed to Opus 4.8 when safeguards intervene, and biology and frontier LLM development tasks to Opus 5. If you run security workloads, part of your test of 5.5 is a test of that fallback.

The behavioural claims matter most to anyone giving a model real tools. Anthropic says Opus 5.5 attempted to circumvent boundaries around 85% less often than Opus 5 or Claude Mythos 5.1, matches or beats Opus 5 on prompt injection in every setting it tested, and is much less likely to take hard-to-reverse actions. Those come from Anthropic's own audit, so they deserve the same treatment as the customer numbers: promising, and worth checking against your own tool set.

Sonnet 5.5 and Haiku 5.5 make this a decision you'll repeat

Anthropic says both follow in the coming weeks. That means the choice you make now isn't permanent. Keep the model ID in config instead of scattering it through your code, and keep whatever test you run today, because you'll want to run it again.

One test settles it

A benchmark can't tell you whether your agents get cheaper, and neither can a launch page. Your own eval set can, if you count the right thing. Count cost per solved task, not cost per call. A cheaper call that fails more often costs more in the end, and a pricier one that finishes in fewer steps can cost less.

import anthropic

client = anthropic.Anthropic()

def cost_per_solved(model, price_in, price_out, tasks, passes):
    """Prices are USD per million tokens; passes() returns a bool."""
    spent, solved = 0.0, 0
    for task in tasks:
        resp = client.messages.create(
            model=model,
            max_tokens=8000,
            messages=[{"role": "user", "content": task["prompt"]}],
        )
        spent += (resp.usage.input_tokens * price_in
                  + resp.usage.output_tokens * price_out) / 1_000_000
        answer = next(b.text for b in resp.content if b.type == "text")
        solved += bool(passes(task, answer))
    return spent / max(solved, 1)

# Same tasks, same checker. Opus 5.5 list price is $4 in, $20 out.
print(cost_per_solved("claude-opus-5-5", 4, 20, tasks, passes))

For a multi-turn agent, sum the usage across every turn of the run before you price it. Run the same function against your current model with its own prices, and you have the two numbers that decide it.

Fig. 5. Decide on cost per solved task, then decide again when the smaller models shipRun the same eval set on both models, compare cost per solved task, and only move traffic if the cost falls while the pass rate holds.

This week, run your existing eval set on claude-opus-5-5 at two effort levels next to your current model, and write down one number: cost per solved task. Deloitte reported Opus 5.5 catching 72% of known bugs at its lowest effort, against 56% for Opus 5 at high effort, so the cheaper setting is worth testing before you assume you need the expensive one. Switch only if the cost falls and the pass rate holds.

Every figure here comes from Anthropic's launch announcement, read on September 24, 2026. They are claims by Anthropic and its launch partners, not independent measurements.