How to Choose Reasoning Effort Levels: A Look at Thinking Budget Trade-offs Through an SVG Animation Task

1. The Problem

Reasoning models that support multiple “thinking budget” levels are now a common configuration. When submitting a task, users not only write a prompt but also make an implicit decision: how long should the model think? A low setting may produce a hasty plan; a high setting may lead to endless deliberation. This trade-off is almost invisible in simple Q&A, but it becomes significantly amplified in engineering tasks that require complete code output.

This article uses a specific SVG emoji animation generation task as a sample to compare low, medium, and high thinking budgets across four dimensions: output scale, execution time, rework cost, and final quality. It then offers a reusable method for choosing effort levels. The article does not rely on any product-specific private parameters; all conclusions come from engineering measurements of the task itself and can be mapped to any reasoning service that supports thinking budget configuration.

2. Experiment Design

2.1 Task Setup

The goal is to generate a single-page HTML application that uses inline SVG animation to implement a minimalist emoji system, with the following requirements:

• At least 12 emoji states, covering basic emotions such as anger, disgust, fear, sadness, surprise, happiness, and calm, with reasonable extensions;
• Each emoji must have dynamic features, avoiding the stiffness of static images;
• Smooth transitions between emojis;
• A built-in automatic switching mechanism that drifts through emojis over time at an approximately random rhythm.

The defining characteristic of this task is that there is no single correct answer, but there are many implicit constraints—animation timing, state machine transitions, SVG path morphing, and visual consistency. It tests the model’s ability to design a solution and also exposes the rework caused by “thinking too little.”

2.2 Metrics

To avoid a one-sided conclusion based only on speed, the experiment records the following metrics:

1. Lines of code in the first round: reflects how much design density the model is willing to invest in the first attempt;
2. Total execution time: total time from submission to a usable result;
3. Rework count and repair cost: the proportion of time spent re-editing, validating, and patching after the initial approach fails;
4. Final usability: whether the output requires human intervention to reach a deliverable state.

3. Comparison of the Three Levels

3.1 Low: Fast, but More Like a Draft

The low setting can be summarized as “draft-style output.” It tends to produce a minimal runnable structure as quickly as possible. The first-round code volume is very small—only about 8 lines of core logic in this task—and the animation and switching mechanisms are extremely simplified.

The problem is that this initial approach failed at the state transition stage: the switching logic did not properly handle animation interruption and re-entry, causing jumps in emoji transitions. Because the underlying structure was too thin, the fix could not be done locally and the whole thing had to be rebuilt. As a result, “re-editing + validation and repair” consumed a large amount of time and compute. The low setting has the lowest nominal cost, but may have the highest actual total cost—this is the most counterintuitive conclusion of the experiment.

That said, low effort is not without value. Draft-style output is fast and lightweight, making it suitable for quick exploration, verifying whether the prompt is clear, or serving as a starting point for human创作. Its problem is not “thinking shallowly” but “thinking shallowly and rushing to finish.”

3.2 Medium: The Sweet Spot

Medium is the sweet spot in this experiment. Its behavior is characterized by adaptively allocating thinking effort according to difficulty: simple sub-problems converge quickly without unnecessary delay, while complex sub-problems (such as state machine design and animation timing orchestration) trigger engineering reasoning and noticeably longer thinking time.

In this task, the first-round output was about 600 lines, covering complete state definitions, transition curves, and automatic drift scheduling. Execution time was not much different from high effort, but the output structure was clearer and more maintainable, and there were no directional errors requiring a rebuild. For the vast majority of scenarios that require deliverable code, medium offers the best value.

3.3 High: Deep Thinking, Heavy Cost

The high setting has a distinctive behavior pattern: first a long round of overall solution design, then a round of haggling over implementation details, possibly overturning part of the approach midway, and only then writing code. The first-round output was about 900 lines, the largest in scale.

In terms of time, high and medium did not differ by an order of magnitude, indicating that for medium-complexity tasks, the marginal benefit of “thinking more” is diminishing. More importantly, high effort also stumbled on a boundary bug; because the structure was more complete, the fix was a minor patch rather than a major overhaul.

This suggests a rule of thumb: high effort buys plan redundancy, not zero defects. It reduces the probability of directional errors, but does not eliminate all implementation flaws.

3.4 Summary Comparison

Dimension	Low	Medium	High
First-round code volume	Very small (draft level)	Moderate (~600 lines)	Large (~900 lines)
Directional errors	Occurred, required rebuild	None	None
Rework cost	High	Low	Low
Total time	Increased due to rework	Moderate	Slightly higher
Suitable scenarios	Exploration, drafts, human starting point	Default delivery	Highly uncertain complex tasks

4. Rethinking the Cost Structure

Most people intuitively assume that “the longer the model thinks, the more expensive it is.” But this experiment shows that real cost consists of two parts:

Total cost ≈ First-pass authoring cost + Validation and repair cost

Low effort puts almost the entire budget into “first-pass authoring,” pushing it to a minimum, but then “validation and repair” spirals out of control, causing total cost to exceed that of higher settings. Medium and high effort invest more in first-pass authoring in exchange for a lower probability of repair. This suggests that when evaluating effort levels, you should look at the rework rate rather than first-round speed. A practical estimation method is to record the “first-pass usability rate” for similar tasks; the lower that rate is for a given effort level, the more deceptive its nominal low cost becomes.

5. Effort Selection Strategy

Based on the experiment, here are practical recommendations:

1. Use medium by default. It does not waste effort on simple problems and does not skimp on complex ones, making it a stable choice for most engineering tasks.
2. Use low for exploration, not delivery. Treat low-effort output as a requirements clarification draft; after confirming the prompt and structural direction, switch to medium for formal generation.
3. Reserve high for highly uncertain tasks. When a task involves multi-option trade-offs, cross-module constraints, or a correct form you cannot predict in advance, high effort’s redundant reasoning pays off. Conversely, using high effort on well-bounded tasks is mostly paying for repeated deliberation.
4. Factor validation cost into selection. If the output requires extensive automated testing or human review, prioritize the effort level with the lower rework rate rather than the fastest first round.
5. Do not judge thinking effort by displayed length. Some services only show the first segment or a summary of the reasoning process; appearing to “think briefly” does not mean the actual thinking was less. Judge effort levels by task duration and output quality, not by the visible length of reasoning text.

6. A Note on Creative Tasks

Returning to the task itself: from a visual aesthetics perspective, the low-effort draft actually had more tension in some emojis—its simplified structure unexpectedly produced more exaggerated dynamic effects. This raises an easily overlooked point: in creative tasks, effort level does not equal the quality ceiling, and human experimentation remains irreplaceable. Deeper reasoning tends to converge on safe solutions, while creativity often comes from trial and error with non-optimal solutions. A reasonable approach is to use medium or high effort to generate structure and a baseline, then manually conduct secondary experiments on low-effort drafts or variant versions.

7. Conclusion

Thinking effort is not a “higher is always better” switch, but a budget that must be allocated according to task difficulty. The conclusion from this SVG animation task is: medium is the sweet spot; low is suitable for exploration but requires vigilance against rework amplification; high buys plan redundancy rather than zero defects. By shifting the evaluation focus from “how fast the first round is” to “how much rework occurs,” you can make genuinely economical effort choices.