ClaudeHowSupport Us

Effort & thinking cost estimator

Your baseline — the multipliers below scale from this.

Edit the multiplier for each level below — how much longer a model thinks at a given effort relative to “high” depends on your task and is not a published constant. These are starting points, not measured figures.

Cost across effort levels

LevelEst. costUse for
low$0.08Short, scoped tasks and latency-sensitive work that is not intelligence-sensitive: classification, extraction, simple lookups, subagents.
medium$0.10Cost-sensitive production workloads that still need real reasoning. On Sonnet 5, roughly comparable to Sonnet 4.6 at high.
high$0.11The default, and the recommended minimum for anything intelligence-sensitive. Omitting the parameter gives you this.
xhigh$0.16The hardest coding and agentic work. Added on Opus 4.7; it is the default in Claude Code.
max$0.22When correctness matters more than cost and latency is not a constraint.

Output tokens scale from your 1,500-token baseline by each level’s multiplier above — e.g. xhigh at 2× ≈ 2,400 tokens.

The lever most integrations never touch

Effort runs from a low setting through the maximum available, and of everything that moves both cost and output quality on a Claude request, it's the one most teams set once — usually to whatever the model defaults to — and never revisit. That's a mistake in both directions: a task that's actually simple keeps paying for reasoning depth it doesn't need at the default, and a task that's harder than it looks quietly underperforms at a low setting without producing any error that would tell you to raise it.

What higher effort actually buys, and costs

Raising effort makes the model think longer before it answers, which raises cost and latency together, in exchange for handling harder or more ambiguous tasks more reliably. That trade is worth it exactly when the task is intelligence-sensitive enough that a wrong or shallow answer costs more than the extra tokens spent getting a right one — and not worth it when the task was never going to benefit from more thinking in the first place, because the ceiling on quality was set by the prompt or the data, not by how long the model deliberated.

Why the top of the range isn't a universal upgrade

The highest effort levels are not simply "better, but slower and pricier." Diminishing returns on the hardest setting are documented behaviour, not a hypothetical risk, and overthinking a genuinely simple task at the top of the range is a real failure mode, not just wasted spend — a model given more room to deliberate than a task calls for can talk itself into a worse answer than a lower-effort pass would have given. This tool's cost curve is deliberately shown alongside that caveat rather than presented as a straightforward "spend more, get more" slope.

Where the parameter doesn't exist at all

Not every current model accepts an effort setting. The cheapest and fastest model in the current lineup rejects the parameter outright, and the highest effort level available elsewhere in the lineup is newer than several other models still in active use — meaning it simply isn't an option on them. This tool flags both cases directly against whichever model you select, rather than letting you configure a combination that would fail the moment you sent it as a real request.

Reading the curve against your task, not in the abstract

Enter your task size and select a model, and this tool plots the cost at every effort level that model supports, so you can see exactly how much each step up costs before committing to it. Pair it with the model picker if you haven't settled on a model yet — effort and model choice interact enough that picking one in isolation from the other tends to produce a worse combination than weighing them together.

Verified 2026-08-08 against ClaudeHow facts module (src/data/facts/) — see /about/#accuracy.