Claude Opus 5: Measure Cost per Accepted Outcome, Not Token Price

Anthropic released Claude Opus 5 on July 24 at the same API price as Opus 4.8: $5 per million input tokens and $25 per million output tokens. The model adds five effort levels, uses adaptive thinking by default, supports a one-million-token context window, and is positioned for difficult agentic and enterprise work. Early independent evaluation also suggests that higher effort can improve complex knowledge-work results—but can take more than 25 minutes per task.

That combination creates a trap for AI app builders. A stronger model at an unchanged list price sounds like a free upgrade. It is not. Thinking tokens, longer outputs, additional turns, tool calls, retries, human review, and latency can all change the real cost of delivering one result that a customer can actually use.

For nontechnical founders and small product teams, the decision is therefore not “Is Opus 5 better?” It is: On which jobs does Opus 5 produce more accepted outcomes per dollar, per reviewer hour, and per minute of customer waiting than the model you already use?

This guide turns the launch into a product decision. You will get precise terms, a reusable cost worksheet, an effort-routing matrix, a hypothetical customer-support scenario, a small-team evaluation procedure, failure modes, rollout rules, and explicit cases where Opus 5 should not be your default. This is not a hands-on YBuild benchmark, and it does not treat vendor demonstrations or one external benchmark as a reliability rate for your app.

What Claude Opus 5 changes—and what remains unproven

Anthropic's official Opus 5 documentation describes more than a model-name change. Opus 5 has a one-million-token context window, a 128,000-token maximum output, adaptive thinking enabled by default, effort settings from low through max, a lower 512-token prompt-cache minimum, beta support for changing tools during a conversation, and optional server-side fallbacks. Anthropic says the largest capability gains are in deep reasoning, long-horizon agent work, code review, long-context tasks, office documents, and multi-agent coordination.

The price card did not increase. Anthropic's current pricing table lists Opus 5 at $5 per million base input tokens, $25 per million output tokens, $6.25 per million five-minute cache-write tokens, and $0.50 per million cache-hit tokens. Fast mode is a separate research preview at twice the base input and output price. AWS also confirmed Opus 5 availability through Amazon Bedrock and Claude Platform on AWS, with different data-governance options.

Those are useful product facts. The launch does not prove that:

your prompt will use the same number of tokens as before;
a higher effort level will improve your particular acceptance rubric;
one million tokens of available context should be filled;
a longer or more polished answer will need less review;
an agent that takes more turns will finish within your customer latency promise;
a result that passes a general benchmark will follow your policy, cite your sources, or update your system correctly.

Anthropic itself tells teams to adjust effort based on their own evaluations. Treat “step-change improvement” as a vendor claim to test, not as permission to remove your acceptance gate.

Six terms to define before comparing models

Model comparisons become misleading when teams use “success,” “quality,” and “cost” without agreeing on what they mean. Define these six terms first.

Attempt is one end-to-end run from an accepted user request to a terminal product state. If an orchestration layer silently retries twice, the customer saw one request but the business paid for three attempts. Valid completion means the requested final state exists and the workflow followed required policy. A fluent support recommendation is not valid if it cites an expired policy. A generated app is not valid if the checkout flow fails. Accepted outcome is a valid completion that passes a written product rubric. The rubric can include factual correctness, source coverage, policy compliance, structured-output validity, tone, latency, accessibility, and required human approval. “Looks good to me” is not a stable acceptance definition. Reviewer minute is a minute a qualified person spends checking, correcting, approving, or recovering the result. Ten minutes from a policy specialist should not disappear from the economics because the API bill was small. Cost per attempt includes model tokens, cache operations, tool and retrieval calls, infrastructure, and directly attributable review or recovery labor for that attempt. Cost per accepted outcome is the total observed cost of all attempts in the evaluation divided by the number of accepted outcomes:

text

cost_per_accepted_outcome =
  (model_cost
   + cache_cost
   + tool_and_retrieval_cost
   + infrastructure_cost
   + reviewer_cost
   + retry_and_recovery_cost)
  / accepted_outcomes

Keep severe policy or safety failures as a separate launch gate. Do not “price them in” and allow a cheap average to cancel an unacceptable event.

Why unchanged token pricing can still change your unit economics

The visible price is only one multiplier. The actual model charge depends on how much context enters, how much thinking and answer text comes out, how often tools are used, whether prompts hit the cache, and how many times the workflow retries.

