How to Choose Reasoning Effort Levels: The Practical Impact of Thinking Depth on Code Generation

1. Thinking Effort Levels: The “Throttle” of Reasoning Models

Current mainstream reasoning models generate an internal thinking process (chain of thought) before producing a final answer, used to decompose problems, weigh alternatives, and self-check for errors. This thinking also consumes tokens and time, so reasoning services typically abstract it into several “levels” for callers to choose from, with common tiers including: non-thinking, Low, High, and Max. Whether you are running a self-hosted inference framework or using a cloud platform’s large-model inference service such as Baidu AI Cloud, these capabilities are generally exposed to developers as a thinking toggle or an intensity level.

It is important to emphasize that the differences between levels are not simply “thinking a bit longer,” but systematic changes in thinking budget and thinking strategy: lower levels tend to compress or even skip deliberation, higher levels adaptively allocate thinking based on problem complexity, and the highest level may run multiple rounds of comparing and overturning solutions. Understanding this difference is a prerequisite for controlling both cost and quality.

2. Test Design: A Representative Programming Task

To observe the real impact of effort levels, you can use the same prompt and execute the same task in a coding agent-style tool, isolating thinking effort as the only variable:

• Task content: write SVG animations for 12 emotional emoji faces, with support for switching between them;
• Task characteristics: medium scale, purely front-end and verifiable, room for creativity, code size easy to quantify;
• Observation dimensions: thinking behavior characteristics, output code size, execution time, rework and repair cost, final result.

This task was chosen because it combines both “engineering” aspects (state management, animation transitions, structural organization) and “creative” aspects (expressiveness of the faces, animation rhythm), which can simultaneously expose differences in effort levels along both dimensions.

3. Behavioral Profiles of Three Effort Levels

1. Low: Draft-Style Execution, and What You Save Comes Back to Haunt You

The Low level’s thinking process is extremely short—it essentially starts writing as soon as it receives the requirement, showing a clear “draft-style” character with a strong tendency to “wrap up as quickly as possible.” In this example, the Low level’s first output was only about 8 lines of code—the initial approach immediately failed, completely failing to cover the “12 emoji faces + switching” functionality, and then a large number of rounds had to be invested in re-editing, validation, and repair, ultimately raising both time and token costs.

2. High: The Sweet Spot of Adaptive Thinking

The most notable characteristic of the High level is that it “reads the dish before cooking”: simple problems converge quickly, without thinking for the sake of thinking; complex problems proactively involve engineering deliberation, such as first planning the component structure, then designing the animation state machine, then considering switching logic and exception fallbacks. In this example, High produced about 600 lines of code with moderate thinking length, but noticeably better solution completeness and first-pass success rate.

3. Max: Deep Deliberation with Diminishing Marginal Returns

The Max level’s behavior can be summarized as “repeated agonizing”: first a lengthy round of solution design, then another round of agonizing over implementation details, possibly overturning part of the approach mid-way and starting over, and only then settling on a plan and starting to write. In this example it produced about 900 lines, and it also stumbled on the same bug—just a minor fix was needed to resolve it. In other words, Max pays significantly more thinking and generation overhead, but the quality improvement it gains is quite limited.

4. Breaking Down the Cost Structure: First-Pass Writing + Validation and Repair

If you break down the time spent on this kind of task, the main overhead consists of two parts: first-pass writing, and validation and repair. This perspective explains many “perceptual contradictions”:

• What Low saves is thinking cost, but the first-pass hit rate is low, causing validation and repair costs to surge, so total cost exceeds the alternatives;
• High and Max differ little in execution time, indicating that once you enter the “write code + fix bugs” loop, differences in first-pass quality are quickly diluted, and effort-level differences mainly show up in the upfront thinking phase;
• Therefore, the real value of thinking effort lies in improving the first-pass hit rate, not in compressing total elapsed time.

An intuitive comparison for this example:

Effort level	First-pass code size	Rework situation	Overall impression
Low	~8 lines	Initial approach failed, heavy re-editing	Strong draft feel, high repair cost
High	~600 lines	Converged smoothly	Best balance of time and quality
Max	~900 lines	One bug, minor fix	Laborious, limited payoff

5. Results and Creativity: Max Is Not Necessarily Best

If you only look at “does it run,” both High and Max are within an acceptable range; but from the aesthetic and creative dimension of the final result, the conclusion is more interesting: the Low level’s draft-style output actually showed greater potential. The reason is that creative work often requires human participation to experiment in more directions, while deep automated deliberation converges too early on a “safe solution,” locking down the exploration space prematurely. Conversely, on tasks with stronger engineering characteristics and lower tolerance for error, first-pass quality carries more weight, and the advantage of deep thinking becomes apparent. This also suggests that effort-level selection should match the task type, rather than being mindlessly maxed out.

6. Selection Recommendations

Combining the test results with everyday practice, here are the recommendations:

1. Default to High. High is sufficient for the vast majority of scenarios; and on simple tasks, High adaptively spends fewer tokens, without causing obvious waste;
2. For batch simple tasks and rapid prototyping, Low can be used, but you must accept draft-style output and reserve time for quick manual iteration;
3. For complex architecture and high-risk tasks, Max can be considered, but you need to budget time and cost, and set expectations for “diminishing returns”;
4. For creative tasks, deep human involvement is recommended, using multiple rounds of small experiments instead of one-shot deep deliberation;
5. Confirm platform semantics before rollout. Different reasoning services name and implement effort levels differently. When using a cloud large-model inference service such as Baidu AI Cloud, consult the documentation first to confirm the exact meaning of the thinking toggle and effort parameters, then factor them into cost estimates.

An illustrative call shape is roughly as follows (pseudocode, for illustration only):

response = llm.generate(
    prompt="Generate SVG animations for 12 emotional emoji faces with switching support",
    reasoning_effort="high",   # non-thinking / low / high / max
)

The front-end implementation of the task itself is not complex; for example, a minimal SVG animation element can be written like this:

<svg viewBox="0 0 100 100">
  <circle cx="50" cy="50" r="30" fill="#ffd54f">
    <animate attributeName="r" values="30;34;30" dur="1s" repeatCount="indefinite"/>
  </circle>
</svg>

The real difference lies in how the model plans the overall structure: whether it designs an emoji parameter system first and then batch-generates, or hardcodes each one; whether the switching logic reuses a single animation template, or maintains each emoji independently. The quality of these decisions is exactly what thinking effort directly affects.

7. A Common Evaluation Pitfall: Truncated Thinking Display

There is another easy trap: some platforms or clients truncate the display of the thinking process by default, showing only the first-line summary, which can easily make people think the model “thought very briefly and did not try hard enough.” In reality, the model’s internal reasoning may be very long—the interface simply does not present it in full. Therefore, when comparing effort levels or models, do not judge by the thinking length shown in the UI; instead, observe actual token consumption, execution time, and task results, and if necessary verify the real thinking overhead through API logs.

8. Summary

The essence of thinking effort levels is a trade-off between first-pass hit rate and reasoning overhead. Testing shows that Low is a draft, Max is a deep dive, and High becomes the sweet spot for most scenarios thanks to adaptive thinking; while creative tasks may actually gain more room from lower effort levels combined with human collaboration. Only by incorporating the “first-pass writing + validation and repair” cost model into evaluation, and then choosing effort levels based on task type, can reasoning budgets truly be spent where they matter.