In short: Opus 5 is a large capability jump over Opus 4.8 at the same $5/$25 price - more than double the score on hard agentic benchmarks, fresher knowledge, and a new effort dial - but it turns thinking on by default, so an unadjusted swap can cost more per call; test on your own tasks before flipping production over.
On 24 July 2026, Anthropic replaced its workhorse model. Claude Opus 5 took over from Opus 4.8 - and it did something model launches almost never do: it kept the price exactly the same. Five dollars per million input tokens, twenty-five per million output, unchanged, for a model that more than doubled its predecessor on the hardest tests.
For anyone running AI in production, that combination - big capability jump, zero price increase - looks like a free upgrade. Mostly it is. But there is one change under the hood that can quietly raise your bill if you swap the model name and walk away.
Here is the honest operator’s comparison of Claude Opus 5 vs Opus 4.8: what genuinely changed, where it matters for your business, and the one thing to check before you move.
Our thesis: Opus 5 is the rare same-price upgrade worth taking - but “upgrade” is a decision to test, not a model string to swap, because the default behavior changed with it.
What is Claude Opus 5?
Claude Opus 5 is Anthropic’s current flagship “Opus” model, released on 24 July 2026 as the successor to Opus 4.8. It keeps the same 1 million token context window and 128,000 token maximum output, and it is priced identically to Opus 4.8. What changed is capability and default behavior: it reasons more effectively on long, multi-step tasks, ships with a more recent knowledge cutoff, and turns its internal “thinking” on by default.
1. The capability jump is real - and concentrated where it counts
Benchmarks are noisy, but the direction here is not subtle. On FrontierBench, a hard agentic-coding test, Opus 5 scored around 43% at maximum effort against roughly 19% for Opus 4.8 - more than double. On ARC-AGI-3, a reasoning benchmark, it went from 1.5% to over 30%. On real developer and computer-use tasks it lands within a fraction of Anthropic’s most expensive model, Claude Fable 5, at a fraction of the cost per task.
What it looks like in production
- Long-horizon work improves most: multi-step automations, larger refactors, and tasks that run across many tool calls - exactly the work businesses automate.
- Simple tasks improve least: on a one-line classification or a lookup, Opus 4.8 was already fine, and the gap narrows.
- Fresher answers: Opus 5’s knowledge runs to May 2026 versus January 2026 for Opus 4.8 - fewer “my information ends before that” gaps.
The jump is biggest on the hard, multi-step work you actually pay people to do - and smallest on the trivial tasks you were never worried about.
2. The catch: thinking is now on by default
This is the one change that can surprise you. On Opus 4.8, if you did not explicitly ask the model to “think,” it did not - it answered directly. On Opus 5, thinking is on by default. That extra reasoning is exactly what drives the capability gains, but it also generates more tokens per response, which you pay for, and makes each call run a little longer.
Swap the model name and change nothing else, and a workload that was cheap and fast on Opus 4.8 can get more expensive and slower on Opus 5 - not because anything broke, but because the default shifted. The fix is simple once you know: Opus 5 exposes a five-level effort dial, from low to max, so you set the reasoning depth each task actually needs.
Cost of getting it wrong
A team that migrates by find-and-replacing the model name, with no effort setting and no test, can see per-call token usage climb across every request at once. The capability is worth paying for on hard tasks; paying it on simple ones is just a leak. Measure cost per completed task before and after, not the model version.
Myth vs Facts
Myth: “A newer model version always costs more.”
Fact: Opus 5 launched at Opus 4.8’s exact price - $5 input, $25 output per million tokens. The capability went up and the sticker price did not, which is rare enough to be worth noting.
Myth: “Upgrading is just changing the model name.”
Fact: Opus 5 thinks by default where Opus 4.8 did not, so a name-only swap changes your token spend and latency. Treat it as a change to test, with the effort dial set deliberately.
Myth: “A benchmark leap means the same leap in my results.”
Fact: The gains concentrate on hard, long-horizon tasks. On simple lookups and classification the difference is small - evaluate on your own workload, not the leaderboard.
Myth: “Newer is always the right model to run.”
Fact: For many production jobs a smaller, cheaper model at the right effort already does the work. Opus 5 also sits in its own rate-limit pool, so moving volume onto it needs planning, not just a flip.
3. Opus 5 vs Opus 4.8: the head-to-head
| Dimension | Claude Opus 4.8 | Claude Opus 5 |
|---|---|---|
| Released | Earlier 2026 | 24 July 2026 |
| Price (per M in/out) | $5 / $25 | $5 / $25 (unchanged) |
| Context / max output | 1M / 128K | 1M / 128K |
| Knowledge cutoff | January 2026 | May 2026 (fresher) |
| Thinking default | Off unless requested | On by default |
| Effort control | Effort levels | Five levels (low to max), incl. a new higher tier |
| Hard agentic benchmark | ~19% | ~43% (more than doubled) |
| Use it when | Simple, cost-sensitive, high-volume tasks | Complex, long-horizon, multi-step automation |
What we see across our deployments
When a model gets cheaper-per-capability like this, the win rarely comes from the model alone. In our experience the model is around 10% of whether an automation succeeds; the system around it - how you set effort, verify output, and route simple work to cheaper models - is the other 90%. Opus 5 raises the ceiling; your architecture decides how much of it you capture.
Before you move a production workload to Opus 5, run this check:
- You tested Opus 5 on your own real tasks, not just the benchmarks.
- You set an effort level deliberately rather than accepting the default everywhere.
- You compared cost per completed task before and after - not just the model version.
- Simple, high-volume jobs are routed to a cheaper model where quality already holds.
- You accounted for Opus 5’s separate rate-limit pool when planning volume.
The strongest case for just upgrading blind
“It’s the same price and clearly better - why overthink it?” For low-volume or non-cost-sensitive workloads, that is a defensible call: switch, set a sensible effort level, and move on. The blind-swap risk only bites at scale, where a small per-call token increase multiplied across millions of requests becomes a real number. Upgrade fast; just glance at the bill afterwards.
What this means if you’re running AI in your business
The practical takeaway is that Opus 5 is a genuinely good deal - more capability, same price - and for most businesses the right move is to adopt it. But the version of the model is the least interesting decision here. What determines your outcome is the system around it: setting effort per task, routing trivial work to cheaper models, verifying what the model produces, and keeping your automation model-agnostic so the next upgrade is a config change, not a rebuild.
That is the same lesson behind our comparison of Claude Fable 5 vs GPT-5.6 Sol, and behind why the businesses that cut costs by 68% did it with architecture, not by chasing the newest model. A better model is a component; the system you build around it is the product - and it is also what keeps model behavior, like a shifted thinking default, from surprising you in production.
If this were your deployment, here’s our first move
We would adopt Opus 5 - the price makes it easy - but we would not flip the switch blind. We would run it on your real tasks, set the effort dial per workload, route the simple high-volume jobs to a cheaper model, and confirm cost per completed task held or improved before moving everything over. The upgrade is worth taking; the discipline is what turns a good model into a lower bill.
Are you upgrading models the right way?
Tick each that applies to how you’d move to Opus 5.
- We’d swap the model name and change nothing else.
- We haven’t tested the new model on our own real tasks.
- We accept the default settings everywhere rather than setting effort per task.
- Every job - simple or complex - runs on the same top-tier model.
- Our automation is tied to one model and hard to change later.
If you ticked more than one, the upgrade is running ahead of the architecture - the most common and most fixable gap we see. See how we build model-agnostic agentic systems, or tell us about your workload and we’ll help you capture the upgrade without the surprise bill.