Opus 5 makes several of those variables more important. Its model overview says effort defaults to high in the API and Claude Code. The migration documentation says thinking is on by default, longer user-facing responses are common, progress narration is more frequent, and the model may delegate to subagents more readily. It also warns that max_tokens covers both thinking and visible response text. A configuration copied from an older model may therefore stop early, cost more, or produce a different interaction pattern even when the input is unchanged.

Long context creates another deceptive shortcut. A one-million-token window is capacity, not an instruction to upload every document. More context can add retrieval noise, sensitive data exposure, cache-write cost, latency, and review burden. A smaller evidence pack with good retrieval can beat an enormous unfiltered prompt on both quality and cost.

Caching also changes the result. Reusing a stable policy, schema, or documentation set can make a capable model more economical because cache hits are heavily discounted. Constantly rebuilding the system prompt or changing document order can destroy that benefit. Measure actual cache reads and writes instead of applying the base input price to every token.

Finally, review time can dominate the model bill. If a cheaper model creates three plausible drafts that each require eight minutes of expert checking, while a more capable route creates one acceptable result that needs two minutes, the expensive token price may produce the cheaper outcome. The reverse is also possible: a polished Opus answer may take longer to inspect because it is longer and its subtle claims are harder to verify.

Read the early benchmarks without outsourcing your decision

Independent results are helpful when they expose trade-offs instead of declaring a universal winner. Artificial Analysis tested all five Opus 5 effort levels on its private AA-Briefcase agentic knowledge-work benchmark. It reports that max, xhigh, and high took the top three positions in that evaluation. It also reports average task costs of $17.79, $14.26, and $10.41 respectively, with average durations of 36.2, 34.3, and 25.7 minutes. The gains were stronger in objective criteria and analytical quality than in presentation quality.

That is exactly the kind of evidence founders should want: quality, cost, and time shown together. It is still one provider's proprietary task set, scoring design, tool environment, and model configuration. Its “cost per task” is not your cost per accepted outcome.

ARC Prize offers a different signal. Its verified Opus 5 results report 30.2% on the ARC-AGI-3 public demo at high effort and disclose that the short test window did not include a max run for that benchmark. The result supports stronger abstract problem solving under a specific setup. It does not tell you whether an onboarding assistant will cite current pricing, whether a support workflow will apply refund policy correctly, or whether a generated app will preserve tenant boundaries.

The correct reading is:

Opus 5 is credible enough to deserve workload-specific testing.
Effort level is a meaningful product configuration, not a decorative setting.
Higher measured capability may come with more turns and longer wall time.
A public leaderboard can help choose candidates, but only your acceptance set can choose a production route.

Build an acceptance rubric before you run the models

Do not generate a pile of outputs and invent the scoring rule after seeing which model produced them. Write the rubric first. For each case, mark both hard gates and scored qualities.

Dimension	Example hard gate	Example scored measure
Final state	Required artifact or update exists	Completeness against requested sections
Factuality	No unsupported critical claim	Percentage of material claims with valid evidence
Policy	No forbidden recommendation or action	Correct handling of edge-case policy
Structure	Output parses against required schema	Number of manual formatting fixes
User value	Answers the actual user job	Reviewer usefulness score with anchors
Latency	Completes before product timeout	p50 and p95 completion time
Review	Qualified reviewer signs off	Reviewer minutes and correction count
Recovery	Failed run leaves no unsafe state	Time to diagnose and restore

Use anchor examples. “5/5 quality” is vague; “can be sent to the customer without factual, policy, or formatting correction” is observable. If two reviewers would disagree, calibrate them on several examples before comparing models.

Separate critical cases from ordinary cases. A support draft that uses the wrong greeting is not equivalent to one that promises an ineligible refund. Report them in different categories. An overall 92% pass rate can hide a 0% pass rate on the ten cases that matter most.

Include refusal and abstention as valid outcomes when the product should not answer. A model that asks for missing evidence can be more useful than one that confidently completes every case.

Use this cost-per-accepted-outcome worksheet

Create one row for every attempt, not one row for every user request. Keep raw values so the team can audit the aggregate later.

Field	What to record
Case ID	Stable identifier and risk tier
Model route	Provider, exact model ID, effort level
Configuration	Prompt version, retrieval version, tool set, cache policy
Input	Base, cache-write, and cache-hit tokens
Output	Thinking plus visible output where reported
Tools	Calls, failures, external API cost
Time	Queue, first token, completion, review, recovery
Attempts	Initial run plus automatic and manual retries
Acceptance	Pass/fail by each hard gate and scored dimension
Human work	Reviewer role, minutes, corrections
Failure	Taxonomy, user impact, durable side effect
Evidence	Trace or run ID, final artifact, approval record

