Almost Fable 5 at Half the Price: Why Opus 5 Changes Your Model Decision from Per-Project to Per-Task
I’ve spent two years watching teams choose “a model” the same way they choose a database: once, at the beginning, with a long meeting and a spreadsheet. Opus 5, which Anthropic launched on July 24, retires that meeting without fanfare. Not because it’s a new state-of-the-art—it is—but because it turns the cost/intelligence tradeoff into a dial you adjust per task, instead of a bet you make per project.
The number that’s going to travel is the headline: Opus 5 “comes close to the frontier intelligence of Claude Fable 5 at half the price”. On CursorBench 3.2, at max effort, it lands within 0.5% of Fable 5’s peak at half the cost per task. It’s the absolute state-of-the-art on Frontier-Bench v0.1 and GDPval-AA, and more than doubles Opus 4.8’s score on Frontier-Bench at a lower cost per task. Same price as its predecessor—$5 per million input tokens, $25 for output—available now on the API as claude-opus-5, and it’s already the default model in Claude Max and the strongest option in Pro.
But the price isn’t the interesting part. The interesting part is the effort setting.
Opus 5 brings an effort control—low, medium, high, xhigh, max—that lets you trade intelligence for tokens on each request. This is what changes how a team should think. Until now, “cheaper vs. smarter” was a model selection decision: you’d route to Haiku for the cheap path and to Opus for the hard path, and you had to maintain that routing logic. With Opus 5, the same model covers the whole range. You lower the effort for boilerplate and raise it for tricky refactoring, and you get billed accordingly.
Early-access reports point in the same direction. A legal workflows customer found that Opus 5 maintained accuracy while generating 26% fewer tokens on average compared to Opus 4.8 at max reasoning. Others describe the efficiency gain differently—a trading firm cites around a seventh of the reasoning tokens and less than half the latency of Opus 4.8; a financial modeling team saw a third fewer turns and tool calls and 60% less clock time—. The exact numbers vary by workload, but the pattern doesn’t: on Opus 5, more effort buys less waste than before.
Here’s the CTO framing I’d actually use in a planning meeting. Your model decision was a fixed cost: you’d pick a tier and live with its floor and ceiling. Opus 5 turns that fixed cost into a variable one you control at call time. That’s a budget change disguised as an API flag. It means your cost per task is now a function of a parameter your engineers set, not a contract you signed. It also means “which model” stops being the lever and “how much effort per task” becomes it.
Two caveats worth keeping honest. First, the benchmark framing: the SOTA claims are on Frontier-Bench and GDPval-AA; the CursorBench story is closeness to Fable 5 at half the cost, not a new peak—don’t mix up the two. Second, Opus 5 is deliberately behind Mythos 5 in cybersecurity and biology. Anthropic didn’t train it on cyber tasks; its cyber classifiers are ~85% less restrictive than Fable 5’s, but they still block exploit generation and binary-based vulnerability scanning, and marked requests fall back to Opus 4.8 on Claude.ai, Claude Code, and Cowork. If your work lives in offensive security, this isn’t your model—and it’s by design—. (Anthropic also calls it their most aligned model to date, with the lowest score on their internal misalignment audit—worth noting, given that the same release loosened the cyber guardrails—).
Practical note for Claude Code folks (the dev corner): the effort setting isn’t just an API abstraction—it’s the lever you reach for when a long agentic run is burning tokens on easy steps—. You should start a session at a lower effort for scaffolding and routine edits, and raise it to high/xhigh/max when you hand off hard debugging or root-cause hunting. Several early-access teams report the same accuracy at lower effort levels, so the “always max” default is now the expensive habit, not the safe one.
The real change isn’t that there’s a new best model this week—there’s a new best model almost every week—. It’s that the choice between smart and cheap moved from purchase decision to code, where a developer fixes it per task. If you’re still picking a model per project, you’re leaving the dial on the table.
Are you already routing by effort setting, or are you still choosing a fixed model per project? Where do you draw the line between “lower the effort” and “give it max”?