The Vibe Father
Claude Opus 5 costs $5 per million input tokens and $25 per million output tokens, holds the same price as Opus 4.8, and undercuts Fable 5 by half. Fast mode runs roughly 2.5x quicker at twice the base rate, which lands at about $10/$50. Five effort levels — low, medium, high, xhigh, max — decide how many tokens a task actually consumes.
That last sentence is where the money is. List price is the least interesting number in this launch. What determines your bill is how much thinking the model does per task, and that is a setting you control. This guide covers how to choose it, what to measure, and how to stop a coding agent from quietly becoming your largest line item.
Related every Opus 5 benchmark explained, token cost and billing discipline, and the ROI measurement playbook.
The price table
| Model / mode | Input per 1M | Output per 1M | Notes |
|---|---|---|---|
| Claude Opus 5 | $5 | $25 | Default rate |
| Claude Opus 5 fast mode | ~$10 | ~$50 | ~2.5x speed at 2x base rate |
| Claude Opus 4.8 | $5 | $25 | Same price, older model |
| Claude Fable 5 | $10 | $50 | Previous flagship |
Note what this means for anyone currently on Opus 4.8, the upgrade is free at list price. There is no budget conversation to have. The only question is whether the new model produces better accepted work on your repository, which you can answer in two weeks.
For anyone on Fable 5, the conversation is different and more interesting. You are being offered equal or better measured capability at half the rate, with two documented exceptions — Fable 5 reportedly leads on health tasks, and Mythos 5 leads on legal. If neither applies to you, staying on Fable 5 is a decision you should be able to defend with data.
Effort levels, the real cost dial
Opus 5 exposes five effort settings. Higher effort means more reasoning tokens before the answer, which means higher cost and higher latency, and — up to a point — better results. Reporting notes that max effort occasionally scores below xhigh on some benchmarks while costing more, so the curve is not monotonic.
| Effort | Relative token spend | Good fit | Bad fit |
|---|---|---|---|
| low | Lowest | Renames, formatting, mechanical edits, classification | Anything requiring a design choice |
| medium | Low | Small features with clear tests, doc updates | Cross-service changes |
| high | Moderate | Most production agent work | Trivial edits — pure waste |
| xhigh | High | Hard debugging, migration planning, unfamiliar code | Latency-sensitive interactive paths |
| max | Highest | Benchmarks, genuinely stuck problems, one-off hard analysis | Default routing — this is the expensive mistake |
The single most common cost failure we see is teams setting the highest effort globally because it produced the best demo, then discovering a month later that 80% of their spend went to tasks a low-effort call would have handled identically. Effort should be a function of task type, not a global default.
Latency is part of the price
Artificial Analysis measures Opus 5 at roughly 52.8 output tokens per second with about 62.7 seconds to first token in the max-effort configuration. That is thinking time, and it is real.
| Surface | Latency tolerance | Recommendation |
|---|---|---|
| Autocomplete | Under 300ms | Never Opus 5 — use a small fast model |
| Interactive chat | A few seconds | Low/medium effort, or fast mode, or Sonnet 5 |
| PR review bot | A minute or two | High effort is fine |
| Background ticket agent | Minutes | xhigh is fine, max for stuck tasks |
| Nightly batch analysis | Hours | Anything goes |
Fast mode exists precisely for the middle rows. Paying 2x the token rate to get 2.5x the speed is a good trade when a human is waiting, and a bad trade when a queue is. Decide per surface, not per company.
Where the tokens actually go
Before optimising the model, look at what you are sending it. In most agent stacks the token bill breaks down roughly like this, and only one line is about the model at all.
| Source | Typical share | Fix |
|---|---|---|
| Re-sent context each turn | Large | Prompt caching, tighter retrieval |
| Reasoning tokens | Large at high effort | Right-size the effort level |
| Retries after failure | Sneaky | Better tests so failures are caught early |
| Tool output dumped raw | Underestimated | Summarise tool results before they enter context |
| Actual answer tokens | Small | Nothing — this is the part you want |
A 1M-token context window is a capability, not an instruction. Filling it is almost always the wrong move, you pay for every token, retrieval quality degrades with irrelevant material, and you lose the ability to reason about what the model actually saw. Send the smallest context that contains the answer.
Cost per accepted change
Here is the only cost metric worth reporting to a finance partner.
Cost per accepted change = (all tokens spent on a task, including retries) x rate, divided by changes that merged and survived a week.
This number is what makes a more expensive model look cheap. A model that lands the change on the first attempt at $25 per million output tokens beats a model at $10 that needs four attempts and a human repair. It is also what exposes the opposite case, a high-effort setting that burns four times the tokens to produce a diff that was already correct at medium.
| Metric | Report it? | Why |
|---|---|---|
| Total monthly spend | Yes | Budget reality |
| Cost per accepted change | Yes | The efficiency number |
| Repair rate within 7 days | Yes | Catches fluent-but-wrong output |
| Tokens per request | Internal only | Diagnostic, not a goal |
| Benchmark scores | No | Not your workload |
A concrete cost-control checklist
- Set effort per task type in code. Not a global default. Map ticket labels or agent modes to effort levels.
- Turn on prompt caching for any repeated system prompt or repository context. This is usually the largest single saving.
- Cap retries. Three attempts, then escalate to a human. Unbounded retry loops are how a $200 month becomes a $4,000 month.
- Summarise tool output before it enters the context window. Raw log dumps are the quietest budget leak in agent stacks.
- Route by lane. Cheap model for mechanical work, Opus 5 for the hard lane. See the routing table.
- Set a hard monthly ceiling with alerting at 60% and 85%. Discover overspend on the 12th, not the 30th.
- Pin the model revision. Behaviour drift changes token consumption as well as quality.
- Re-measure monthly. Prices and effort curves both move.
A worked example, one month of agent spend
Numbers make this concrete. Take a five-engineer team running a background ticket agent, a PR review bot, and an interactive assistant. Assume 900 agent tasks in a month.
| Workload | Tasks | Naive setup | Tuned setup |
|---|---|---|---|
| Mechanical edits | 400 | Opus 5 at max effort | Sonnet 5 at low effort |
| Routine features | 300 | Opus 5 at max effort | Opus 5 at high effort |
| Hard debugging | 120 | Opus 5 at max effort | Opus 5 at xhigh effort |
| PR review | 80 | Opus 5 at max effort, no caching | Opus 5 at high effort, cached repo context |
The naive setup is not a strawman. It is what happens when someone picks the best model at the highest effort during a proof of concept and nobody revisits it. The tuned setup changes no vendor and no model family — it changes which task goes where and turns on caching.
In our own measurements across this shape of workload, the dominant savings came in this order, caching repeated repository context, then dropping mechanical work to a cheap model, then reducing effort on routine work. Switching models entirely was the smallest lever of the three. That ordering surprises people who arrive at cost control expecting the answer to be "use a cheaper model."
Your ratios will differ. The ordering of levers usually does not.
Prompt caching is the first thing to turn on
If your agent sends the same system prompt, the same repository map, or the same style guide on every turn, you are paying full input price for identical tokens repeatedly. Caching that context is the single highest-return change available in most stacks, and it requires no change to model choice, prompt design, or output quality.
| Context type | Cacheable? | Notes |
|---|---|---|
| System prompt / instructions | Yes | Stable across every call — always cache |
| Repository structure map | Yes | Re-cache when the tree changes materially |
| Coding standards, review rubric | Yes | Changes monthly at most |
| Current file contents | Partly | Cache the stable files, not the working set |
| Conversation history | Depends | Cache prefixes, the tail changes every turn |
| Tool output | No | Summarise it instead |
The discipline that pairs with caching is prefix stability. Caching only helps if the beginning of your prompt is byte-identical between calls. Injecting a timestamp, a request ID, or a shuffled tool list at the top of the prompt silently destroys the cache and the saving with it. Put volatile content at the end.
Which lever to pull first
- Cache repeated context. Zero quality risk, largest typical saving.
- Summarise tool output before it enters context. Also zero quality risk, and frequently the second-largest.
- Right-size effort per task type. Small quality risk on the tasks you downgrade — measure it.
- Move mechanical work to a cheaper model. Moderate quality risk, needs an escalation path on failure.
- Cap and reduce retries. Trades throughput for predictability.
- Change the frontier model. Highest disruption, and usually the smallest saving of the six.
Teams routinely start at step six because it is the one the launch cycle is talking about. Start at step one.
Reading the fast-mode trade correctly
Fast mode doubles your rate for about 2.5x the speed. Whether that is good depends entirely on what the latency buys you.
| Situation | Fast mode worth it? | Reason |
|---|---|---|
| Engineer blocked waiting for output | Yes | Engineer time costs more than tokens |
| Live demo or customer-facing assistant | Yes | Perceived quality is latency-bound |
| Overnight batch job | No | Nobody is waiting |
| CI check with a 10-minute budget | Usually no | Default speed fits the window |
| Trying to fix a bad retrieval design | No | You are paying to go fast in the wrong direction |
That last row is the one worth internalising. Fast mode is a latency purchase, not a quality purchase. If your agent is slow because it is re-reading a monorepo every turn, fast mode makes you burn money more quickly rather than saving any.
What Anthropic's own framing gets right and what it leaves out
The launch framing — near-Fable-5 capability at half the token price — is defensible. On the published Intelligence Index, Opus 5 is at 61 to Fable 5's 60, and the price genuinely halves. Artificial Analysis puts the practical gain at roughly 26% lower cost per task at comparable intelligence.
What the framing leaves out is that the headline benchmark numbers come from the max-effort configuration, which is the most expensive and slowest way to run the model. The price-per-token comparison and the capability comparison are not measured at the same operating point. That does not make the claim false. It makes it a claim you should re-verify at the effort level you will actually deploy.
Budgeting for a model that changes every few weeks
The release cadence is the part of this that breaks annual planning. Opus 4.8 shipped in May, Fable 5 and Mythos 5 arrived in June, Opus 5 landed in July. Any budget built on "we picked a model and its price" has a shelf life measured in weeks.
The version that survives is a budget built on unit economics rather than on a vendor SKU. If you know your cost per accepted change and your monthly volume, a new model is a simple substitution, does it move the unit cost up or down, and by how much? You do not need to re-plan. You need to re-measure one number.
| Planning approach | Survives a model launch? |
|---|---|
| "We budgeted for Fable 5 seats" | No — the SKU changed underneath you |
| "We budgeted a flat monthly total" | Partly — but you cannot explain variance |
| "Our cost per accepted change is known at a known volume" | Yes — substitution becomes arithmetic |
Set a ceiling, alert well before it, and review the unit number monthly. That is enough process. Anything heavier will be abandoned by the third launch cycle, and there will be a third launch cycle before the quarter ends.
Common questions
How much does Claude Opus 5 cost?
$5 per million input tokens and $25 per million output tokens. Fast mode is about twice that for roughly 2.5x the speed.
Is Opus 5 cheaper than Fable 5?
Yes — half the rate on both input and output, at equal or better published Intelligence Index performance.
Does a bigger context window cost more?
Only if you fill it. The 1M window is a ceiling, not a floor. Sending less context is the cheapest optimisation available to you.
What effort level should we run in production?
High for most agent work. Reserve xhigh for hard debugging and migrations, max for genuinely stuck problems, and low or medium for mechanical edits.
What is the single biggest saving available?
Usually prompt caching on repeated context, followed by right-sizing effort per task type. Model choice is typically third.
Sources and further reading
- Anthropic. Introducing Claude Opus 5
- DataCamp. Claude Opus 5 pricing and fast mode
- Artificial Analysis. Claude Opus 5 speed and latency
- The Decoder, half the token price
- Routing models through OpenRouter
Cost discipline in AI-assisted engineering is not about spending less. It is about being able to explain what you bought. A team that can say "we spend $3,100 a month, our cost per accepted change is $4.20, and it fell 30% when we moved mechanical edits to low effort" is in control. A team that can only say "the bill went up" is not, regardless of how much they are spending.
Build the measurement before you build the optimisation. Two weeks of honest data will tell you more than any launch-day benchmark table, including this one.
