Opus 5 is here at half the price of Fable 5. The benchmarks are great, but the API changes are the real story.

Opus 5 shipped on July 24, 2026. Opus 4.8, the model it replaces, is my daily driver, so I read the release with a specific question: not “is it smarter” (it is), but “what changes in the loop I already have.” The answer turned out to be more interesting than the benchmark table, and most of it is not in the release blog post.

Here is the short version. Opus 5 costs the same as Opus 4.8, five dollars per million input tokens and twenty-five per million output. That is half the price of Fable 5, Anthropic’s top-tier model, and Opus 5 gets within spitting distance of Fable on most of the numbers that matter. It is now the default on Claude Max and the strongest model on Claude Pro. If you were on 4.8, this is a model-name swap that makes you meaningfully smarter for the same money.

But “swap the string and go” hides three changes that will quietly bite you. Let me get the benchmarks out of the way first, because they are the least surprising part.

The benchmarks, honestly

The headline Anthropic is selling is “frontier intelligence of Fable 5 at half the price,” and the numbers mostly back it up. On Frontier-Bench v0.1 at max effort, Opus 5 scores 43.3%. Opus 4.8 scored 18.7% on the same test. Fable 5, the model that costs twice as much, scores 33.7%. Opus 5 does not just close the gap to Fable; on this particular benchmark it clears it.

The rest of the table is the same shape:

• SWE-bench Verified: 96.0%. Real GitHub bugs, graded by the projects’ own hidden tests. A year ago the frontier here was in the mid-sixties.
• SWE-bench Pro: 79.2%, against Fable 5’s 80.0%. Within a point, half the cost. That single comparison is the entire pitch.
• OSWorld 2.0: 70.57%, up from 55.7% on 4.8. This is the computer-use benchmark, a real Ubuntu desktop driven by mouse and keyboard.
• ARC-AGI-3 at high effort: 30.16%. Opus 4.8 scored 1.52% here. This is the novel-problem-solving benchmark, the one designed so you cannot pattern-match your way through, and the jump is not a typo.
• IMO 2026: 42 out of 42, gold-medal level on this year’s International Mathematical Olympiad problems.

I am quoting these from the release and from the first wave of coverage, not from a system card I have read cover to cover, so treat the third-decimal precision with the usual caution. The pattern is what matters, and the pattern is clear: the agentic and reasoning numbers are where Opus 5 pulled ahead, and it did so while staying at Opus pricing. If you spend your day inside a coding agent, that is the number that shows up in your work.

That is the part everyone will screenshot. Now the part that will actually change how you use it.

Thinking is on by default now, and your max_tokens is a trap

On Opus 4.8 and 4.7, a request that left the thinking field unset ran without thinking. That was the default, and a lot of code was written around it, including mine. On Opus 5 the same request thinks. Omitting the field now gives you adaptive thinking; the old “no thinking” behavior is thinking: {type: "disabled"}, which you now have to ask for.

This is not just a behavior change, it is a billing and truncation change, and that is the part that catches people. max_tokens is a hard cap on thinking plus response text, together. A workload that never set thinking, ran clean on 4.8, and sized max_tokens tightly around the answer will now spend a chunk of that budget on reasoning and can truncate mid-response. Nothing errors. You just get a shorter answer than you asked for, and if you are parsing structured output downstream, that shows up as a broken parse rather than an obvious cause.

So the first thing to do on migration is not to swap the model string. It is to walk every call site that never touched thinking and either raise max_tokens to leave room, or explicitly pass thinking: {type: "disabled"} if you genuinely want the old behavior.

And there is a second edge on that same lever. Disabling thinking is only allowed at effort high or below. Pair thinking: {type: "disabled"} with xhigh or max effort and you get a 400. The check runs per request, so a route that raises effort to xhigh for a hard turn while thinking is still disabled will fail on that turn even though every earlier turn in the same conversation went through fine. If you were reflexively running xhigh with thinking off on 4.8, that combination is now invalid, and honestly you are probably better served by a lower effort with thinking on. Opus 5 is unusually strong at low and medium; the effort defaults you carried over from a previous model are almost never the right setting.

Delete your verification scaffolding

This is the one that surprised me, because it inverts advice I give constantly.

