Anthropic’s effort parameter changes a familiar question—“which model should handle this?”—into a second decision: “how hard should this model work?” Supported Claude models can trade response thoroughness for speed and token efficiency without switching model IDs. For agent builders, the important detail is that effort influences not only prose but also thinking and tool calls.
That makes effort a workflow control rather than a cosmetic answer-length setting. A low-effort agent may make fewer tool calls and proceed directly to action. A high- or max-effort agent may inspect more evidence, explain a plan, call additional tools, and validate more thoroughly. Those behaviors can improve difficult work, but they also affect latency and cost.
The five documented levels
Anthropic’s current platform documentation lists five levels:
| Effort | Intended profile | Typical use |
|---|---|---|
low |
Most token-efficient | Simple, high-volume, latency-sensitive work or narrow subagents |
medium |
Balanced savings | Routine agent tasks with measurable acceptance criteria |
high |
High capability and the default | Complex reasoning, coding, and general agent work |
xhigh |
Extended capability | Long-horizon or especially demanding agentic tasks |
max |
Maximum capability without an effort constraint | Rare frontier tasks where incremental quality is worth substantial cost |
Availability varies by model. Anthropic documents all five for Fable 5 and Sonnet 5, while some older supported models have a smaller set. Applications should consult the current model documentation instead of assuming a level exists everywhere.
Omitting the parameter is equivalent to high on the documented API behavior. Setting effort explicitly is still helpful because it makes a production policy visible and prevents a default from being mistaken for an intentional evaluation result.
Effort is not a hard budget
Anthropic calls effort a behavioral signal. It encourages Claude to be more or less eager to spend tokens, but it does not promise an exact token count. A difficult request at low effort can still trigger thinking; an easy task at high effort may finish quickly.
Hard limits belong elsewhere. max_tokens limits total output capacity, including thinking where applicable. An agent harness should also have a task-level budget covering all turns, retries, subagents, and tools. Wall-clock deadlines and tool quotas are separate again.
This separation avoids a common error: setting low effort and assuming cost is now bounded. A loop can still make many model calls, and an inexpensive model decision can trigger an expensive external action. Conversely, max effort on one carefully scoped review may cost less than several failed medium-effort attempts.
Adaptive thinking differs across Claude models
Fable 5 and Mythos 5 use adaptive thinking that is always on, according to Anthropic’s documentation. Developers control depth with effort; attempts to disable thinking are rejected. Raw chain-of-thought is not returned. Applications can work with the supported thinking summaries or omitted blocks while preserving required blocks in multi-turn exchanges.
Sonnet 5 also uses adaptive thinking by default, with effort as the recommended control. Anthropic’s model guidance should be checked during migration because supported thinking settings and sampling parameters can change across generations.
The practical point is that developers no longer need to guess a fixed “thinking token” allocation for every request. The model decides when and how much reasoning is useful, while effort changes its operating posture. This simplifies configuration, but it also makes empirical evaluation essential: the same effort level can behave differently on extraction, coding, research, and tool-use tasks.
Tool behavior is part of the cost
Anthropic says lower effort tends to combine operations, make fewer tool calls, skip lengthy preambles, and return terse confirmations. Higher effort can lead to more calls, planning detail, summaries, and comments.
More calls are not automatically better. An agent might gather redundant sources, repeatedly inspect the same file, or poll a slow job too often. Fewer calls are not automatically efficient either; skipping a validation step can force an expensive rerun.
Evaluate the whole trajectory:
- completion and acceptance-test pass rate;
- model input, cache, thinking, and output tokens;
- number and type of tool calls;
- external tool fees;
- elapsed time and human review time;
- duplicate or unnecessary operations;
- severity of errors that escape validation.
This is especially important with subagents. Giving every subagent xhigh or max effort can multiply cost without improving synthesis. A strong default is low for bounded retrieval or classification, medium for routine execution, high for planning and integration, and an evidence-based escalation for difficult failures.
Dynamic effort is better than one global setting
A production router can choose effort from task properties. Start with objective signals: data sensitivity, reversibility, ambiguity, number of dependencies, expected duration, and cost of a wrong answer.
For example:
- Use low for schema validation, filename normalization, and status classification.
- Use medium for a standard tool workflow with explicit parameters and tests.
- Use high for planning across several tools or resolving conflicting requirements.
- Escalate to xhigh when a long-running task repeatedly fails a meaningful validation.
- Reserve max for frontier problems whose value exceeds the additional cost and latency.
Do not escalate merely because a service returned a transient error. More reasoning will not fix a 429 rate limit. The agent should back off according to the service’s retry guidance. Similarly, a malformed input should be corrected, not pondered at max effort.
Routing rules should be reversible and observable. Log the selected level, why the router chose it, the task outcome, and any later escalation. Review samples where low effort failed and where max effort added no value. This creates a feedback loop for adjusting thresholds instead of turning a launch-day intuition into permanent infrastructure. It also lets finance and engineering discuss cost using completed tasks rather than isolated token prices.
Pricing makes workflow-level evaluation necessary
At launch, Sonnet 5 carried an introductory price and Fable 5 was listed at $10 per million input tokens and $50 per million output tokens. Prices, plan access, and promotional periods can change, so calculators should use current official data.
Effort affects the number of tokens the model chooses to spend, but token rate remains tied to the model. Lowering Fable’s effort does not turn it into Sonnet’s price tier. Sometimes Sonnet at high will outperform Fable at low on cost while meeting the same acceptance criteria; sometimes Fable’s stronger capability will finish a complex task in fewer attempts.
Prompt caching can reduce repeated-input cost, but only for stable reusable prefixes. Constantly changing project histories should be summarized or retrieved selectively. Long-running agent tests should report cached and uncached input separately.
Quality safeguards at lower effort
When lowering effort, make the task narrower and the output more verifiable. Use schemas, checklists, explicit stop conditions, and deterministic validators. A low-effort subagent that returns three required fields can be reliable; a low-effort agent asked to “manage the entire launch” is under-specified.
At higher effort, control overreach. Require the agent to ask before expanding scope, cap tool calls, and separate proposed actions from approved actions. “Think more” should not mean “do more without permission.”
Human review should be proportional to impact, not effort level. Max reasoning does not authorize publication, financial commitments, sensitive file uploads, or identity-related media edits.
Applying effort to Medux media orchestration
Suppose Claude is coordinating an approved Medux workflow through a separately configured MCP connection. Effort can improve how Claude interprets the request and validates parameters, but it does not change Medux’s underlying processing model. No native Fable or Sonnet integration is implied.
A cost-aware sequence could use medium effort to inspect clip metadata and plan an ordinary merge, low effort to poll the returned task status, and high effort only if duration or ordering checks fail. The Claude MCP video merge tutorial shows the asynchronous lifecycle that makes this separation visible.
Photo restoration offers a different risk profile. Claude may use high effort to compare the request with the source image and define conservative expectations, while Medux performs the actual restoration. The old photo restoration tutorial illustrates the upload, task, and result flow.
In both cases, an effort escalation must reuse the existing task ID. It should not submit the same media job again merely because Claude is now reasoning more deeply. Store the operation state outside the conversation, count model and media charges separately, and let higher effort improve decisions—not multiply side effects.
Record the selected effort beside each orchestration decision so reviewers can distinguish a model-planning change from a media-processing change when quality, latency, or cost shifts.