Reasoning Effort: How to Set It Without Guessing

Most teams leave reasoning effort at the default and adjust it by feel when something goes wrong and both habits waste tokens. This is the procedure we use instead: what the control actually does, what each level is for, how to calibrate it against your own work, and how to tell whether a failure is an effort problem at all. Every section ends with the choice we made and why.

Why your instinct is the wrong input

Almost everyone sets reasoning effort the same way: high when the task looks hard, low when it looks easy. The rule has one fatal property. It uses your sense of difficulty as the input, and your sense of difficulty is not measuring what you think it is measuring.

Two published results measure that gap directly. In a planning study, GPT-4 solved 210 of 600 Blocksworld instances under zero-shot natural language prompting. The same 600 instances, re-expressed with the action and object names obfuscated, a cosmetic change that leaves a classical planner's performance identical, yielded one solution. In Apple's GSM-Symbolic work, changing only the numbers in a grade-school math problem lowered accuracy, and inserting one clause that reads as relevant while contributing nothing to the answer produced drops across every model tested, up to 65 percent in the worst case.

None of those edits makes the problem harder for a person, which is the whole point. Human difficulty and model difficulty are different quantities, and the second one is invisible to you when you are looking at a ticket. Two caveats worth stating, in an article about not trusting unexamined numbers: the human baseline in the planning study was collected on the plain version only, so it shows the underlying task is easy for people rather than that people are immune to the renaming, and the size of the model collapse varies with the prompting strategy.

There is a weaker result about self-assessment in general that is worth knowing and worth not overreading. METR restates its own randomized trial in which experienced developers, working on their own repositories, overestimated AI's effect on their time by about 40 percentage points. That measures estimates of productivity, not estimates of model difficulty, so it belongs here as a caution about confident introspection rather than as evidence about reasoning effort levels.

So the instinct fails in both directions. It overspends on work that looks substantial and is trivially easy for the model, and it underspends on work that looks routine and happens to sit on a failure mode you cannot see. The second is the expensive one, because overspending shows up on an invoice and underspending shows up in a defect nobody attributes to a setting.

We removed the judgment from the moment of use. Nobody on a delivery team picks a reasoning effort level while a ticket is open, because that is the decision the evidence says people are worst at. The reasoning effort level is configuration, set per class of work and committed alongside the code.

How should I decide the reasoning effort level for a task?

Not per task. Group your work into classes, set a level per class from a measured sweep, and change it only when a classified failure justifies it. Deciding per request means deciding on perceived difficulty, which does not predict how hard the work is for the model.

What the reasoning effort control actually does

The most expensive misconception about reasoning effort is that the control is a budget and it is not. Reasoning effort authorizes deliberation rather than consuming it, and the difference decides whether your cost model works.

Anthropic states that effort is a behavioral signal rather than a strict token budget, and that at lower levels the model will still deliberate on genuinely difficult problems, simply less than it would higher up. Google documents its lowest thinking level as matching a no-thinking setting for most queries, while warning in the same breath that it does not guarantee thinking is off. OpenAI advises treating the parameter as a tuning knob rather than the primary way to recover quality.

The practical consequence is that a high reasoning effort level on a simple request may consume roughly the same tokens as a low one would, because the model declines the permission it was given. Token projections built on the assumption that level equals consumption are wrong in both directions, and so are the savings people expect from turning it down across the board.

If you need a hard ceiling on token consumption, the control for that is the maximum output tokens, not the reasoning effort level. They are different instruments and only one of them is a limit.

We stopped forecasting consumption from the level. Tokens per task are measured per workload class in the same sweep that sets the level, because the relationship between the two is empirical and not arithmetic.

The levels, and what each one is for

Three providers expose reasoning effort under three parameter names, with level names that do not translate between them. The table below is the starting point, not the answer, and the vendor guidance behind it is worth reading in full before you commit to a default.

Provider	Parameter	Levels	Default
Anthropic	effort	low, medium, high, xhigh, max, subject to model support	high
OpenAI	reasoning.effort	none, minimal, low, medium, high, xhigh, max, subject to model support	Model dependent
Google	thinking_level	minimal, low, medium, high, subject to model support	Model dependent

Taking Anthropic's scale as the worked example: low is for short, scoped, latency-sensitive work that is not intelligence-sensitive, such as classification and lookups. Medium is the drop-in for high-volume work that can trade some capability. High is the default and usually the best balance of quality against token spend. Xhigh is the recommended starting point for coding and agentic work with repeated tool calls and search, at meaningfully higher token usage. Max is reserved for genuinely frontier problems, and Anthropic's own guidance for its Opus 4.7 and 4.8 models warns that on most workloads it adds significant token usage for small gains and can produce overthinking on structured output.

None of these levels is universal: xhigh and max are gated per model, some models that accept max do not accept xhigh, and on Google not every current model accepts minimal. Check the level list for the exact model you are calling before you commit a value to configuration.

