Skip to content
Beyond Prompt AI Studio

Strategy & research

The effort dial in Claude Opus 5: why the real feature isn't the half-price headline

July 25, 2026 · 13 min read · Beyond Prompt AI Studio

On July 24, 2026, Anthropic released Claude Opus 5. The announcement reads as expected: a new top model, best-in-class scores on several coding and knowledge-work benchmarks, and the catchy message that it comes close to the frontier intelligence of the top model Fable 5 - at half the price, at an unchanged tariff versus its predecessor Opus 4.8. Almost every report leads with those three points. This analysis argues they miss what's actually interesting. Because the most consequential change for companies is an unassuming control: a dial that lets you set, per request, how much thinking effort the model spends. That dial is sold as a saving feature - but it is really a decision handed to you that defaults to expensive. And the fact that Anthropic and OpenAI both suddenly marketed efficiency rather than raw capability in the same month is a quiet admission about the question you should even be asking of a model.

Key takeaways

  • The real feature in Opus 5 isn't the half-price headline but the effort dial: per request you set how hard the model thinks (levels from minimal to max). That dial decides the cost, not the list price.
  • The dial doesn't save on its own: per Anthropic's own documentation, the default sits at a high level. Leave it alone and you pay full thinking effort for every trivial task - the advertised saving has to be actively dialed down.
  • It's the same mechanism as per-click approval from an earlier article: a dial only helps with discipline. Without deliberate assignment, everything ends up on the default or on just-use-max-to-be-safe - and the bill rises instead of falling.
  • That both Anthropic and OpenAI market efficiency instead of intelligence in the same month is a quiet admission: the relevant question is no longer how smart a model can be, but how much intelligence a specific task actually needs.
  • This turns model choice from a one-time decision into an ongoing routing question inside your own system - an architecture and engineering task, not a subscription pick. That's exactly where the lever sits for a mid-sized company.

What was actually announced yesterday

Anthropic released Claude Opus 5 on July 24, 2026, available immediately under the model name claude-opus-5 via its own platform and the major cloud providers. The hard facts: pricing is 5 dollars per million input tokens and 25 dollars per million output tokens - identical to its predecessor Opus 4.8, so more performance at the same tariff. On several coding and knowledge-work benchmarks, Opus 5 sets new best scores, including roughly 96 percent on the established SWE-bench Verified and a markedly higher number than the competition on the reasoning test ARC-AGI-3. Anthropic's core message: Opus 5 comes close to the intelligence of the pricier top model Fable 5 - at half the price.

A note on method up front: the facts on price, availability, and dial logic come from Anthropic's own announcement and documentation and from Fortune's reporting. Some of the circulating benchmark figures - for Frontier-Bench, CursorBench, or DeepSWE - come from secondhand sources of varying quality and should be treated with caution. For the point at hand, that's secondary, because it doesn't hinge on the second decimal of a benchmark but on a control that Anthropic itself documents.

The real feature is the dial - and it defaults to expensive

In the list of new features, usually as an aside, an effort parameter appears: a setting that controls, per request, how much the model thinks before it answers. Technically it's about so-called thinking tokens - compute spent before the actual answer that you pay for too. Anthropic's documentation names a range from very sparing to maximal. And here is the point the headlines miss: per the official documentation, the default is not the cheapest sensible level but a high one. Change nothing and the model reasons at full effort even for the most trivial request.

That quietly inverts the marketing message. Half the price versus the top model is not automatic but the result of an active decision: you have to deliberately turn the dial down for the task at hand. Early external evaluations even suggest that the medium setting is the economic sweet spot for many tasks - nearly the quality of the highest setting at markedly lower token use. That's plausible, but it rests on a single benchmark analysis and should therefore be read as a hint, not a law. The robust statement remains: the default is not the frugal setting but the effortful one - and anyone who wants the advertised saving has to go get it actively.

The dial doesn't save money - it hands you a decision

That makes the dial less a saving feature than a delegation. On every task the model implicitly asks: how much thinking do you want to pay for? And someone has to answer that - per request, continuously. This is exactly where a pattern repeats that we described in an earlier article on the OpenAI agent incident. There it was the obvious but unworkable idea of having a human approve every agent action: in practice such prompts get waved through reflexively because habituation sets in. The effort dial risks the same mechanism in two directions. Either the dial simply stays on the expensive default because nobody touches it per task. Or - almost worse - it gets turned up preemptively, on a just-max-it so the answer definitely isn't worse basis.

Both lead to the same result: the bill doesn't fall, it can even rise, because the same model at a higher level consumes more tokens than the predecessor at a normal one. The half-price in the headline is thus a best case conditional on perfect discipline - and per-request discipline is precisely what people and teams tend not to sustain. The saving is real, but it's tied to work the marketing omits: deliberately matching effort to task. For a one-off chat question, that doesn't matter. For an agent running thousands of times a day, it's the actual cost question.

