The interesting number in the Opus 5 launch is not a benchmark
Anthropic released Claude Opus 5 on July 24, 2026. The headline claims are strong: new state of the art on Frontier-Bench v0.1, roughly 3x the next-best model on ARC-AGI 3, around 1.5x the pass rate of the next-best model on Zapier's AutomationBench, and best-in-class on OSWorld 2.0 at any given cost.
Those are the numbers everyone quoted. The number that actually matters for anyone running this in production is different: more than double Opus 4.8's performance at a lower cost per task.
Cost per task, not per token. That distinction is the whole story, and it is why most cost comparisons of frontier models are wrong.
Per-token pricing stopped being a useful comparison
Opus 5 lists at $5 per million input tokens and $25 per million output tokens, with a 300k default context extending to 1M.
Compare that to a cheaper model at, say, a fifth of the price and the conclusion looks obvious. It is not, because on agentic work the two models do not do the same amount of work to reach the same result.
A weaker model on a multi-step task takes a wrong turn, notices, backtracks, retries a tool call with different arguments, and re-reads context it already processed. Every one of those steps is billed. A stronger model that gets it right in four steps instead of eleven can be cheaper in absolute terms at 3x the token price.
This is why the Frontier-Bench framing is the honest one. Anthropic's own CursorBench 3.2 result makes the point in the other direction too: Opus 5 lands within 0.5% of the higher-tier Claude Fable 5 at roughly half the cost. Nearly identical capability, half the spend.
The metric to track is cost per completed task at your quality bar. If you are not measuring that, you are guessing.
Here is the measurement that actually settles a model choice:
from dataclasses import dataclass
@dataclass
class TaskRun:
model: str
input_tokens: int
output_tokens: int
succeeded: bool # judged against YOUR bar, not a benchmark
wall_clock_s: float
PRICES = { # USD per million tokens
"claude-opus-5": (5.0, 25.0),
}
def cost_per_success(runs: list[TaskRun], model: str) -> float:
"""The only model-selection number that matters."""
rs = [r for r in runs if r.model == model]
inp, outp = PRICES[model]
total = sum(
(r.input_tokens / 1e6) * inp + (r.output_tokens / 1e6) * outp
for r in rs
)
wins = sum(1 for r in rs if r.succeeded)
if not wins:
return float("inf") # a model that never succeeds is not cheap
return total / winsRun 50 real tasks from your product through each candidate and compare. The ranking frequently inverts against per-token intuition, and it takes an afternoon.
Fast mode: 2.5x the speed for 2x the price
Opus 5 offers a fast mode running at roughly 2.5x speed for 2x the price.
The instinct is to treat this as a premium tier for impatient users. That is the wrong frame. Latency is not a UX nicety in agentic systems, it is a multiplier on every step in the loop.
A 12-step agent where each step takes 8 seconds is a 96-second operation. Users abandon it. At 2.5x, the same loop finishes in about 38 seconds, which is the difference between a feature people use and one they route around.
So the decision rule is not "how impatient is this user." It is:
- •Single-shot, non-interactive (batch summarisation, offline enrichment, nightly jobs): standard mode. Latency is irrelevant, so paying 2x for it is waste.
- •Interactive, single-turn (a chat reply, one completion): standard mode is usually fine. You are paying 2x to save a few seconds on one call.
- •Multi-step agent loops with a human waiting: fast mode is often the better economic choice even though the token bill is higher, because it converts a workflow people abandon into one they complete.
That last case is the one teams get wrong, because the token bill goes up and the benefit does not appear on the same dashboard. If you have invested in latency optimisation, fast mode is another lever on the same problem, and it is worth measuring against the engineering time you would otherwise spend shaving milliseconds.
The 300k default context is a trap if you treat it as a target
Opus 5 ships with a 300k token default context, extending to 1M.
Every time context windows grow, the same mistake follows: teams stop retrieving and start stuffing. Why build hybrid search when you can drop 200 documents in the prompt?
Three reasons, and they have not changed:
- 1You pay for every input token, every call. 300k input tokens at $5/M is $1.50 per request before the model produces anything. At 10,000 requests a day that is $15,000 daily for context you mostly did not need.
- 2Attention is not uniform. Models remain measurably better at using information near the beginning and end of a long context. Burying the critical paragraph at 60% depth is not the same as retrieving it into a focused prompt.
- 3Debugging becomes guesswork. When a 300k-token prompt produces a wrong answer, you have almost no signal about which part caused it. A 4k-token prompt built from five retrieved chunks tells you exactly what the model saw.
Large context is a safety margin, not a design target. It means your RAG pipeline no longer breaks when a document runs long. It does not mean retrieval is obsolete. The chunking strategies benchmark holds up fine in a 1M-token world, because the argument was never that context was scarce, it was that focused context produces better answers.
What the agentic benchmarks are actually telling you
ARC-AGI 3, OSWorld 2.0 and Zapier AutomationBench measure something the older benchmarks did not: whether a model can operate over many steps without going off the rails.
That is a different property from raw reasoning. A model can be excellent at single-turn reasoning and still be unusable in an agent loop because it loses track of what it has already tried, or because a single tool error derails it permanently.
A 3x margin on ARC-AGI 3 and 1.5x on AutomationBench point at improved multi-step coherence. If you previously evaluated agentic workflows, concluded the reliability was not there, and shelved the project, that evaluation has an expiry date on it. The failure modes that made autonomous loops impractical in 2025 are exactly the ones these benchmarks track.
Two caveats before you rewrite anything:
Benchmark conditions are not your conditions. These are curated tasks with clean tool definitions. Your tools have inconsistent error messages, your data has edge cases, and your users phrase things strangely. Benchmark performance is an upper bound.
Better models do not fix bad architecture. If your agent fails because your tool descriptions are ambiguous or your error messages give the model nothing to act on, a stronger model papers over it slightly and fails in subtler ways. The reliability patterns still do the heavy lifting.
A practical migration approach
If you are on an earlier Claude model, this is what I would actually do:
- 1Do not swap the model globally. Route a slice of production traffic and compare on your own tasks.
- 2Measure cost per completed task, not per-token spend. Use the function above.
- 3Leave your context strategy alone at first. Change one variable. If you switch model and blow up your context budget simultaneously, you will not know which change caused what.
- 4Re-run your agentic evals. This is where the gains are concentrated. Single-turn quality differences will be subtle; multi-step reliability differences will not.
- 5Test fast mode specifically on loops with a human waiting. Measure completion rate, not just latency. The point is abandoned workflows becoming completed ones.
- 6Pin the version.
claude-opus-5is the identifier. Log it alongside stored outputs so you can attribute behaviour changes later.
Steps 1 and 3 are the ones people skip, and they are the reason migrations produce ambiguous results.
Is it worth switching?
If you run multi-step agents, probably yes, and the cost-per-task math may well be favourable despite the higher token price.
If you run single-turn completions at high volume, probably not by default. You are paying frontier prices for capability the task does not need. Route by task complexity and reserve the expensive model for requests that earn it.
If you shelved an agentic project on reliability grounds in the last year, it is worth an afternoon re-running your evaluation. That is the most likely place to find something that changed.
The broader pattern is worth noticing: model releases are increasingly about agentic coherence over many steps rather than single-turn intelligence. That is a good signal about where to point your own engineering effort. You can track how the ranking shifts on the LLM leaderboard, and the churn itself is the lesson. Build the parts that survive a model swap.
Frequently Asked Questions
How much does Claude Opus 5 cost?
It lists at $5 per million input tokens and $25 per million output tokens, with a 300k default context extending to 1M. Fast mode runs at roughly 2.5x speed for 2x the price. Compare on cost per completed task rather than per-token price, since a stronger model that needs fewer steps can be cheaper in absolute terms.
Is Claude Opus 5 better than Claude Fable 5?
On CursorBench 3.2, Opus 5 lands within 0.5% of Fable 5 at roughly half the cost, so for coding-style work Opus 5 is the better value. Fable 5 sits at roughly 2x the cost and requires data retention approval. Anthropic also notes Fable 5 leads on some cybersecurity tasks.
Should I use fast mode?
Use it for multi-step agent loops where a human is waiting, since latency multiplies across every step and turns a workflow people abandon into one they complete. Skip it for batch and offline work, where you would be paying 2x for speed that delivers no value.
Does the 1M context window mean I can stop using RAG?
No. You pay for every input token on every call, models are measurably better at using information near the start and end of long contexts, and large prompts make debugging nearly impossible. Treat large context as a safety margin so long documents no longer break your pipeline, not as a reason to stop retrieving.
What does a 3x score on ARC-AGI 3 actually mean for my product?
It points at improved multi-step coherence, meaning the model is better at operating over long loops without losing track or being derailed by a tool error. It does not mean a weak agent architecture will now work. Benchmark tasks use clean tools and curated inputs, so treat the result as an upper bound.
Where to go from there
The pattern worth internalising is that model choice is an empirical question about your workload, not a ranking you read off a leaderboard. Measure cost per completed task on your own tasks and the answer is usually clear within an afternoon.
If you want to build and evaluate agent loops hands-on, I run a 2-hour live workshop most Sundays, real code and no slides. ₹499 / $19 with a full refund guarantee. See what's coming up →
For the wider path, the AI engineer roadmap covers where model evaluation fits alongside everything else.