The failure at the other end is documented too. On moderately complex tasks run at low, there is a recognized risk of under-thinking, and the recommended correction is to raise the reasoning effort level rather than to compensate through prompt wording.

We do not run any reasoning effort at max in delivery. It is a diagnostic setting we use to establish whether a quality ceiling is capability or effort, and then we step back down, because paying frontier prices on a workload that does not need them is the most avoidable line in a token budget.

Step 1: set reasoning effort per class of work

Group the work first, then assign a reasoning effort level to the group. Anthropic's own guidance is to treat the level as a general preference rather than a task-by-task decision, which is the single change that removes most of the waste.

A reasoning effort class is defined by three properties, and perceived difficulty is not one of them: how much latency the user will tolerate, what a call costs at your expected volume, and what an undetected error costs. Those three are knowable in advance and stable over months, which is exactly what a configuration value needs.

Class of work	Latency tolerance	Cost of an undetected error	Sensible starting level
Interactive assistance in a session	Low	Low, the engineer sees the output	medium
Coding against a written specification	Moderate	Moderate	high
Agentic work with repeated tool calls	High	Moderate	xhigh
Code and security review	High	High, catching the error is the point	xhigh
Batch classification and extraction	Low	Low per item, material in aggregate	low

The third column is the one that moves most between industries, and it is the one that should set your floor. In regulated delivery, the kind of work covered in the 2026 healthcare software and defense software reviews, an undetected error outweighs latency and volume combined, so the reasoning effort floor is set from that column alone: those classes start high and earn the right to come down, rather than starting low and earning the right to go up. Financial-services cybersecurity is the same case sharpened, because in a review class catching the error is the entire deliverable.

The opposite end deserves the same discipline. High-volume extraction, the pipeline shape typical of AI development for fintech, is cheap to get wrong on any single item and expensive to get wrong for a month, so its reasoning effort level is set from aggregate cost rather than from how any one task looks.

Where you attach the reasoning effort value matters as much as the value itself. A session-level setting follows whoever launched the session; a setting attached to the kind of work follows the work. In Claude Code that means skill and subagent frontmatter rather than the interactive picker, so a review agent and an exploratory agent do not inherit whatever the last person selected.

Every class we run has its level committed to the repository and reviewed like any other configuration change. The interactive controls, the slash command and the environment variable, are for investigation only. They are never the record.

Step 2: calibrate with a sweep instead of guessing

Once the reasoning effort decision is per class it becomes measurable, and measuring it takes an afternoon. Take twenty to fifty representative items with known-good answers, run all of them at every reasoning effort level, and record pass rate, output tokens and latency. You are looking for the point after which accuracy stops improving and cost keeps rising.

