How to Choose Between Low, High, and Max Thinking Effort in AI Coding Tools: A Benchmark Test

As large-model-driven coding tools increasingly expose a “thinking effort” mechanism, developers face a practical question: for the same task, should you choose low, high, or maximum effort? Does longer reasoning always produce better code? I recently ran a front-end animation benchmark task through one coding tool’s Low, High, and Max settings, and summarized the observed behavioral differences, cost structure, and selection conclusions for reference when you conduct similar evaluations.

1. What Thinking Effort Is and Why It Deserves Careful Testing

First, let’s align on the concept. Thinking effort refers to a mechanism that lets users control how much “internal reasoning budget” the model invests before and during production of the final answer. It is typically divided into three levels:

• Low: minimal upfront reasoning; the tool starts almost immediately upon receiving the task, producing draft-style output.
• High: adaptive to problem difficulty—simple problems converge quickly, while complex problems trigger genuine engineering deliberation.
• Max: fully expanded reasoning, repeatedly weighing multiple approaches, sometimes discarding and restarting before writing code.

The problem is that reasoning consumes tokens and time, and it is unclear whether “more thinking” translates linearly into “higher-quality code.” That directly determines which level to use by default and which tasks justify Max. Abstract discussion is not useful; the best approach is to design a benchmark task that is human-reviewable and quantifiable, then actually run it.

2. The Benchmark Task: An SVG Animation System with 12 Emotional Expressions

I gave all three levels exactly the same task:

Build a minimalist-style HTML page with an SVG-animation-based facial expression system that can smoothly switch at any time to the following expressions: angry, disgusted, fearful, sad, surprised, happy, and calm. You may extend the set, for a total of 12. Each expression state should include some dynamic characteristics so it looks lively rather than stiff, and there should be an automatic switching mechanism that drifts between expressions over time at a seemingly fairly random rhythm.

I chose this task for several reasons:

1. Visual and human-reviewable results. Whether expressions look lively and transitions are smooth can be judged by eye in a second, without writing complex automated test scripts.
2. Constraints and creativity coexist. The task specifies seven required expressions and hard constraints such as “smooth switching” and “random drift,” while leaving room for “extend to 12” and “minimalist style.” This tests both constraint adherence and aesthetic and creative quality.
3. Full engineering elements. To achieve “lively rather than stiff,” the model must reason through how to model expression parameters (how eyebrows, eyes, and mouth shapes interpolate), how to make transition animations smooth, how to avoid mechanically uniform intervals in the random drift rhythm, and the overall state-machine structure—excellent material for testing engineering reasoning.
4. Single file, clear boundaries. The output is a standalone HTML page, so all three levels are compared under identical conditions, eliminating noise from external dependencies.

3. Measured Results: Reasoning Length and Behavioral Profiles

(1) Low: Draft-style, but the draft is too short. The reasoning process was only about 8 lines, giving an overall impression of “rushing to finish”: it started immediately upon receiving the task, and the plan had barely taken shape. To be fair, a draft-style output is not inherently bad—rapid exploration followed by manual refinement is a legitimate creative workflow. The problem was that this draft was too short: in this test, Low’s initial approach failed outright, and a large amount of subsequent effort had to go into re-editing, verification, and fixes, driving up both time and cost. The reasoning budget saved upfront was paid back double in rework.

(2) High: The sweet spot. Reasoning was about 600 lines. The behavior was adaptive—simple sub-problems converged quickly without dragging, while key difficulties (the interpolation scheme for transition animations, the rhythm design for random drift) triggered genuine engineering deliberation, with multiple approaches compared before implementation. Considering final quality, elapsed time, and rework count together, High was the most balanced of the three.

(3) Max: An overzealous perfectionist. Reasoning was about 900 lines. The process can be summarized as: a long round of agonizing over overall design, then another round over implementation details, then discarding part of the existing approach mid-way and starting over, and only then deciding on a plan and beginning to write code—it looked very “laborious.” The result? End-to-end execution time was roughly the same as High, it failed on the same bug, and it was fixed the same way with small patches. Those extra hundreds of lines of reasoning did not translate into “fewer bugs” or “faster convergence.”

