Claude Opus 5 shipped this week and the scoreboard reads well.
More than double Opus 4.8 on Frontier-Bench v0.1. Within half a percentage point of Fable 5 on CursorBench 3.2 at roughly half the cost per task. Three times the next-best model on ARC-AGI-3, where 4.8 barely registers. It clears Fable 5's peak on OSWorld 2.0 computer-use while spending about a third of the budget.
Price per token is unchanged from 4.8: five dollars in, twenty-five out, per million.
Strong release. I've been using it all day and I'm not going to pretend otherwise.
The line that will cost you an afternoon sits further down, buried in the effort documentation, in the section for the new model:
If you carried effort settings over from an earlier model, run a fresh effort sweep on your evals rather than reusing them.
Read that with your own repo in mind. Whatever effort value you tuned for Opus 4.8, in your Claude Code config, in your subagent definitions, in the output_config of whatever service you shipped last quarter, is now advice from a previous model.
It still parses. It still runs. It no longer means what it meant on the day you measured it.
The wins are real
The gains here sit well clear of the usual release-to-release creep. Doubling a coding benchmark between releases eight weeks apart is a big number, and ARC-AGI-3 is the kind of eval that models either get or visibly do not.
The part I care about more: the bottom of the range got better. Anthropic's own guidance says low and medium effort "are stronger on Claude Opus 5 than on earlier Opus models" and tells you to use them liberally as your primary control for cost and latency. For anyone running agents in a loop, a stronger floor matters more than a taller ceiling. Most of the tokens in an agentic session aren't spent on the hard part.
That is also exactly where the trap is.
"Half the cost" is a claim about behaviour, not billing
Nothing about the rate card moved. Opus 5 costs the same per token as Opus 4.8. Every "half the cost per task" line in the launch material is arithmetic over tokens spent: the model reaches the same result in fewer tokens and fewer turns, so the task comes out cheaper.
That saving is real and it is conditional. Cost per task depends on your prompts, your tool loop, how often you retry, how much context you drag along, and the effort level you run at. Anthropic measured theirs with settings they swept for this model. You'll run yours with settings you swept for the last one.
Same model, same price, two different bills. This is the cheap-is-not-free arithmetic again, one layer down.
Five labels that stayed put while the thing underneath moved
The effort levels are stable as names. low, medium, high, xhigh, max, same five words, same API field, same YAML key. What sits behind each word is model-specific and changes every release.
For Opus 4.7 and 4.8, the guidance was to start at xhigh for coding and agentic work, treat high as the floor for anything intelligence-sensitive, and step down to medium only once your evals proved it held. max was for genuinely frontier problems, with a warning that on most workloads it buys cost rather than quality.
For Opus 5, xhigh is still the recommended starting point for coding. The floor is what shifted: medium and low moved from "prove it holds before you drop this far" to "reach for these first". A team that dutifully pinned everything to xhigh in May, exactly as instructed, is now overspending on work this model handles two tiers down.
Two smaller changes hide in the same page and both bite config that used to work:
- Effort no longer shortens output. On Opus 5, changing effort doesn't reliably shorten responses, so you prompt for length instead. If you were running
lowpartly to keep answers terse, that lever came off. - Thinking cannot be disabled at
xhighormax. A request combining either withthinking: {"type": "disabled"}returns a 400. That is the one stale setting that fails loudly, which makes it the least dangerous of the three.
The failure is quiet, which is why it survives
Effort is documented as a behavioural signal, which puts its meaning inside the model, somewhere you can't inspect. There's no validator that knows which model you tuned a value against, no drift warning, no deprecation notice. Nothing in the stack has any idea that your medium was calibrated in May.
So you upgrade, and it works. You get an answer, the answer looks fine, the tests pass. Somewhere in there you're running a tier you wouldn't have chosen if you'd measured, either paying for depth this model no longer needs or quietly capping it below where the wins are. The output has no tell.
This is the same shape as a stale memory file: an artefact that was true once, still loaded, still authoritative, silently wrong. Config rots the same way documentation does, and for the same reason. It describes a world that shipped an update.
What to actually do this week
Nothing here takes long. The reason it doesn't happen is that upgrade day feels like the day you get something for free.
- Grep for effort values. Claude Code settings, subagent frontmatter, skill definitions, service code, CI jobs. Most teams have more of these than they remember, scattered across places that were never meant to hold a tuning decision.
- Keep one eval you can rerun. Ten to twenty tasks pulled from your actual repo, with a pass/fail you trust. A fixture you can point at any model on any day, nothing fancier.
- Sweep downward first. Given where the floor moved, the cheapest useful discovery is that you're paying
xhighprices formediumwork. - Pick effort per workload, then hold it steady. Changing the value mid-conversation invalidates your cached prefix, so vary it across workloads rather than inside a session that depends on cache hits.
- Do it on upgrade day. The alternative is doing it during an incident, or during a billing review, where it won't feel like a free afternoon.
Anthropic said the same thing about Opus 4.8 that they're saying now, which is that the numbers only transfer if your setup transfers. That was true then too, and I wrote about the part of the 4.8 release that wasn't a benchmark for the same reason.
The upgrade is free. Everyone gets the better model at the old price on the day it lands, and that's a good deal by any reading. The retuning is what it actually costs, and it is charged in an afternoon instead of in dollars, which is precisely why it gets skipped. Skip it often enough and you end up running last quarter's settings against this quarter's model, watching the gains land smaller than advertised, and concluding the benchmarks were hype.
The benchmarks were measured. Yours weren't.