Your Agent's Cost Is a Slider Now: What Claude Opus 5's Effort Setting Changes
Anthropic shipped its flagship and led with cost-per-capability. The architectural change underneath is that inference cost became a runtime parameter — here's how to tier it.
Anthropic shipped its flagship and led with cost-per-capability. The architectural change underneath is that inference cost became a runtime parameter — here's how to tier it. What happened On 24 July 2026 , Anthropic released Claude Opus 5 , available on all platforms the same day. Pricing is $5 per million input tokens and $25 per million output tokens — unchanged from Opus 4.8. The benchmark claims from Anthropic's own launch post: - On Frontier-Bench v0.1 , it surpasses all other models and more than doubles Opus 4.8's performance. - On CursorBench 3.2 at max effort , it lands within 0.5% of Fable 5's peak score, at half the cost . - On ARC-AGI 3 , it scores three times as high as the next-best model . - On OSWorld 2.0 , it beats Fable 5's best result at just over a third of the cost . It also ships three things worth naming separately: an adjustable effort setting (optimise for intelligence, or conserve tokens), a Fast mode running around 2.5× default speed at twice the base price, and Automatic Fallbacks in beta — requests flagged by safety classifiers can automatically route to another model instead of failing. One note on numbers before we go on. Several write-ups this week are circulating specific absolute figures for Frontier-Bench and ARC-AGI. Those numbers are not in Anthropic's post , which states relative claims only. We're not repeating them, and you shouldn't build a comparison on them. Why it matters Read the four claims above again and notice their shape. Three of them are phrased as capability per dollar : half the cost, a third of the cost, relative to the next-best model. A frontier lab is marketing its flagship on price-performance. That's the strategic signal, and it's sitting in plain sight in the primary source. It tells you the competition has moved from "who has the best model" to "who has the best model per dollar" — which is a much better environment to be a builder in. But the change that will actually touch your codebase is quieter. Cost stopped being a procurement decision and became a runtime parameter. Until now, managing AI spend meant model selection: route cheap requests to a small model, expensive ones to a big model, and maintain a routing layer, a set of prompts per model, and evals for each. That's real engineering overhead, and it's why most teams either over-spend on one good model or under-deliver on a cheap one. An effort setting collapses that. One model, one prompt, one set of evals — and a dial you set per request. The operational model goes from "which model?" to "how much effort does this request class deserve?" That is a question your product team can answer, which is the point: it moves a cost decision out of infrastructure and into product. For CEOs, that reframes the budget conversation. The question isn't "which model can we afford." It's "which of our AI request classes actually need high effort?" Most teams have never asked, and the answer usually saves money in places customers can't perce