Reasoning LLMs Tested: Choosing Between Low, High, and Max Thinking Effort Levels

1. Background: From One-Size-Fits-All to Tiered Reasoning

Reasoning-based Large Language Models (LLMs) generate a lengthy internal thought process before providing a final answer. This mechanism is used for task decomposition, solution comparison, and self-verification. While it significantly improves the quality of complex tasks, it introduces new challenges: longer thinking leads to higher response latency and greater token consumption. For simple tasks, lengthy reasoning is a pure waste of resources; for complex tasks, too little reasoning is insufficient.

To solve this contradiction, the industry has introduced “thinking effort levels” (adjustable reasoning intensity) as a general capability, handing control over the thinking budget to developers. The low tier restricts thinking length for rapid response; the high tier allows for comprehensive engineering reasoning; the max tier essentially removes limits, letting the model thoroughly weigh various possibilities. Focusing on these three tiers—Low, High, and Max—this article conducts a comprehensive test using a reproducible coding task to answer three questions: How large is the behavioral difference between the tiers? Where do the costs differ? Which tier should be the default for daily development?

2. Evaluation Design: Selecting a Task That “Amplifies Differences”

Tier differences are nearly invisible in simple tasks (all tiers can answer instantly) and are prone to collective failure in overly difficult tasks. An appropriate evaluation task should meet three criteria:

1. Verifiable functionality: Correct or incorrect outcomes can be judged objectively, eliminating subjective interference.
2. Open-ended details: There is no single correct solution, allowing observation of the model’s reasoning depth and willingness to refine.
3. Medium complexity: The task requires both engineering structure and attention to boundary conditions and dynamic details.

The task selected for this evaluation is: A minimalist emoji system based on SVG animations, delivered as a single HTML page. It requires implementing 12 emotional expressions (anger, disgust, fear, sadness, surprise, happiness, calmness, etc.), each with dynamic characteristics (vivid and not rigid), supporting smooth transitions at any time, and featuring a “seemingly random” auto-drift switching mechanism.

This task is ideal for tier evaluation: it requires the model to decompose expressions into deformable components (eyes, eyebrows, mouth), design smooth transitions between states, and implement pseudo-random scheduling logic—testing both structural reasoning and detail/aesthetic trade-offs.

Testing Methodology: Using the same AI coding tool, keeping the exact same prompt, and only switching the thinking effort level, with all other parameters remaining completely consistent. Four metrics were recorded: lines of thought, initial solution quality, repair rounds, and total time consumed.

3. Test Results: Behavioral Profiles of the Three Tiers

Low Tier: Draft-style thinking, eager to finish. The thought process is only in the single digits of lines, basically following a “get requirements -> start immediately” rhythm, with an obvious tendency to rush to completion. In this test group, the low tier’s initial approach crashed directly, forcing a massive amount of effort into re-editing and verification repairs later. Consequently, the total time and token costs actually increased. However, it is worth noting: the “skeleton” produced by the low tier is lightweight. If combined with multiple rounds of human iteration, creative tasks might actually have more experimental space—rapidly generating drafts and having humans pick the direction can be more effective than the model overthinking alone.

High Tier: The Sweet Spot. It converges quickly on simple sub-problems without dragging, while seriously engaging in engineering reasoning for complex sub-problems, resulting in a few hundred lines of thought. The overall performance is stable with no obvious shortcomings. In testing, even if bugs occasionally occurred, they only required minor tweaks before delivery.

Max Tier: Overthinking. Typical behavior involves a lengthy debate over the overall system design, followed by another round of debating implementation details. It might even overturn its existing approach midway and start over before finally settling on a plan and coding. The number of thinking lines is about 50% more than the high tier, but there is no corresponding advantage in total execution time—it completed the task after minor bug fixes just like the high tier, but the overall experience felt “laborious.”

A summary of the observations from this test group is as follows (for reference only; absolute values will vary by task and model):

Observation Dimension	Low Tier	High Tier	Max Tier
Thinking Length	~8 lines	~600 lines	~900 lines
Initial Solution	Crashed, required rework	Stable	Stable, but laborious process
Repair Overhead	Massive re-editing & verification	Minor tweaks	Minor tweaks
Overall Experience	Draft-style, rushing to finish	Balanced depth & speed	Overthinking design then details

It must be emphasized: while the above is a single set of observations, the behavioral pattern differences among the three tiers are stable and reproducible. This is the core output of the evaluation.

4. Cost Structure Breakdown: Initial Coding + Verification & Repair

The total overhead of a coding task can generally be broken down into two parts:

• Initial Coding: Thinking process + initial code generation.
• Verification & Repair: Running tests, locating issues, and repeated modifications.

The low-tier case reveals a critical rule: costs saved during the thinking phase may be paid back double during the repair phase. An incorrect initial solution means rework, and each round of rework involves a full chain of “read context + locate + rewrite + re-verify,” which is far more expensive than thinking it through once. This is the hidden cost of “insufficient thinking.”

Meanwhile, the execution time difference between the high and max tiers is minimal, indicating that for medium-complexity tasks, once thinking depth exceeds a certain threshold, marginal returns diminish. The extra reasoning is mostly spent on “agonizing and self-overturning,” which does not translate into a better final solution.