Why two competitors are marketing efficiency at the same time

The most revealing part of the story isn't in the spec sheet but in the timing. Fortune explicitly frames the effort dial as a response to growing complaints from enterprise customers about expensive AI bills - specifically about the high burn rate of the top model Fable 5. And in the same breath, the report notes that OpenAI already foregrounded economical token usage when marketing its latest model, GPT-5.6. So two direct competitors, in the same month, are no longer primarily advertising that their model is smarter, but that it is more efficient.

That's a quiet but remarkable admission. For years the implicit sales logic of the frontier labs was: more intelligence is always better, and the next benchmark point justifies the next price. A dial for deliberately throttling intelligence, and a marketing message that puts efficiency over capability, say something else. They say, implicitly, that the interesting question is no longer how smart a model can maximally be, but how much intelligence a specific task actually needs. Have it add up a sum or categorize an email and the smarter model gains you nothing - you just pay more. That very insight, that context matters and not the top of the leaderboard, is the thread running through our comparison work. That the model vendors are now casting it into a product feature themselves is the strongest confirmation one could ask for.

What it means in practice: model choice becomes an architecture question

If the same model ID is an expensive-brilliant or a cheap-solid tool depending on the dial, then an assumption underlying many projects falls apart: that model choice is a one-time decision you make once and then forget. The opposite is true. The decision of which model and which effort level is appropriate for which kind of task becomes an ongoing routing question inside your own system - and thus an architecture and engineering task. It's the same idea we spelled out in connection with the Kimi K3 sell-off: it's not the cheapest or the smartest model that wins, but the system that routes each task to the right level.

Concretely, for a company that uses AI in production or wants to:

  • The effort level belongs in the system, not in the user's discretion: define per task type which level is appropriate - classification and extraction low, complex reasoning high - and set it in code, not through daily manual calls. That turns a matter of discretion into an auditable rule.
  • The default is a cost risk, not a neutral starting point: for every model, check what effort it defaults to, and treat that default as something you must actively set - not something you can let run.
  • Benchmark numbers without an effort level have become worthless: a SOTA score at maximum effort is a completely different economic proposition than the same test at medium. Anyone comparing vendors now has to ask at which level a number was produced - otherwise they're comparing apples to oranges.
  • The lever is in routing, not in the tariff: the biggest saving doesn't come from a model getting cheaper per token, but from trivial tasks never landing on the expensive level in the first place. That's a question of your own system's architecture, independent of which model runs underneath.

What this means for your decision

The Opus 5 headline isn't wrong - the model is strong, and the same price for more performance is good news. But the headline distracts from the actual event. The actual event is that cost control moves from the tariff into the application: it's no longer the list price that decides what AI costs, but how well a company matches each individual task to the appropriate effort level. That's worse news for anyone who hoped a cheaper model would solve the budget question on its own - and good news for anyone willing to treat that matching as what it is: a technical task with a real result.

For your own decision, that means: the question isn't whether Opus 5 is the best model - on some tasks it leads, on others, such as certain coding or security tests, other models do. The question is whether you have a system that routes each task to the right level, instead of running everything on the most expensive one by reflex. Build that capability and you benefit from the effort dial regardless of which model tops the leaderboard next week. Fail to build it and you'll see little of the half-price in practice.

Frequently asked questions about Claude Opus 5 and the effort dial

Is Claude Opus 5 automatically cheaper to run because of the half-price headline?

No. The half-price refers to the comparison with the pricier top model Fable 5; versus the direct predecessor Opus 4.8 the tariff is unchanged. The actual cost control runs through the effort dial - and per the documentation its default sits at a high level. Without actively dialing down per task, the bill can stay the same or even rise.

What is the effort dial in Opus 5 exactly?

A setting that controls, per request, how much compute the model spends before answering - simplified: how much it thinks. More effort can raise quality on hard tasks but costs more tokens; less effort is cheaper and faster. The benefit only materializes when you deliberately match the level to the task instead of leaving it on the default.

Why are Anthropic and OpenAI suddenly marketing efficiency instead of intelligence?

Because enterprise customers increasingly complain about expensive AI bills. The effort dial in Opus 5 is explicitly framed as a response, and OpenAI foregrounded economical token usage with GPT-5.6. Behind it is an admission: for real work, what matters isn't how smart a model can maximally be, but how much intelligence a specific task needs.

What should a company take away from the Opus 5 release in practice?

That cost control moves from the tariff into your own application. The effort level belongs firmly in the system, defined per task type, not in users' daily discretion. The biggest lever is not letting trivial tasks run on the expensive level in the first place - a routing and architecture question that holds regardless of which model currently leads.

Want to use AI so that every task goes to the right model level - instead of running everything on the most expensive one?