for level in low medium high xhigh; do
  for item in evals/<class>/*.json; do
    run --effort "$level" "$item" >> "results/$level.jsonl"
  done
done
# compare per level: pass rate, output tokens, p95 latency, cost per item

Three requirements decide whether the result is worth anything: the items come from real traffic rather than being written for the test, every case in that class that failed in production is included and scoring runs without a human, because a calibration that needs a reviewer will not be repeated when it needs to be.

Real traffic carries an obligation, where the data cannot leave a jurisdiction, the sweep that sets the reasoning effort level runs inside the same boundary as the workload it calibrates, which on EU sovereign cloud engagements means the evaluation set is built and scored in region rather than shipped to whichever machine is convenient.

The main providers of AI offer the following guidance: Anthropic tells teams to run a fresh sweep on their evaluations rather than reuse settings from an earlier model, OpenAI qualifies its highest levels by saying to use them only where evaluations show a benefit that justifies the latency and cost, and Claude Code's guidance on max is to test before adopting it broadly.

The sweep is a deliverable rather than an optimization we get to when there is time. A new workload class does not reach client traffic with an uncalibrated level, and the result is committed next to the configuration it justifies so the next person can see why the number is what it is.

How many items do I need for a useful sweep?

Twenty to fifty per class is enough to see a difference worth acting on. Composition matters more than count: real traffic, every known production failure in that class, and a scoring function that needs no human in the loop.

Step 3: diagnose the failure before turning the dial

Most bad output is not a reasoning effort problem, and raising the level on a problem it cannot fix is how token budgets disappear. Let's clarify the order of operations plainly: when the model gets something wrong, the first move is to examine the context you supplied, not to adjust a parameter. The question that sorts almost every case is whether it failed to try hard enough or failed to know enough.

What you see	Actual cause	What to change
Output ignores information you assumed it had	Context, tools or scope	Fix the prompt, the tools, the project instructions
Reasoning is coherent, the conclusion is wrong	Capability	Change the model. The level is not the variable
Skipped a file, never ran the tests, stopped halfway	Reasoning effort	Raise the level for that class
Correct, but slow and token-heavy on routine work	Over-allocation	Lower the level and re-run the sweep
Long deliberation on a structured output task	Overthinking	Lower the level, keep the schema strict

The second row is the one teams get wrong most often. A model that reasons at length and still concludes wrongly does not need more of the same reasoning. Raising the level there buys a longer wrong answer at a higher price, and it delays the model change that would actually fix it.

A change to a reasoning effort level requires a classified failure as its justification, named against the table above. An unclassified failure is not grounds for a change, which sounds bureaucratic and takes about ten seconds in practice.

Step 4: read the signals that beat intuition

When a class is new and you have no calibration yet, judge the structure of the work rather than its subject. Three properties predict trouble, and none of them registers as difficulty to a person reading the task.

The first is plausible but irrelevant material in the input. Apple's GSM-Symbolic work found that adding a single clause that looks relevant and contributes nothing produced drops across every state-of-the-art model tested, up to 65 percent in the worst case. A human reader discards such a clause without noticing. Any class whose inputs carry that property needs a higher starting level, and a cleaning step upstream if the input is yours to clean.

The second is unfamiliar naming. The collapse from 210 valid solutions to one came from renaming alone. Generated identifiers, internal jargon and vocabulary absent from training data all put a task in that territory while looking exactly as hard as before.

The third is a requirement for exact symbolic operation, and it is the case where raising reasoning effort is the wrong purchase entirely. An ACL 2026 benchmark ran nine models, reasoning ones included, across ten character-level tasks and located the failure in tokenization rather than in reasoning: the processing granularity does not match the precision the task needs.

Effort does move the number, for example DeepSeek-R1 reads keystroke sequences at 94 percent where its non-reasoning sibling scores zero. But where the paper sweeps the thinking budget, accuracy traces an inverted U that peaks near 2,048 tokens and declines after it, because the surplus deliberation goes into re-litigating an answer that was already right. You buy the result, then you buy the doubt. There is no level that settles it but a three-line function does.

Counting, arithmetic, date computation and schema validation go to a tool by default, and deliberation is reserved for the part of the task that needs judgment. Paying a deliberation premium in tokens for work a function performs deterministically is the least defensible consumption in this whole area.

Step 5: re-run the sweep when the model changes

Reasoning effort level names are not portable across models, even within one provider. The scale is calibrated per model, so the same name can correspond to a different amount of deliberation after an upgrade, and provider defaults differ across a single family.

This produces a specific and quiet failure: a configuration carried forward through an upgrade, delivering a cost and quality profile that nobody measured and nobody intended. It does not announce itself, because nothing errors. The bill moves and the quality moves, and the change log says the model was updated.

The same applies to controls that disappear. For example, Anthropic's fixed thinking budget, configured as a token count, is deprecated on the 4.6 models and rejected outright with an error by 4.7 and later. Integrations still setting it are configuring a control that no longer exists.

A model version change voids the calibration. The sweep is re-run for every affected class before the new model reaches client traffic, and that work is scheduled as part of the upgrade rather than after it.

Five reasoning effort mistakes that waste tokens

These are the ones we see most, in rough order of how many tokens they burn before anyone notices.

• Leaving every workload at the vendor default: The default is a reasonable guess about an average customer, and it is high on several models. On batch classification that is a large recurring overpayment for capability the task never uses.
• Changing reasoning effort inside a conversation: It invalidates prompt caching, so you pay twice: once for the extra deliberation, once for the cache you discarded. Vary across workloads, never within a session that depends on cache hits.
• Prompting instead of configuring: Phrases such as think hard are ordinary text in an API call and their effect is wording-sensitive rather than calibrated. Claude Code is a documented exception, recognizing the keyword ultrathink for a single turn and adding an in-context instruction, though the effort level sent to the API is unchanged. Think, think hard and think more pass through as plain prompt text.
• Ignoring the output ceiling: Reasoning tokens are billed even when the response hits the cap before producing anything visible. OpenAI suggests reserving at least twenty-five thousand tokens for reasoning and output when you start, which is cheaper than discovering the failure mode in production.
• Sending two conflicting controls: On Google, supplying the legacy numeric budget together with the thinking level returns an error rather than picking one. Migrations that leave both in place fail at the API rather than degrading quietly.

All five are checked at configuration review rather than trusted to memory, because every one of them is invisible in the output and visible only in a token bill or an incident.

Our take, in one line

Reasoning effort is a property of the workload, measured once against an evaluation set, and not a judgment to be made while a ticket is open.

Paying for AI capability you have never measured?

Talk to our AI engineering team →

About the author

This article was written by Mohamed Boukrim, software engineer at Lasting Dynamics, an EU-based custom software development company. We run agent-assisted delivery on fixed-scope engagements, which is why tokens per task and the quality floor are numbers we have to defend rather than estimate.

FAQs