Therefore, the essence of tier selection is finding a balance between two types of costs:

• Insufficient thinking -> Hidden cost is rework, with both time and tokens rising.
• Excessive thinking -> Explicit cost is waiting and consumption, making the experience “laborious.”

5. Selection Recommendations: Default to High, Adjust as Needed

Combining the test results and daily user experience, here are four actionable recommendations:

1. Default to High for daily tasks. The high tier has a certain self-adaptive ability to task difficulty: it automatically converges for simple problems without wasting tokens, and provides sufficient reasoning depth for complex problems. For most scenarios, simply using the high tier is sufficient; no need to overthink it.
2. Reserve Max tier for hard tasks. Multi-constraint trade-offs, architecture-level design, and problems with dense boundary conditions are worth the “laborious” cost. Do not enable max tier by default.
3. The correct way to use Low tier is “draft + human.” It is suitable for rapid prototyping, direction exploration, and creative experimentation. The low tier has high variance and a lower floor, but a lightweight skeleton and high potential. It is best used to leave the “direction picking” decision to humans, running a few sets and picking the best.
4. Do not blindly rely on Max tier for creative tasks. Deeper thinking does not equal better creativity. Sometimes, the combination of “short and fast output + human iteration” is more likely to produce surprises than a long session of the model agonizing over a single round.

6. A Common Misconception: Displayed Thinking Length ≠ Actual Reasoning Intensity

During the testing process, another pitfall was discovered: some models or tools default to truncating or collapsing the display of the thought process, only revealing the first line. This easily misleads people into thinking “this model didn’t think much.” In reality, when testing the same task with such models, the internal thinking might last a long time, but it simply isn’t fully displayed.

From this, two judgment principles can be derived:

1. Do not judge tier strength by the “visible thinking text length.” Instead, judge it comprehensively based on actual token consumption, response latency, and final output quality.
2. Tier naming is not comparable across models. Model A’s low tier is not necessarily weaker than Model B’s high tier. The true intensity difference of tiers with the same name varies greatly across different products. Selection conclusions must be based on tests using your own business tasks, not on tier labels.

If integrating an LLM via a model service platform like Baidu AI Cloud, it is recommended to first confirm the target model’s support for reasoning intensity-related parameters in the official documentation before deciding whether to implement tier management at the application layer.

7. Methodology: How to Conduct Your Own Tier Evaluation

The conclusions above come from a specific task, but the evaluation methodology itself is more universally applicable:

1. Select a task: Verifiable functionality + open-ended details + medium complexity (like the SVG emoji system in this article).
2. Control variables: Same prompt, same tool, same parameters; only switch the tier.
3. Record metrics: Lines/words of thought, initial solution quality, repair rounds, total time, manual score.
4. Multiple samples: Run each tier at least 2-3 times to get an average, ruling out accidental crashes.
5. Form conclusions: Clearly define the team’s “daily sweet spot tier” and “hard task tier,” and document them in development guidelines.

Using the emoji system as an example, the deliverable looks something like this (illustrative code):

<svg viewBox="0 0 120 120" class="face" data-emotion="happy">
  <ellipse class="eye" cx="42" cy="48" rx="5" ry="7"/>
  <ellipse class="eye" cx="78" cy="48" rx="5" ry="7"/>
  <path class="mouth" d="M40 76 Q60 94 80 76"/>
</svg>

The core of the “seemingly random” auto-drift switching is pseudo-random scheduling (illustrative code):

// Avoid mechanical equal intervals: random intervals + non-repeating extraction
function pickNext(current) {
  const pool = EMOTIONS.filter(e => e !== current);
  return pool[Math.floor(Math.random() * pool.length)];
}
const delay = 4000 + Math.random() * 5000; // 4s ~ 9s jitter
setTimeout(() => switchTo(pickNext(current)), delay);

These types of small tasks, which “have acceptance criteria but also aesthetic space,” are ideal samples for evaluating the cost-effectiveness of model tiers. It is recommended that each team establishes a few of their own “benchmark tasks” for quick regression validation when models or tools are upgraded.

8. Appendix: Full Prompt Used in This Evaluation

Create a minimalist emoji system HTML page based on SVG animations,
capable of smoothly switching to the following expressions at any time:
anger, disgust, fear, sadness, surprise, happiness, calmness. 
You can add a few more, totaling 12.
Each expression state should contain dynamic characteristics to appear 
vivid and not rigid. Include an auto-switching mechanism that drifts 
between expressions over time at a seemingly random rhythm.

9. Conclusion

Tiered thinking transforms “reasoning depth” from a model black box into an adjustable parameter for developers. The core conclusion of this test is: all three tiers can ultimately complete the task, but the differences lie in the process experience and cost structure—the low tier is the draft zone, the high tier is the sweet spot, and the max tier is the heavy-lifting zone. For daily development, defaulting to the high tier is sufficient; reserve the max tier for truly hardcore, multi-constraint tasks; for creative and prototype exploration, use the low tier to quickly generate drafts and leave directional decisions to humans. The most important methodology: don’t just look at the tier name and the displayed length of the thinking text—let your own real-world task tests do the talking.