Reasoning effort: what changes in model comparisons
Reasoning level changes the results and costs of the same AI model. Why a comparison that omits it is incomplete.
Reading time: 9 min
The reasoning effort is the setting that decides how much a model thinks before responding. It has become one of the most important variables when comparing models, and it is also the one that is omitted most often.
The reason is simple: the same model, with different effort, is in fact two different tools for cost, latency and quality. Comparing two models without telling what effort they were measured at is like comparing two cars without telling which route.
In summary
- Effort regulates how much the model reasons before answering.
- The same model at different effort gives Different results and costs.
- The Reasoning tokens are paid for as output.
- Raising it on simple tasks is spent without benefit.
- A comparison that does not declare the effect is not reproducible.
- The right level is found for testing, starting from the bottom.
How it looks on current models
The three main vendors display control in different ways. As of the date of this article, from the official documentation:
| Vendor | How it presents itself |
|---|---|
| Anthropic | Adaptive Reasoning; Default Effort high on Fable 5.1, Opus 5 and Sonnet 5 |
| OpenAI | Levels declared by none to max on GPT-5.6; by low to max on GPT-6 Astra |
| Reasoning tokens included in the output price |
Sources: platform.claude.com, developers.openai.com, ai.google.dev — consulted 19 August 2026.
The difference in setting between vendors is already a reason why cross comparisons are delicate: there is no common scale, so ‘high effort’ on one model does not equal ‘high effort’ on another.
Why it counts in benchmarks
In the announcement of Claude Opus 5 on 24 July 2026, Anthropic does not publish a single score per benchmark but shows how performance varies with effort, explicitly presenting it as a way to optimise the balance between intelligence and token consumption.
It is a correct way of presenting the data and makes the problem obvious: a unique number hides a curve. Two articles can quote the same model on the same benchmark with different numbers, and be both correct.
The Cost Effect
It is direct and often underestimated. More reasoning means more tokens generated, and reasoning tokens fall within the turnover output.
- On simple tasks, a high effort produces expense without improving the result
- On difficult tasks, a low effort produces answers to be corrected — which cost anyway
- The same setting can be right for one type of request and wrong for another
- On high volumes, the effort difference is the entry that moves the bill the most
The complete economic reasoning is in cost per task or price per token.
How to choose the level
- Start at the level lower available for your case.
- Try out ten real tasks, including the most difficult.
- If quality is enough, stop there.
- If that's not enough, go up one level and try the same ten again.
- It checks how much consumption has grown between levels.
Many companies find that on ordinary cases an intermediate level is sufficient, and that it is better to reserve the high one to automatically recognized exceptions. It is the same logic as the mixed strategy described in Mixed Model Strategy: not a unique setting, but the lowest one that solves.
Effort and latency
There is a third effect in addition to quality and cost: response time. A high effort means longer wait, and in some contexts this counts more than quality.
Latency counts
- Assistants who respond to customers in real time
- Voice systems, where waiting is heard
- Interactive tools used while working
Latency matters little
- Nightly processing of documents
- Periodic analyses
- Queue jobs that no one waits for
In the right column you can raise the effort freely. In the left, a faster model at low effort often serves better than a slow and perfect one.
Practical examples
Extracting data from recurring invoices. Repetitive task with known structure. Low effort is sufficient, and on high volumes the cost difference from a high setting is consistent.
Analysis of a complex contract. Here the high effort pays off: an interpretation error costs more than any token savings.
Voice assistant. Latency is the dominant constraint. A low effort is convenient, and switch to a person when the request comes out of the expected cases.
Mistakes to Avoid
- Setting maximum effort for safety. Expenditure without benefit on simple tasks.
- Comparing models to different efforts. The comparison is invalid.
- Ignoring reasoning tokens in the budget. It's turnover output.
- Using a single level for all tasks. You pay too much or you're too wrong.
- Neglecting latency. In some cases it matters more than quality.
- Not rechecking after an update. Defaults can change.
How to apply it in the company
If you already have a system in production, check what level it is running at: in many cases it is the default value, chosen by no one. Try to lower it to ten real cases and see if the quality holds. If it holds, you've reduced your spending without touching anything else.
If you're considering a project, ask the supplier what effort they predicted and why. It's a question that distinguishes who reasoned about your case from who left the factory settings.
The overall picture is in how to read AI benchmarks.
What Really Happens When You Raise Effort
The model no longer becomes capable: more space is taken to arrive at the answer. It produces intermediate reasoning, considers more roads, checks more before concluding.
This has three immediate consequences, and all three must be considered together.
- The Salt Quality on tasks that require multiple steps
- The Salt Cost, because reasoning tokens are paid
- The salt latency, often very sensitively
- On simple tasks the gain is null or negative
The last point is what surprises. On a trivial task — classifying a message, extracting a date — raising the effort doesn't improve anything and sometimes gets worse, because the model processes a simple answer more than necessary and ends up complicating it.
Why it ruins comparisons
This is why this parameter appears among the causes of unreliable comparisons, along with the scaffold described in because vendor benchmarks are not comparable.
The same model, on the same test, with different effort produces different results — and sometimes the difference is larger than that between two distinct models. A comparison that does not state the level used for each candidate is not interpretable.
Then there's the economic side. A number obtained at the highest level of reasoning was also produced at the highest cost. If the ad reports the score without the corresponding cost, it is showing half the information.
| Level | When it makes sense | Typical effect |
|---|---|---|
| Low or absent | Classification, extraction | Fast and Cheap |
| Medium | Synthesis, articulated responses | Balanced |
| High | Multi-step analysis, code | Slower, more expensive |
| Maximum | Difficult problems, little volume | Much more expensive and slow |
The official documentation of the main providers describes this parameter explicitly: OpenAI’s documentation describes levels from none to the maximum, while Anthropic’s indicates a high default level for the leading models in the Claude family. These details were verified on 19 August 2026 on the respective documentation pages.
How to set it in production
The right setting is rarely one. In well-designed systems the effort is a variable of the task, not a global configuration.
A typical stream uses a low level for initial classification —which is fast, cheap, and sufficient —and only raises the level for cases that the first phase has marked as complex or uncertain. You get the quality where you need it by paying it only where you need it, and it's the same principle as mixed model strategy.
A mistake that costs dear
The most frequent is setting the maximum level anywhere "for safety". It seems prudent and it is not: it multiplies the cost on all traffic, including the thousands of trivial requests that do not benefit from it, and it worsens latency just where users notice it the most.
The second mistake is the opposite: keep the minimum level to save even on tasks that require reasoning. The result is hasty responses that then have to be corrected by hand, and the correction time costs more than the savings obtained.
The sensible road lies in the middle and is measured: take twenty representative cases, try them at two different levels, compare quality, cost and time. In an hour you have the answer for your case, which no article can give you in the abstract.
Practical examples
Study that ranks incoming emails. Pure recognition task: the lowest level of reasoning is the correct choice. Raising it doesn't improve anything, it costs more and slows down responses. It is the typical example where the default setting should be lowered, not raised.
Company that analyzes articulated contractual documents. Here the task requires connecting distant clauses and concatenating deductions. Raising the level significantly improves the results, and since the documents are a few tens per month the additional cost is absorbable.
Agent running the passive cycle. Mixed task: most invoices are ordinary and do not require processing, a minority has anomalies. The correct configuration uses a low level for the first step and raises it only on cases that the first one reports as doubts.
How to apply it in the company
The operating principle is that effort is a variable of the task, not a global configuration. In well-designed systems it changes from one call to another.
The typical flow uses a low level for initial classification —fast, cheap, and sufficient —and only raises the level for cases marked as complex. You get the quality where you need it by paying it only where you need it, and it's the same principle as Mixed Model Strategy applied to parameters instead of models.
To find the right setting you don't need theory: take twenty representative cases, try them at two different levels and compare quality, cost and time. In one hour you have the answer for your case.
An important note for those who read comparisons: a score obtained at the highest level was also produced at the highest cost. If the ad reports the score without the corresponding cost, it is showing half the information — as discussed in because vendor benchmarks are not comparable.
If you want to go from testing with ChatGPT to an AI system integrated into business processes, Giallo Studio custom designed agents and automations.
Conclusion
Reasoning effort is the variable that makes the same model two different tools. It changes quality, cost and response time, and for this reason it must be stated in every serious comparison.
For a company the rule is simple: the right level is the lowest that solves your task. All that is above is spending that does not buy anything.
If you want to understand what processes in your company can be automated with AI, Giallo Studio can help you turn the problem into a real workflow.
Giallo Studio guides: methodology and sources
How we apply it in the company
Related resources
FAQ
What is reasoning effort?
It is a setting that regulates how much the model reasons before responding. Higher levels produce more reasoning tokens and generally better results on difficult tasks, at greater cost and latency. It is configurable on the current models of all three major vendors.
What levels exist?
They vary by vendor. On current Claude models the reasoning is adaptive, with default effort set to high for Fable 5.1, Opus 5 and Sonnet 5. On OpenAI models GPT-5.6 the declared levels range from none to max, while GPT-6 Astra starts from low. Always check the official documentation of the model you use.
Is a higher effort always better?
No. On simple tasks it produces the same result by consuming more, so it worsens the cost-benefit ratio. It makes sense to raise it where the task really requires reasoning and where a mistake costs money.
Why is it important in comparison between models?
Because the same model achieves different scores at different effort levels. A comparison that does not state the level used is not reproducible: it could compare a model at maximum effort with one at medium effort.
Are reasoning tokens paid for?
Yes, they are included in billed output. Google states this explicitly in its price list, where the output price includes thinking tokens. This is why effort has the greatest impact on cost when using the same model.
How do you choose the right level?
Empirically: Start at the lowest level that solves the task and only raise if quality is not enough. Many companies find that on their ordinary cases an intermediate level is sufficient, and reserve the high one for exceptions.