Claude: The Effort Dial, and When It Is Wasted

The effort parameter looks like a quality knob, and for a narrow class of task it is one. For everything else it buys latency and tokens and no accuracy, which would be fine if people could tell the difference. Mostly they cannot, because they never measured.

Start with the fact that settles most of these arguments: on Claude Fable 5.1 and Claude Opus 5, effort already defaults to high. Setting it to high is not a change. It is a no-op that feels like action.

Why this exists

Here is the sequence it prevents. Output quality disappoints. Somebody raises effort to high, sees no difference, and concludes the model is the limit. A more expensive model gets adopted, or a rebuild starts. Nobody establishes what was actually wrong, and the one change made was a setting already in effect.

The diagnostic question is narrow: is the bottleneck thinking, or information? Effort helps when the model already has what it needs and the remaining work is reasoning — a plan with dependencies, an ambiguous edge case, a problem where the first step determines the rest. It cannot help when the needed fact is not in the window, when the schema is ambiguous, or when the task is retrieval wearing a reasoning costume. More effort on a missing fact does not produce a right answer. It produces a more confident wrong one, which is worse, because confidence is what reviewers read.

How to use it

Log what you send. The parameter value goes in the log next to the model ID on every call. If it is not in the log, you do not know what you ran, and every later comparison is folklore.

Use the step you are skipping. xhigh sits between high and max. Teams jump from high to max, get the latency of max, and never find out the intermediate setting was enough.

Spend the dial before you spend the model. Anthropic’s own guidance is to start with Opus 5 and move to Fable 5.1 for demanding reasoning and long-horizon agentic work, or when your evals on Opus 5 at higher effort still fall short. Note the order — higher effort on the cheaper flagship comes first, and Opus 5 is half the input price of Fable 5.1.

Then settle it with an eval, not a vibe. Take thirty real items with known-good answers. Run them at two settings. Compare. If the difference is smaller than the disagreement between two people grading the same thirty items, the dial is not your problem. Building that set of thirty items is the work; the dial is a one-line change either way.

Effort pays on one-shot problems with a verifiable answer, and on long agentic runs where a wrong first step wastes everything after it. It is wasted on extraction, classification, reformatting and routing.

Where it goes wrong

Haiku 4.5 does not support the parameter. If you route across a mixed pool, the behavior you depend on is what the SDK does with an unsupported parameter — fail loudly, or drop it silently. Find out by testing, not by assuming: the silent version means you believe you raised effort on a model that never had the dial.

Latency compounds. Fable is slower than Opus, Opus than Sonnet, Sonnet than Haiku, and raising effort adds to whichever you chose. On a path where a person is waiting, the dial can be the wrong answer even when it improves the answer.

It is not a factuality control. More effort adds no knowledge, no documents, and no tools. If the failure is a missing fact, fix retrieval.

Do not map it onto another vendor’s dial. No published parity exists between Anthropic’s effort levels and anyone else’s reasoning settings, so an “equivalent setting” column in a comparison table is invented. If you benchmark across providers, say the settings are not comparable.

And do not raise it on a high-volume classifier, or in response to one complaint. That is how a permanent cost increase gets adopted to resolve a single anecdote.