A Complete Guide to LLM Reasoning Effort

What Is Reasoning Effort?

Before producing a final answer, a large language model often performs an internal, draft-like reasoning process commonly known as thinking. One detail that is easy to overlook is that this internal reasoning also consumes tokens. It uses part of the same budget as the final response and may therefore affect both cost and latency.

Reasoning effort is the setting that controls how deeply the model works through this internal draft:

• Lower effort: The model gives straightforward answers with minimal internal reasoning, making it faster and more economical.
• Higher effort: The model reasons through more steps, considers more edge cases, and performs additional self-checks before reaching a conclusion.

A workplace analogy makes this easy to understand. If you ask a colleague which package contains a particular annotation, they can answer immediately. If you ask them to investigate an intermittent production bug, they may inspect logs, compare the code against their assumptions, and eliminate possible causes one by one. Reasoning effort tells the model which working mode to use for the task at hand.

Reasoning Effort vs. Switching to a Different Model

This is one of the most commonly misunderstood distinctions:

Operation	What changes	Analogy
Switch to a more capable model	The model’s capability ceiling	Asking a smarter person to do the work
Increase reasoning effort	How much reasoning compute the same model applies	Asking the same person to work more carefully

In other words, switching models addresses a capability problem, while changing effort addresses a depth-of-reasoning problem. If the model lacks the necessary knowledge or capabilities, increasing effort will not solve the issue. If the answer is incorrect because the reasoning was not sufficiently thorough, increasing effort may be more cost-effective than switching models.

Default Strategy: Do Not Adjust It Most of the Time

For many current AI coding tools, the default setting for mid- and high-end models is typically medium. Official documentation generally positions this level as suitable for well-scoped, everyday development work, such as implementing a new feature.

It is also worth noting that vendors commonly report that newer-generation models at the medium setting can match the coding performance of previous-generation models at higher settings. As models improve, the cost-effectiveness of the default level continues to increase. Automatically choosing a higher setting may simply mean paying for unnecessary reasoning.

The first practical principle is therefore:

Start with the default setting and judge it by the results. Do not assume that a higher setting is always better.

When Should You Adjust Reasoning Effort?

There are only two main reasons to change the setting:

1. The model is too slow or consumes too many tokens → Lower the effort.
2. The model repeatedly misses important details in complex tasks → Increase the effort.

A Quick Reference for the Five Levels

The “Best suited for” descriptions below reflect the general positioning in official documentation. The examples focus on backend development tasks.

Level	Best suited for	Typical examples	Trade-offs
low	Fast back-and-forth work where you review every result	Renaming a variable or asking how to use an API	Fastest and most economical, but more likely to miss details in complex tasks
medium	Well-scoped everyday development; usually the default	Adding a pagination endpoint or writing a set of unit tests	The best balance between speed and quality
high	Tasks requiring verification and involving many edge cases	Fixing a bug in poorly documented legacy code	Slower, with noticeably higher token usage
xhigh	Planning-oriented tasks that require deeper reasoning	Producing a plan before a cross-module refactor	Significantly slower and more expensive
max	Difficult problems where you want the model to work with minimal intervention	Security reviews or diagnosing highly unusual issues	Slowest and most expensive; it may overthink the problem, so test it on a small task first

Additional Guidance for Each Level

• The value of low lies in interaction density. If your workflow is “give an instruction, review the result, and immediately correct it,” the cumulative effect of response latency may matter more than a small loss in per-response quality. In that situation, low is often the most rational choice.
• Medium covers most everyday work. When requirements are clear and the context is not especially long, medium usually provides sufficient reasoning depth. Additional thinking may only slow down feedback.
• High is appropriate when errors are costly. For legacy code changes or tasks involving transaction boundaries and concurrency logic, additional self-verification can reduce outputs that appear correct but overlook important edge cases.
• xhigh is better for producing a plan than for writing routine code. Refactoring plans and architecture decisions can deliver long-term value from a single careful analysis, making the additional reasoning budget worthwhile.
• Max requires caution because of overthinking. With the reasoning budget fully increased, the model may get stuck in unnecessary self-questioning or drift away from the original problem. Official guidance also recommends validating the effect on small tasks before using the highest setting more broadly.

Practical Recommendations and Common Misconceptions

A Recommended Adjustment Strategy

The basic recommendation is simple:

Use the default medium setting in normal work. Increase the effort only for the specific task that needs it instead of running an entire session at xhigh.

In practice:

1. Adjust effort at the task level, not the session level. A single development session may include questions, small edits, and large design tasks. Using a high setting globally is one of the biggest sources of wasted reasoning.
2. Use token consumption as feedback. If thinking tokens account for an increasingly large share of usage without a corresponding improvement in output quality, the setting is probably too high.
3. Increase effort one level at a time. If medium is insufficient, try high. If high still does not work, consider xhigh or max. Gradual escalation helps identify the point where the additional cost stops producing meaningful benefits.

Common Misconceptions

• Misconception 1: A higher setting always produces better code. Reasoning effort changes the depth of reasoning, not the model’s knowledge boundary. If the model does not know how to use a particular library, switching to max will not make it know the answer.
• Misconception 2: Reasoning effort can replace a clear prompt. When the task description is ambiguous, deeper reasoning may simply lead the model further in the wrong direction. Clarify the requirements before increasing the effort.
• Misconception 3: Low effort is guaranteed to be inaccurate. For mechanical tasks with clear instructions, the accuracy of a low-effort response may be nearly identical to that of a high-effort response. The tokens and time saved are then pure efficiency gains.

Conclusion

Reasoning effort is an attention-budget control. It does not change the model’s underlying capabilities; it changes how much reasoning compute the model applies to the current task.

To balance speed, cost, and quality, understand the purpose of each of the five levels and adjust the setting dynamically at the task level. Keep three principles in mind:

Use medium by default, increase effort only when needed, and move up one level at a time.