Claude Opus 5 Effort Parameter Guide: How to Reduce Claude API Costs Without Switching Models

Every production LLM stack I've audited in the last year has the same component: a routing layer that classifies incoming work and dispatches it to Haiku, Sonnet, or Opus based on difficulty. Everyone builds it. Everyone maintains three sets of prompts for it. And everyone eventually gets burned by it, because the router itself misclassifies, and because switching models mid-conversation throws away your prompt cache.

Claude Opus 5 launched yesterday with a different answer to "how do I reduce my Claude API costs": one model and a dial. The effort parameter (low, medium, high, xhigh, max) controls how much the model thinks and how much work it does per request. Anthropic is explicitly positioning it as the toggle between cost and capability. So I rebuilt one of our client pipelines, an intake system handling everything from ticket triage to contract clause analysis, on a single claude-opus-5 deployment and retired the three-model router. Here's what I learned, with real cost numbers.

How the Claude Opus 5 effort parameter works

Effort isn't a token cap the model ignores. Opus 5 respects effort levels strictly, especially at the low end. At low and medium it scopes work to exactly what was asked: fewer tool calls, more consolidated ones, less preamble. At xhigh it thinks and acts far more per request. The parameter goes inside output_config, and it defaults to high when unset. Set it explicitly on every route or you're paying high prices for low work.

import anthropic

client = anthropic.Anthropic()

EFFORT_BY_ROUTE = {
    "triage": "low",          # classify and route, sub-second matters
    "draft_reply": "medium",  # customer-facing text
    "account_review": "high", # multi-document reasoning
    "contract_analysis": "xhigh",  # the work clients pay us for
}

def run(route: str, messages: list) -> anthropic.types.Message:
    return client.messages.create(
        model="claude-opus-5",
        max_tokens=64000 if route == "contract_analysis" else 8000,
        output_config={"effort": EFFORT_BY_ROUTE[route]},
        messages=messages,
    )

Note the max_tokens bump on the xhigh route. Thinking is on by default on Opus 5 and counts against max_tokens, and at xhigh the model uses that room. Anthropic recommends starting at 64K for the top effort levels. You can run a route with thinking fully off if you want, with one restriction: thinking: {"type": "disabled"} is only accepted at effort high and below. The top two levels require thinking.

Claude Opus 5 cost per request, measured

Effort doesn't change Claude Opus 5 pricing per token. Everything bills at $5/$25 per million. What changes is how many tokens each request spends. On our eval set of 500 historical intake items, the same triage prompt cost this much per 1,000 requests at each level (output tokens, thinking included):

• low: ~180K output tokens, about $4.50
• medium: ~410K output tokens, about $10.25
• high (the default): ~890K output tokens, about $22.25
• xhigh: ~2.1M output tokens, about $52.50

The spread between low and the default is roughly 5x on this workload. That's the whole argument for setting effort explicitly. A triage route left on the default was quietly costing five times what it needed to, and classification accuracy at low was identical. Your numbers will differ, so sweep rather than trusting my table: run each route at three effort levels against your evals and pick per route.

Why one model beat our three-model router

The obvious objection first: Haiku is still $1/$5, so low-effort Opus 5 costs more per token than Haiku for bottom-tier work. True. Three things made the single-model setup win anyway for this pipeline.

Prompt cache coherence. Caches are model-scoped. Every time our old router escalated a conversation from Sonnet to Opus, the entire cached prefix (system prompt, tool definitions, conversation history) was reprocessed cold at full input price. On one model, an escalation is just a different output_config on the next request. Our cache hit rate went from 62% to 91% after consolidating, and cache reads bill at about a tenth of base input price. On long conversations that pays for the Haiku delta several times over.

One prompt, one eval suite. We maintained three variants of every system prompt because what steered Haiku over-triggered Opus. That matrix is gone.

Escalation without a router model. The best trick is also the dumbest: run at low, and when the model signals low confidence in its structured output, re-run the same request at xhigh. The retry reads the same cache. The model becomes its own router.

result = run_with_effort(messages, "low")
if result.parsed["confidence"] < 0.7:
    result = run_with_effort(messages, "xhigh")  # same cache, more depth

When Haiku still wins

If your bottom tier is genuinely trivial (sentiment tags, yes/no gates) and runs at millions of requests per day, Haiku's raw per-token price still wins. The cache argument can't save you there because those requests are short and stateless anyway. Latency-critical paths also care that Opus 5's comparative latency is "moderate" while Haiku's is "fastest"; low effort narrows that gap without closing it.

The mental model I've settled on: effort replaces model routing within a pipeline, where requests share context and caches. Picking the right model per pipeline is still your job.

Two setup notes

First, effort defaults to high on the Claude API and Claude Code specifically. Don't assume another surface behaves the same way. Second, if your stack used budget_tokens to control thinking spend, that parameter now returns a 400 on Opus 5. Effort is the replacement, and there's no clean formula mapping a token budget to a level, so measure.

One afternoon of migration bought us a deleted router service and a cost dashboard with a single line on it. The effort dial sounds like the most boring feature in the Claude Opus 5 launch. It changed our architecture more than anything else in it.