GC-301c · Module 2
When to Increase or Decrease
3 min read
Increase thinking budget when: the model is producing shallow analysis that misses edge cases, debugging sessions are not identifying root causes, architecture suggestions lack consideration of tradeoffs, or security reviews are not catching subtle vulnerabilities. These are signals that the model needs more reasoning space. The fix is not a better prompt — it is a deeper thinking budget that lets the model explore the problem space more thoroughly.
Decrease thinking budget when: responses are taking too long for the task complexity, the model is overthinking simple requests (producing paragraphs of analysis for a one-line change), or you are running batch operations where speed matters more than depth. The "off" setting is appropriate for tasks where the model's first instinct is correct — generating boilerplate, formatting code, simple string manipulations. For these tasks, thinking tokens are pure overhead.
# Thinking budget decision matrix
## Increase (high / 16384+)
- Root cause analysis across multiple files
- Security vulnerability assessment
- Architecture refactoring with dependency analysis
- Complex algorithm design or optimization
- Multi-step migration planning
## Keep at auto
- Feature implementation from a clear spec
- Writing tests for existing code
- Code review (standard)
- Configuration changes
- Most daily development tasks
## Decrease (off / low)
- Bulk file renaming or formatting
- Boilerplate generation from templates
- Documentation writing from outlines
- Simple search-and-replace operations
- Git operations (commit messages, branch management)
- Track correction frequency Note how often you need to re-prompt or correct the model for different task types. High correction rates on complex tasks indicate the thinking budget is too low.
- Experiment with profiles Run the same complex task with auto, high, and off thinking budgets. Compare output quality and latency. The difference is often dramatic and helps calibrate your profiles.
- Build task-specific overrides Create custom commands for high-thinking tasks (/deep-debug, /security-review) that set the thinking budget explicitly. This removes the friction of manually switching budgets.