I Did the Math on Claude Opus 5: Max Effort Cost 94% More Than High Effort

Claude Opus 5 launched on July 24. The first takes in my feed were predictable:

"Same price means the upgrade is free."

"Max effort is obviously the best setting."

"Migrating from Opus 4.8 is just changing one model string."

The first is incomplete. The other two can get expensive fast.

I pulled Anthropic's API docs, pricing table, and the first independent effort-level measurements. The headline benchmark is real. So is the cost curve hiding behind it.

TL;DR

• NO, max effort should not be your default. It gained 2 Artificial Analysis Intelligence Index points over high while the reported evaluation spend rose about 94%.
• Opus 5 costs $5 per million input tokens and $25 per million output tokens, unchanged from Opus 4.8.
• You get 1M context, 128K maximum output, thinking on by default, and five effort levels from low to max.
• A 100K-input, 20K-output run costs $1 standard, $0.55 with a cache hit, $0.50 in batch, or $2 in fast mode.
• Migration has a breaking edge: disabling thinking at xhigh or max returns HTTP 400.
• I would start production at high, test medium, and escalate only failed high-value tasks.

What Anthropic actually shipped

Opus 5 is not a preview or a leaked model name. Anthropic released it on July 24 as claude-opus-5.

Field	Claude Opus 5
API model ID	claude-opus-5
Context window	1,000,000 tokens
Maximum output	128,000 tokens
Standard input	$5 / MTok
Standard output	$25 / MTok
Thinking	On by default
Effort levels	low, medium, high, xhigh, max
Default effort	high

The official migration notes call this a step-change over Opus 4.8, especially for agentic coding, long-horizon work, and test-time compute scaling.

I care more about the API behavior than the launch adjectives.

Thinking now runs by default. The 1M context is both the default and maximum. The maximum output is 128K. Prompt caching starts at 512 tokens instead of 1,024. The model also tends to write longer deliverables, narrate agent progress more often, and delegate to subagents more readily.

That last paragraph is why "same price" does not mean "same bill."

The benchmark is strong, but effort changes the meaning

Artificial Analysis scored Opus 5 at 61 on its Intelligence Index at max effort. That put it just above Fable 5 at 60, GPT-5.6 Sol at 59, and Opus 4.8 at 56.

But I would not stop at the max row.

Effort	Intelligence Index	Reported evaluation spend	Output tokens
Medium	56	$1,114.96	29M
High	59	$1,973.77	52M
Xhigh	60	$2,909.91	76M
Max	61	$3,835.51	100M

These are evaluation-suite totals, not a prediction of anyone's monthly API invoice. They are still useful because the evaluator kept the suite comparable.

My math:

Max vs high cost increase:
($3,835.51 - $1,973.77) / $1,973.77 = 94.3%

Index gain:
61 - 59 = 2 points

Going from high to max nearly doubled the measured evaluation spend for two points. Going from xhigh to max added one point while adding about $926.

I am not saying max is useless. I am saying max is an escalation policy.

If one difficult debugging task is worth $20,000, extra reasoning is cheap. If you run 50,000 classification jobs, it is a budget leak.

The $1 agent run becomes four different bills

The official Claude pricing table lists the same $5/$25 standard rate as Opus 4.8. The modifiers matter more than the sticker.

Assume one repository-agent run uses 100K input tokens and 20K output tokens.

Route	Calculation	Cost per run	Cost at 1,000 runs
Standard	0.10 x $5 + 0.02 x $25	$1.00	$1,000
Cache hit	0.10 x $0.50 + 0.02 x $25	$0.55	$550
Batch	$1.00 x 50%	$0.50	$500
Fast	0.10 x $10 + 0.02 x $50	$2.00	$2,000
US-only	$1.00 x 1.1	$1.10	$1,100

This is the part I would screenshot for a budget review:

Fast mode on 1,000 runs costs $1,000 more than standard. A stable cache hit saves $450. Batch saves $500.

The right mode depends on whether waiting is expensive.

For an interactive incident-response agent, paying $2 instead of $1 may be trivial. For overnight evals, paying $2 instead of $0.50 is indefensible.

The migration catch is an HTTP 400

The model ID change is one line:

model = "claude-opus-5"

The behavior change is not.

Opus 5 enables thinking by default. The effort parameter controls depth:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "high"},
    messages=[
        {
            "role": "user",
            "content": "Find the root cause, implement the fix, and run tests."
        }
    ],
)

You do not need to add a thinking field. It is already on.

Here is the breaking combination:

# This returns HTTP 400 on Opus 5.
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    thinking={"type": "disabled"},
    output_config={"effort": "max"},
    messages=[{"role": "user", "content": "Review this change."}],
)

Disabling thinking is accepted only at high or below. If my application truly needs thinking disabled, I would keep effort at high or lower. If I need xhigh or max, I would remove the disabled-thinking field.

I would also revisit max_tokens. Thinking and visible response text share that hard output limit. A limit that worked for non-thinking Opus 4.8 can now truncate the job.

The effort decision tree

This is the routing logic I would start with:

def choose_opus_5_effort(task):
    value = task["business_value_usd"]
    failed_high = task.get("failed_at_high", False)
    batchable = task.get("batchable", False)
    latency_sensitive = task.get("latency_sensitive", False)

    if task["type"] in {"classification", "simple_summary"}:
        return "Use Sonnet or a cheaper model"

    if batchable:
        return "Opus 5 high via Batch API"

    if failed_high and value >= 1000:
        return "Retry Opus 5 at xhigh"

    if failed_high and value >= 10000:
        return "Retry Opus 5 at max"

    if latency_sensitive:
        return "Opus 5 high; test fast mode against SLA value"

    return "Opus 5 high, then test medium on a canary"

I would add one more rule outside the function: never silently fall back to a different model. Opus 5 adds a beta server-side fallback mode, but production logs still need to record which model handled the request.

What I would do this week

If I already use Opus 4.8

I would create a 100-300 task canary. I would compare accepted results, retries, human corrections, tool-call failures, output tokens, total latency, and cost per accepted task.

I would not migrate every call on day one.

If I run a coding agent

I would start at high, remove redundant "verify your work" instructions, and inspect whether the model over-verifies. Anthropic says Opus 5 checks its work more often without being told.

Then I would test medium on routine repository work.

If I run high-volume workloads

I would keep Sonnet first and escalate only failures. Opus 5 is a premium problem solver, not a cheap classifier.

If I need the hardest possible model

I would compare Opus 5 max directly with Fable 5. Opus 5 costs half as much per token, but Fable remains Anthropic's highest-capability product tier.

The bigger picture

Opus 5 is not just another benchmark release. It makes test-time compute an explicit product surface.

The model name no longer determines the bill by itself. The combination of model, effort, cache, batch, speed, geography, output behavior, and retry policy determines the real cost.

That is good news for teams willing to route intelligently. It is bad news for anyone who sets every dial to maximum and calls it an upgrade.

If you want the full pricing tables, benchmark evidence labels, and migration matrix, I put them in the data-cited Opus 5 review.

If you want to swap between Anthropic, OpenAI, Google, and other models through one OpenAI-compatible endpoint, that is roughly what TokenMix does. Disclosure: I work on the research side. Opus 5 was not yet listed in TokenMix's public catalog when I checked on July 25, so verify the live model list before routing traffic.

Bottom line

Claude Opus 5 is a serious upgrade at the same per-token price as Opus 4.8. I would migrate through a high-effort canary, test medium for savings, and reserve max for expensive failures.

The model got smarter. The default deployment should get more selective.

Which matters more in your workload: the last two benchmark points, or cutting the reasoning bill nearly in half?