Then calculate four views:

Cost per attempt reveals raw operating expense.
Acceptance rate reveals how often attempts become usable outcomes.
Cost per accepted outcome combines expense and yield.
Reviewer minutes per accepted outcome exposes scarce human work that a dollar-only chart hides.

Also chart p95 completion time and critical-failure count. A route can be cheap on average and still be unsuitable for an interactive feature or a regulated action.

Never compare a new model using a new prompt, new retrieval system, and new rubric at the same time. Change one primary variable or label the result as a system comparison. In production the whole system matters, but you still need to know which change caused an improvement.

A concrete scenario: a support escalation copilot

Consider a hypothetical SaaS team that wants an AI copilot to prepare escalations for a human support lead. Each job receives a ticket history, account facts, the current refund policy, incident notices, and relevant help-center pages. The copilot must identify the issue, cite the governing evidence, recommend the next action, draft a customer response, and abstain when account data or policy is insufficient. It cannot issue a refund.

This is a good candidate for Opus 5 testing because the job combines long documents, conflicting evidence, policy interpretation, structured output, and a consequential recommendation. It is not proof that Opus 5 will win.

Build an evaluation set from real, permission-safe historical patterns:

routine questions with one clear policy answer;
long conversations containing irrelevant details;
policy changes where an older article conflicts with a current rule;
similar account names or plans;
partial outages that change the normal resolution;
emotionally charged messages where tone matters;
requests that require missing account data;
cases that must escalate without a recommendation.

Run the same cases through the current production route and candidate Opus 5 routes at low, medium, and high. Reserve xhigh or max for a small subset of genuinely difficult cases because early external evidence shows that those modes can take substantially longer.

The hard gates could be: correct policy version, no invented account fact, valid citations, no unauthorized commitment, valid JSON, and correct abstention. Then measure reviewer minutes, correction count, API and tool cost, total time, and accepted outcomes.

Possible decisions include:

keep routine cases on the cheaper model;
route only high-ambiguity or high-value escalations to Opus 5;
start Opus 5 at medium and escalate to high only when the first pass identifies conflicting evidence;
reject Opus 5 for interactive use if p95 latency breaks the support workflow;
adopt Opus 5 because fewer retries and less specialist review offset the higher per-attempt cost.

Those are decision patterns, not claimed test results.

Route by job difficulty instead of choosing one default

Most small teams do not need one model for everything. They need a routing policy that is simple enough to explain and audit.

Workload	Starting route	Escalate when	Do not escalate merely because
Classification, extraction, formatting	Fast lower-cost model	Schema failures or material ambiguity persist	The input is long but easy
Customer-facing draft	Sonnet-class or current proven route	Policy conflict, high-value account, repeated rejection	The user asks for more polished prose
Multi-document decision support	Opus 5 `medium` or `high` candidate	Evidence conflicts or rubric misses at lower effort	A benchmark calls it “knowledge work”
Long-running agent job	Bounded Opus 5 trial	Recovery, planning, or verification needs improve measurably	More autonomy looks impressive
High-risk state change	Best evaluated model plus approval	Never bypass policy or human authorization	The model score is high

Routing signals should come from product state: case risk, ambiguity, document conflict, first-pass rubric failure, customer tier, and latency budget. Avoid asking a model to declare itself “complex” without limits; that can send too much traffic to the expensive route.

Use an escalation ceiling. A failed high attempt should not automatically retry at max forever. Define the maximum model cost, tool calls, turns, and wall time, followed by a human or safe fallback.

Test effort as a product control, not a quality slider

Anthropic's effort documentation makes effort a direct control over how many tokens the model uses when responding. Opus 5 supports low, medium, high, xhigh, and max. Higher is not automatically better for the business.

Test at least three levels on the same case set. For each level, compare:

hard-gate acceptance;
critical failure type;
total and output tokens;
number of turns and tool calls;
completion time;
reviewer minutes;
correction severity;
cost per accepted outcome.

Look for the elbow of the curve: the lowest effort that preserves acceptance on a workload. If medium and high produce the same accepted outcomes, the extra thinking at high may be waste. If high prevents expensive review or failure on difficult cases, it may be the cheaper route.

