Anthropic shipped Claude Opus 5 on July 24 at 5permillioninputtokensand25 output, the same price as Opus 4.8 and half of Fable 5, while landing within half a point of Fable 5 on agentic coding. The price is the headline everyone will read. The part that actually decides your bill is the one they will skim past: a per-request effort dial with three positions, low, medium, high. Almost everyone is going to leave it on high, because high sounds like "best", and pay for reasoning most of their prompts never needed. That default-high setting is the new version of the compensation scaffolding we told you to cut when Fable 5 shipped: capability you are billed for and do not use. Here is why the dial is a cost decision, not a quality slider, and how to set it per prompt instead of per vibe.
What actually shipped
Opus 5 is a frontier model at a mid-tier price. Standard mode is 5/25 per million tokens; a Fast mode runs about 2.5x quicker at double the rate, 10/50. Context is 1M tokens, output up to 128K (300K via the Message Batches API), extended thinking is on by default, and the knowledge cutoff is May 2026, the most recent of any Claude. It also drops the 30-day data-retention requirement that Fable 5 carries, which matters if prompt privacy is a hard line for you.
The benchmarks back the "frontier at half the price" framing: 43.3% on Frontier-Bench v0.1 agentic coding against Fable 5's 33.7%, roughly triple the next model on ARC-AGI-3 (30.2% versus Opus 4.8's 1.5%), 1,861 Elo on GDPval-AA against Fable 5's 1,747, and within striking distance on SWE-bench Pro (79.2%, just under Fable 5's 80.0%). One honest caveat Anthropic notes: on Frontier-Bench, Opus 4.8 stood in as a fallback whenever a safety classifier refused a request, and the fallback frequency is undisclosed. Migration from Opus 4.8 is a drop-in model ID change. None of that is the interesting part for your prompt library. The dial is.
The dial is a control surface, not a quality knob
Here is the trap in one sentence: effort is not quality, it is reasoning budget, and the two only look the same on hard problems. Low burns fewer thinking tokens and returns faster and cheaper. High lets the model reason as long as it needs. The instinct, the moment you see low/medium/high, is to read it as a quality slider and pin it to high so you never get a worse answer. On a genuinely hard, multi-step problem, that instinct is right. On a well-specified task, it is exactly wrong: high does not produce a better extraction or a cleaner classification, it produces the same answer with a longer, billed reasoning trace in front of it.
Your prompts can improve. Promptimizer rewrites and auto-tests them for you.
That is the whole cost story. At 25permillionoutputtokensstandard,and50 in Fast mode, those reasoning traces are not free padding, they are the line item. A prompt that returns a correct, well-formed answer on low effort returns the identical answer on high effort at a multiple of the output cost. Nothing errors. The output looks fine. The bill is just bigger, and no exception will ever tell you why.
Default-high is the new scaffolding tax
We made almost exactly this argument when Fable 5 launched and its capability jump made compensation scaffolding obsolete: the manual step-by-step decomposition, the defensive self-verify loops, the redundant few-shot you wrote for weaker models became dead weight you were still paying to run. The effort dial is the same waste wearing a cleaner interface. Instead of paying for scaffolding tokens you wrote, you pay for reasoning tokens the model generates, on tasks that did not need them, because a three-position dial defaulted to its most expensive setting and nobody went back to check.
It is the same silent-drift failure mode we keep documenting, from the always-on thinking that shipped with Sonnet 5 to cache misses to stale guard-rails. The pattern never changes: a default moves cost or behavior underneath you, the output stays plausible, and the only signal is in the token counts nobody is reading. Default-high is that pattern with a knob you could have turned.
A diagram contrasting two prompts producing the same correct output, one run on low effort and one on high effort, with the high-effort run showing a long billed reasoning trace and a multiplied output cost
The default-high tax. On a well-specified task, low and high return the same answer; high just bills a longer reasoning trace in front of it. At 25(or50 Fast) per million output tokens, that trace is the line item, and nothing errors to flag it.
The routing decision moved inside the model
There is a second, more interesting shift here. For a year the routing question was always "which model for this task": default down to a cheap tier for the volume work, escalate up to a frontier model for the hard tail. We walked through that discipline when a dollar-tier agentic model first crossed the usability line, and again across every migration piece since. Opus 5 gives the escalate-up decision a middle gear. Often you no longer swap to a bigger model for a harder task, you turn the dial up on the same one. One model, three cost points, chosen per request.
The techniques you're reading about work. Test your prompts now with Prompt Score and see your score in real time.
That is genuinely useful, and it collapses a lot of multi-model routing into a single parameter. But it only helps if you know which prompt needs which gear, and that is precisely the thing a dial defaulted to high hides from you. The dial does not remove the routing decision. It moves it inside one model and makes it cheaper to get wrong quietly.
How to set the dial per prompt
Treat the effort level as a property of the prompt, decided once with evidence, not a per-call guess:
Classify the task. Is the answer well-specified (extraction, classification, formatting, first drafts, mechanical transforms) or genuinely hard (multi-step reasoning, ambiguous tradeoffs, long agentic loops)? The first bucket almost never needs high.
Start low, escalate on evidence. Run the prompt at low, then medium, and only reach for high where you can measure the lower gears falling short. Do not start at high "to be safe", that is the tax, restated as a precaution.
Score at each level. The right effort is the lowest gear whose output still clears your bar. That is a measurement, not a gut read: send the same input across levels, score the outputs, and watch where quality stops improving. Everything above that point is spend with no return.
Lock it in next to the prompt. Record the chosen effort level with the prompt itself, so it is a decision you can see and revisit, not a default someone re-guesses on every call.
The one-line version: find the floor. For most of your library the floor is lower than your instinct, and the gap between the floor and a reflexive high is your bill.
A decision matrix mapping task types to a recommended starting effort level and the signal that justifies escalating, with well-specified tasks starting low and genuinely hard reasoning tasks starting higher
Where to start the dial, by task. Well-specified work starts low and escalates only on a measured miss; genuinely hard reasoning starts higher because the floor is genuinely higher. The column that matters is the last one: the evidence that justifies the next gear, not a hunch that high is safer.
Why your library should carry the effort level
You cannot set a per-prompt effort level by vibes across a folder of scattered strings, and you certainly cannot re-check it when the next model moves the price again. A prompt that is a versioned artifact, carrying the effort level it was tuned for and a score at that level, turns all of this into something you can audit: you open the prompts set to high, you see which ones were actually measured there and which just inherited the default, you re-score, you dial down the ones that pass lower, you ship. The default-high tax becomes a line you can find and cut, not a slow leak.
That is the same portability thesis we keep landing on: the model underneath is a replaceable backend, and the value is in the one layer that survives it, a library where every prompt records what it targets and what it scored. When you can score any prompt against a fixed rubric, "which effort level" stops being a guess and becomes the lowest gear that still passes.
If you want that layer before you flip your workload to Opus 5, Keep My Prompts scores every prompt you save and keeps a version history, so setting the dial is a measured call with a paper trail instead of a reflex. Free to start.
Do this before you flip everything to high
Default to low, not high. Reverse the reflex. Make high the setting you escalate to with evidence, not the one you start from.
Split your library into two buckets: well-specified (extraction, formatting, classification, drafts) and genuinely hard (multi-step reasoning, agentic loops). The first bucket is almost all low or medium.
Score across levels on your real prompts, not toy inputs. Find the lowest gear whose output still passes, per prompt.
Record the effort level with each prompt, so the next price change is a diff you review, not a default you never revisit.
Watch Fast mode especially. At $50 per million output, a high-effort prompt left on Fast is the most expensive way to get an answer low effort would have nailed.
The dial is real leverage. Default-high is the expensive way to waste it.
Opus 5 is a frontier model at half the price of the last one, and the effort dial is a genuine lever: three cost points on one model, a middle gear for the escalate-up decision, real money saved when you set it right. But a lever you leave in one position is not a lever, it is a default, and the default here is the expensive one. The teams that come out ahead on Opus 5 are not the ones who flipped everything to high to be safe. They are the ones who knew, prompt by prompt, the lowest gear that still passes, because their library could tell them.