Summary: Reasoning length and final quality are not linearly related. The gain from Low to High is clear; from High to Max, marginal returns approach zero and can even turn negative—because the time cost genuinely increases.

4. Breaking Down the Cost Structure: First-Pass Writing + Verification and Fixes

The most valuable finding from this test was the breakdown of the task’s total cost structure. The end-to-end cost of one code generation roughly satisfies:

Total cost ≈ reasoning overhead + first-pass writing + Σ(verification + fix) loops

How the three levels performed on each term:

• Low: reasoning near zero and fast first-pass writing, but the initial approach was wrong, and verification-and-fix loops consumed the bulk of total cost—making it more expensive and slower overall.
• High: moderate reasoning, high first-pass quality, and only a few verification-and-fix rounds needed.
• Max: highest reasoning overhead, first-pass quality comparable to High, and the same fix loops present.

This yields an important evaluation methodology: do not fixate on single-point metrics such as “how many lines were reasoned” or “how long the first version was.” Record the end-to-end convergence trajectory. Low’s failure case precisely illustrates that what looks “cheap” on a single-point metric may be “expensive” end to end. When testing yourself, at minimum collect the data in the table below:

Metric	Meaning
Reasoning length	Intuitive consumption of reasoning budget
First version runs directly	First-pass writing quality
Rework count	Number of verification-and-fix rounds
End-to-end elapsed time	From task submission to a usable result
Final quality score	Scored against a manual checklist

5. An Easy Pitfall: Displayed Reasoning ≠ Actual Reasoning

One easily overlooked phenomenon deserves mention: some platforms do not display the full reasoning process by default, showing only the first line or a summary, and may even advertise that “high effort is the default,” while the reasoning presented looks suspiciously short. Yet when the same task is actually tested, the internal reasoning turns out to be quite long—only the display layer was truncated.

This has two implications for evaluation. First, do not be misled by “visible reasoning”; evaluation should be based on the final product and end-to-end elapsed time. Second, when comparing different tools side by side, be sure to confirm each one’s reasoning-display policy, to avoid comparing A’s full reasoning against B’s truncated summary and drawing distorted conclusions.

6. A Reusable Evaluation Method

Here is the workflow distilled from this test:

1. Task design: Choose a small-to-medium task that is visual, human-reviewable, and combines constraints with creativity (SVG/Canvas animations and interactive component pages are good choices). State hard constraints and room for creativity clearly in the prompt.
2. Three-level comparison: Run the same prompt at Low, High, and Max two to three times each—single-run variance is not small, and the median of multiple runs is more reliable.
3. Process recording: Collect data per the table above, focusing on where rework occurred and how many rounds of fixes were needed.
4. Result review: Score against a checklist—are all 12 required expressions present, are transitions smooth, is the drift rhythm natural, is the code structure clear and maintainable?
5. Form your own effort strategy: The optimal level differs across task distributions; others’ conclusions are only a reference, and you must test your own distribution yourself.

7. Recommendations for Choosing an Effort Level

Based on this test and day-to-day experience, here are a few selection recommendations:

1. Default to High for the best cost-effectiveness. Most tasks can simply use High. Notably, High does not “use a sledgehammer to crack a nut” on simple tasks—its adaptive nature means simple problems converge quickly without excessive token consumption.
2. Max is not “better,” it is “more expensive.” Max suits tasks that genuinely require deep architectural trade-offs, but you must accept its time cost of repeated agonizing and restarting. If High already produces a reasonable plan after one round of engineering reasoning, Max’s extra investment is likely wasted.
3. For creative tasks, Low may actually offer greater potential. When a task has no single correct answer and requires human participation and iteration, Low’s draft-style output is a good starting point: rapidly generating multiple prototypes and manually selecting and refining them is more efficient than waiting for Max to struggle alone toward one version it considers “perfect.” The optimal solution for creative work often lies in human-machine collaboration, not in the machine thinking harder on its own.
4. Model generations reset what each level means. The observation here is that a new-generation model’s Low level is already clearly stronger than the previous generation’s same level, and may even be no weaker than the previous generation’s default. Therefore conclusions about “which level to choose” must be re-validated with each version iteration; last year’s experience may not hold this year.