Pin effort explicitly. A default can change across surfaces or model generations, and a hidden default makes later comparisons ambiguous. Pin the exact model ID, prompt, tools, retrieval configuration, fallback behavior, and effort in the evaluation receipt.

Be careful with fallbacks. A successful response produced by another model is not an Opus 5 success. Log the model that actually completed the run, why the fallback happened, and whether the product disclosed any behavior change.

Common comparisons that produce the wrong answer

Comparing list prices only. This ignores token volume, caching, tools, retries, review, and acceptance yield. Using one impressive task. One successful founder prompt demonstrates possibility, not repeatability. Use representative cases and repeated runs where variability matters. Scoring style as correctness. Opus 5 may produce longer, more polished work. A reviewer must still check evidence, policy, and final state. Filling the context window. More documents can reduce relevance and increase cost. Retrieve the smallest sufficient evidence set and record which sources were used. Changing the whole stack. A new prompt, model, tool set, and retrieval index can improve the product, but the experiment cannot attribute the gain to Opus 5. Ignoring reviewer skill. A generalist and a domain specialist may accept different errors. Use qualified reviewers for critical cases and record their role. Averaging across risk tiers. Easy, high-volume cases can hide catastrophic misses in a small critical set. Apply critical gates separately. Treating refusal as failure. When evidence is missing or an action is outside scope, abstention can be the correct product outcome. Allowing unlimited effort escalation. Automatic retries can turn an ambiguous request into a slow and expensive failure loop. Stop and ask or hand off.

When Opus 5 should not be your default

Do not default to Opus 5 when the task is deterministic enough for code, a rule engine, search filter, database query, or schema validator. A stronger language model is not a substitute for a reliable primitive.

Do not use it to rescue an undefined product. If the team cannot state what an accepted outcome is, more intelligence will produce more persuasive ambiguity. Fix the job, evidence, permissions, and rubric first.

Avoid it in tight interactive loops until your own p95 data fits the experience. External tests show that frontier performance can require long runs. A user waiting for autocomplete, a form validation, or a simple classification does not benefit from a 25-minute reasoning process.

Do not send sensitive or residency-constrained data merely because the model is capable. AWS documents zero-data-retention and regional options for its routes, but deployment choice, data classification, logging, retention, access control, and vendor terms still require review.

Finally, do not let a stronger model remove approvals from consequential actions. Capability and authority are different product decisions. An accepted recommendation can still require a human before money moves, access changes, a message is sent, or production state is modified.

Run a seven-day founder evaluation

Day 1: Define the job. Choose one production-shaped workflow, one user group, and one terminal state. Write the hard gates and review anchors before generating outputs. Day 2: Assemble cases. Select 30–60 permission-safe cases across ordinary, difficult, critical, and abstention conditions. Keep a frozen holdout group if prompt tuning will occur. Day 3: Capture the baseline. Run the current production route. Record attempts, tokens, tools, time, acceptance, reviewer minutes, and failures. Day 4: Test effort levels. Run Opus 5 at low, medium, and high with the same system configuration. Use xhigh or max only on a bounded difficult subset. Day 5: Review blind. Hide model identity where practical. Have qualified reviewers apply the prewritten rubric and label corrections and critical failures. Day 6: Calculate the outcome economics. Compare acceptance, cost per accepted outcome, reviewer minutes, p95 latency, and critical failures. Segment by risk and difficulty rather than publishing one blended number. Day 7: Make a routing decision. Choose adopt, route selectively, continue trial, or reject for now. Document the model, effort, prompt, retrieval, tool, budget, fallback, approval, monitoring, and rollback settings.

Re-run the critical set before every model, prompt, retrieval, policy, or tool change. The launch evaluation becomes a regression asset, not a one-time purchasing exercise.

The launch decision to make now

Claude Opus 5 is significant because it puts stronger reasoning, long context, agentic work, and five effort levels at the existing Opus API price. Early independent results make it a serious candidate for complex knowledge work. They also make the operating trade-off visible: stronger outcomes can require more turns, more time, and a different cost profile.

Do not respond by switching every workflow. Pick one job where reasoning or review cost is currently painful. Define an accepted outcome, measure the entire attempt, compare effort levels, and route only the cases where the model improves outcome economics without breaking latency, policy, privacy, or authority boundaries.

The winning model is not the one with the lowest token price or the highest public score. It is the route that repeatedly produces a valid, reviewable, policy-compliant result at a cost and speed your product can sustain.

References