“Ask the model to double-check its work” is a standard, sound prompting technique. On Opus 5 it is wrong. The model self-verifies without being asked, so an instruction that tells it to verify, or a harness step that spins up a verifier pass, now causes over-verification: it does the work, then does it again, burning tokens and latency for no gain. Anthropic’s own guidance is blunt about it. Delete the verification prompts. This is a delete, not a rewrite, and removing the scaffolding reduces the over-verification with no measurable capability loss.

The same instinct shows up with subagents. Opus 4.8 under-reached for delegation and needed a nudge to fan out. Opus 5 reaches for subagents readily, sometimes too readily, because each one re-establishes context, re-explores, reports back, and then the coordinator re-reads the report. If your harness supports subagents, any “delegate more” guidance you added for 4.8 should come out, and you probably want an explicit cap on spawn count. The direction reversed between the two models, which is a genuinely unusual thing to have to account for in a point-release migration.

It also just talks more. Default response text is longer, and files it writes to disk are longer. Lowering effort does not reliably shorten the visible output, so the lever here is a plain conciseness instruction in the prompt, not a knob. A short “keep responses focused and brief” line cut visible length by about a fifth in Anthropic’s testing.

The smaller changes that still matter

A few things that are easy to miss:

The prompt-cache minimum dropped to 512 tokens, down from 1024 on 4.8. Prompts you had written off as too short to cache will now create cache entries with no code change. Worth re-checking anything you assumed was uncacheable.

Fast mode runs at roughly 2.5x throughput for 2x the price, and it is Claude API only. If you have Bedrock, Vertex, or Foundry in the mix, that lever is not available there, so drop it on those routes.

Automatic fallbacks got easier. Opus 5’s safety classifiers can decline a request outright: you get a normal HTTP 200 with stop_reason: "refusal", not an exception. If your code reads content[0] without checking stop_reason first, it breaks on a refusal. The new fallbacks: "default" mode re-runs a declined request on a fallback model server-side and routes by refusal category, so you do not maintain a model list yourself. For a security-adjacent workload where benign requests occasionally trip a classifier, opting into that by default is the right move.

Rate limits are a separate bucket. Opus 5 does not draw from the combined Opus 4.x pool, so moving traffic over neither frees headroom on the old bucket nor inherits it. Check your tier’s Opus 5 limits before you shift volume.

The safety story is a real shift for anyone doing security work

This one is relevant to me specifically, and probably to a chunk of the people reading this. Anthropic tightened alignment and, at the same time, loosened the cybersecurity classifiers by a lot. Opus 5’s cyber classifiers are described as roughly 85% less restrictive than Fable 5’s. On Frontier-Bench, the safety classifiers flagged about 5% of API calls, against 42% for Fable 5.

Concretely, source-code vulnerability finding is now unblocked, while binary scanning, penetration testing, and exploit generation stay restricted. If you do authorized defensive work, code review for vulnerabilities, CTF-style analysis, the false-positive rate that made Fable 5 frustrating for that work has come way down. It is not a free-for-all, and the exploit-generation guardrails are still there, but the day-to-day friction of getting a legitimate security question answered is much lower.

And it pairs with the alignment gains rather than trading against them. Prompt-injection resistance improved (2.0% attacker success on the Gray Swan benchmark, down from 5.5% on Opus 4.8), and Anthropic is calling this its most aligned model to date. Fewer refusals on legitimate security work and better injection resistance in the same release is a good combination to see.

What I am actually doing about it

Nothing dramatic, which is the point. The migration is a model-name swap plus a short checklist:

1. Change the model string to claude-opus-5.
2. Walk every call site that never set thinking. Raise max_tokens, or pass thinking: {type: "disabled"} if I want the old no-thinking behavior. This is the one that would have silently truncated things otherwise.
3. Find any route that pairs disabled thinking with xhigh or max effort and fix it, because it now 400s.
4. Delete verification prompts and any verifier passes in the harness.
5. Re-sweep effort. The xhigh-by-reflex default I carried from 4.8 is probably too high; low and medium are stronger on Opus 5 than they have any right to be.
6. Add a conciseness line where output length matters, since the model runs longer by default.

The benchmarks are the headline and they are genuinely good. But the story for anyone who builds on top of this model is that a handful of defaults moved, and moved in ways that do not throw errors, they just quietly change your output or your bill. Those are the ones worth an afternoon before you roll it out.

---

Sources: Introducing Claude Opus 5 (Anthropic, July 24, 2026). Benchmark figures and API details cross-referenced against Anthropic’s developer documentation and launch coverage; treat exact decimals as reported rather than independently verified.