8. Illustrative Code: Expression State Machine and Random Drift

Finally, here is a minimal reference implementation of such an expression system to illustrate the technical essentials:

<style>
  #mouth, .eye { transition: all .8s cubic-bezier(.45, 0, .25, 1); }
</style>
<svg id="face" viewBox="0 0 100 100" width="240">
  <circle cx="50" cy="50" r="46" fill="#f7f7f7" stroke="#333" stroke-width="2"/>
  <ellipse class="eye" id="eyeL" cx="35" cy="44" rx="4" ry="6" fill="#333"/>
  <ellipse class="eye" id="eyeR" cx="65" cy="44" rx="4" ry="6" fill="#333"/>
  <path id="mouth" d="M36 68 Q50 71 64 68" stroke="#333"
        stroke-width="2.5" fill="none"/>
</svg>

// 1) An expression = a "parameter snapshot" of brows/eyes/mouth; mouth shapes
//    all use isomorphic M x y Q x y x y paths so interpolation stays structurally
//    consistent and transitions remain smooth
const EXPR = {
  calm:  { mouth: "M36 68 Q50 71 64 68", eyeRY: 6 },
  happy: { mouth: "M34 63 Q50 81 66 63", eyeRY: 5 },
  sad:   { mouth: "M34 74 Q50 57 66 74", eyeRY: 7 },
  angry: { mouth: "M35 72 Q50 61 65 71", eyeRY: 5 },
  fear:  { mouth: "M37 70 Q50 64 63 70", eyeRY: 8 },
  // ...extend the remaining 7 expressions (disgusted, surprised, etc.)
  //    with the same structure to reach 12
};
let current = "calm";
function switchTo(name) {
  const t = EXPR[name];
  mouth.setAttribute("d", t.mouth);  // isomorphic path + CSS transition = smooth transition
  eyeL.setAttribute("ry", t.eyeRY);  // modern browsers support interpolating path d
  eyeR.setAttribute("ry", t.eyeRY);
  current = name;
}
// 2) Random drift: base mean + occasional long pauses, avoiding the stiffness
//    of mechanically uniform intervals
(function drift() {
  const pool = Object.keys(EXPR).filter(k => k !== current);
  switchTo(pool[(Math.random() * pool.length) | 0]);
  const pause = Math.random() < 0.15
    ? 7000 + Math.random() * 5000    // occasional long pause
    : 1500 + Math.random() * 3500;   // normal switching rhythm
  setTimeout(drift, pause);
})();

Three implementation points deserve elaboration: expressing all mouth shapes and similar parameters as isomorphic paths is the technical foundation of the “smooth switching” constraint; constructing the drift rhythm as “base mean + long-tail pauses” is the engineering expression of “seemingly fairly random”; and modeling expressions in groups as parameter snapshots, where switching is state-machine transition plus parameter interpolation, gives a clear structure that is easy to extend.

9. Conclusion

Back to the original question: how should you choose a thinking effort level? The answer from this test is that High is the sweet spot for most scenarios; Max’s deep deliberation has limited marginal returns on routine tasks; and Low’s short drafts are a good starting point for creative collaboration, though the rework cost when the initial approach fails should not be ignored. The more important takeaway is the method: cost should be measured by the end-to-end convergence trajectory, quality should be judged by a human-review checklist, and conclusions should be re-tested as model versions iterate. Tool effort levels will keep evolving, but this evaluation framework can be reused indefinitely.