Claude pricing is easy to quote and surprisingly easy to misunderstand. A provider publishes a rate for one million input tokens and one million output tokens, but the buyer pays for a completed workflow: context, reasoning, tool calls, retries, human review and occasional failure.
Claude Opus 5 makes that distinction important. Anthropic launched the model at a reported API price of $5 per million input tokens and $25 per million output tokens—the same nominal rate as Opus 4.8 and below the company’s Fable tier. Sonnet 5 remains cheaper, while Fable 5 is positioned for the hardest work. Those list prices are useful, but the correct question is whether Opus reduces the cost per accepted task.
Always verify the current figures on Anthropic’s pricing page and API pricing documentation. Plan allowances, regional taxes, cloud-platform margins, caching rules and introductory offers can change the effective cost.
The pricing decision in one table
| Workload characteristic | Likely starting tier | Economic reason |
|---|---|---|
| Short, repetitive, easily validated | Sonnet 5 | Lower token cost; limited value from extra reasoning |
| Complex but recurring professional work | Opus 5 | Fewer retries and less repair can outweigh a higher rate |
| Rare frontier problem with very high failure cost | Fable 5 | Capability margin may justify the premium |
| Large input, short structured output | Sonnet first, Opus on failure | Input-token economics dominate |
| Small input, long analytical output | Compare Opus and Sonnet carefully | Output rate and reasoning verbosity dominate |
| Multi-step agent using external tools | Opus with strict controls | Better planning can reduce unnecessary actions |
| Customer-facing latency-sensitive interaction | Sonnet 5 | Speed and predictable cost usually matter most |
The table is a routing framework. It is not a promise that one model always uses fewer tokens or produces a better answer.
A simple Claude cost formula
For a single API task:
Model cost = (input tokens ÷ 1,000,000 × input rate) + (output tokens ÷ 1,000,000 × output rate)
Suppose an Opus 5 task uses 40,000 input tokens and 4,000 output tokens. At $5 and $25 per million respectively:
input: 40,000 ÷ 1,000,000 × $5 = $0.20;
output: 4,000 ÷ 1,000,000 × $25 = $0.10;
nominal model cost: $0.30.
That does not include cached context, batch discounts, platform charges, tools or staff time. It also assumes the published rates remain current. Use the example as a method, not a quote.
Now compare a cheaper model costing $0.12 for the same nominal task. If it needs two attempts plus eight minutes of editing, the lower API price may not create a lower business cost.
Cost per accepted task
The most useful metric is:
Cost per accepted task = total model and tool spend + human review cost + failure cost, divided by accepted outputs
This turns quality into an economic variable. Consider 1,000 monthly research tasks:
| Metric | Sonnet scenario | Opus scenario |
|---|---|---|
| Nominal model cost per attempt | $0.10 | $0.30 |
| First-pass acceptance | 70% | 90% |
| Average attempts per accepted task | 1.35 | 1.08 |
| Average human correction | 6 minutes | 2 minutes |
| Reviewer cost assumption | $60/hour | $60/hour |
| Estimated model cost per accepted task | $0.14 | $0.32 |
| Estimated review cost per accepted task | $6.00 | $2.00 |
| Combined illustrative cost | $6.14 | $2.32 |
The numbers are hypothetical, but the lesson is real: professional labour can dwarf inference spend. A stronger model earns its cost when it removes enough rework, not when it produces the most impressive demo.
The reverse can also happen. If a structured extraction workflow already achieves 99% acceptance on Sonnet, Opus has little room to save labour. The higher token rate becomes pure overhead.
Input tokens often decide the bill
Teams frequently focus on output because it is visible. Large inputs can be more consequential. A coding agent may receive repository context, tool schemas and prior messages. A research assistant may ingest hundreds of pages. Repeating that context on every turn can inflate cost regardless of model.
Reduce input waste before changing models:
retrieve only the passages relevant to the task;
summarise stable background once and cache it when supported;
keep tool schemas concise;
end unproductive conversations rather than carrying them indefinitely;
separate independent tasks into clean sessions;
store approved facts in structured fields instead of restating them in prose.
A well-designed Sonnet workflow can outperform an inefficient Opus workflow on both cost and reliability.
Output tokens and the verbosity trap
Output rates are generally higher than input rates, and agents can generate long explanations, plans and logs that nobody uses. A more capable model may still over-produce when instructions are vague.
Define the artifact before the prompt. Ask for the decision, evidence, exceptions and next action in a known structure. Set length limits where appropriate. For code, ask for the patch and verification rather than a tutorial unless a tutorial is required.
Do not suppress reasoning that the reviewer genuinely needs. The goal is not the shortest answer; it is the smallest output that supports a safe, auditable decision.
How Fast mode changes the calculation
Anthropic says Opus 5 Fast mode runs roughly 2.5 times faster than its default mode. Faster generation can create value in interactive coding, customer support escalation or time-sensitive analysis. The economic benefit depends on whether model latency is the bottleneck.
If the agent spends most of its time waiting on websites, databases or approvals, a faster model may have little effect. Measure full task duration:
queue time;
model processing;
tool execution;
human approval;
correction and retry;
final delivery.
Paying for speed makes sense only when it reduces a meaningful part of that chain. Verify whether Fast mode carries a different charge or availability rule before modelling the benefit.
The effort dial is a budget control
Opus 5’s effort control can turn one model into several economic profiles. Low or moderate effort may suit familiar tasks; high effort may improve difficult analysis.
The mature implementation is conditional. Start at a normal effort, then escalate when evidence indicates difficulty: failed tests, conflicting sources, low confidence, unresolved constraints or a high-consequence action. Do not let the model decide the budget without external limits.
Log the chosen effort level alongside task outcome. After a few hundred cases, the organisation can test whether higher effort actually raises acceptance for each task class.
Subscription pricing versus API pricing
Consumer and team subscriptions are not interchangeable with API economics. A subscription may provide access to Opus 5 through the Claude interface with plan-specific usage limits. It does not necessarily authorise automated production use or offer a predictable number of tokens.
API use is metered and easier to attribute to a workflow, but it requires engineering, security and monitoring. Cloud-platform access may add enterprise controls and a different commercial structure.
Choose by operating model:
individuals doing interactive work may prefer a subscription;
teams needing shared projects and governance should examine business-plan controls;
products and repeatable automations generally need the API;
regulated deployments may require a particular cloud, region or contract.
Do not estimate an API business case by dividing a subscription price by an assumed number of prompts. The products have different limits and responsibilities.
When Opus 5 is probably worth it
Opus is a strong candidate when:
the task needs multi-step planning across tools;
first-pass failure creates significant human rework;
prompts contain many interacting constraints;
the output supports a valuable professional decision;
errors are easy to detect before external action;
the organisation can route only difficult cases to it.
Examples include complex repository changes, evidence synthesis, contract comparison, operating reviews and investigation of a failure spanning several systems.
The value case strengthens when Opus replaces a sequence of cheaper model attempts. One well-planned run can be cheaper than three partial runs plus manual repair.
When Opus 5 is probably not worth it
Stay with Sonnet when:
the work is routine and highly structured;
validation is automatic and inexpensive;
quality is already above the business threshold;
latency or volume matters more than marginal reasoning gains;
the user wants a short interactive response;
a deterministic program should perform the task instead.
Some work should not use a language model at all. Exact calculations, schema validation, access-control enforcement and financial totals belong in deterministic systems. A model can explain the result, but should not replace the control.
A 30-day purchasing test
Run a limited evaluation rather than switching the entire estate:
Select three workload classes with at least 100 cases each.
Freeze instructions, tool access and acceptance criteria.
Route a random sample to Sonnet and Opus.
Record tokens, latency, tool calls, retries, review minutes and accepted outcome.
Review severe failures separately from average performance.
Calculate cost per accepted task and cost per business outcome.
Expand only where the advantage survives repetition.
Keep Fable as a third arm for a smaller set of genuinely difficult cases. This reveals whether Opus captures enough of the frontier benefit at a lower price.
Our Claude model comparison provides a workload-level routing matrix, while the Opus 5 release explainer covers what changed.
The verdict
Opus 5 is worth the extra token cost when it materially improves accepted outcomes, reduces retries or removes expensive human repair. It is not worth it when Sonnet already clears the threshold or when poor retrieval, excessive context and weak controls are the real problem.
Start with list price, but make the decision using total workflow economics. Measure the whole task, route by difficulty, control effort and review the failure tail. The winning model is the one that completes valuable work reliably at the lowest total cost—not the one with the lowest rate card.
