SECTION 01
What Is Ultrathink | The Feature Explained in 30 Seconds
Claude Code has a built-in mechanism to adjust the depth of AI reasoning in stages. In normal mode, it makes quick surface-level judgments and responds fast. With ultrathink enabled, the internal reasoning tokens increase significantly, allowing the model to examine problems from more angles before answering.
There are three levels of thinking depth. Here's how they break down.
- think: Slightly deeper than normal. Good for light design decisions and code reviews
- think hard: Medium reasoning boost. Useful when you need better accuracy across multi-file changes
- ultrathink: Maximum reasoning depth. Reserved for complex bug hunting, architecture design, and changes you can't afford to get wrong
Enabling it is simple — just write "ultrathink" in your prompt. No special flags or API configuration changes are needed. Claude Code reads the instruction and raises the internal reasoning token limit accordingly.
However, deeper thinking means longer wait times and higher token consumption. This isn't a feature to leave always-on. In practice, knowing when to use it matters far more than knowing how to turn it on.
SECTION 02
Tasks Where Ultrathink Helps vs. Tasks Where It Just Slows You Down
The core decision criterion comes down to one question: "Is this a task where getting it wrong the first time is expensive?" If the cost of redoing work is high, invest in deeper reasoning. If mistakes are easily fixed, normal mode is enough.
Scenarios where accuracy noticeably improves share a common trait — going in the wrong direction means painful backtracking.
- Complex bug root-cause analysis across multiple files. Pass reproduction steps and related code to let it reason through the cause
- Architecture design decisions. Have it evaluate data flow and separation of concerns
- Large-scale refactoring plans. Changes with wide blast radius where rework would be costly
On the other hand, ultrathink adds no real value for tasks like renaming variables, generating boilerplate CRUD code, or simple file operations. Normal mode is dramatically faster for these, and the output quality is identical.
Just being aware of this distinction lets you invest in accuracy only where it matters without disrupting your development rhythm. Using ultrathink for everything is like drizzling premium olive oil on every single dish.
SECTION 03
My Switching Rule | Try the Fast Mode First, Upgrade If Needed
The approach I've settled on is remarkably simple: start with normal mode, and escalate to ultrathink only when accuracy falls short. Instead of leading with deep reasoning, stepping up gradually tends to get you to the right answer faster overall.
The same logic applies to model selection. Running the most powerful settings at all times is actually inefficient — the slower responses break your development tempo. Quick code fixes don't need deep reasoning.
I went through a period of constantly using Opus 4.5, one of Claude's most capable models, and the cost was significant — even the Ultra plan ran out quickly. Keeping deep reasoning always-on means consumption spikes hard, and without restraint, you simply run out of budget.
What this experience taught me is that "on when needed" is the only sustainable approach, not "always on." That said, for complex architecture design or planning phases, the wait time and cost are genuinely worth paying.
My operational flow has settled into this pattern:
- Start with normal mode. If the quality is good enough, you're done
- If accuracy is lacking or there are gaps in reasoning, switch to think or ultrathink
- For tasks where you already know precision matters — design, complex bugs — go straight to ultrathink
SECTION 04
Tips to Maximize Ultrathink's Accuracy
Simply turning on ultrathink doesn't automatically improve output quality. Raising the clarity of your instructions before invoking deep thinking is a prerequisite. Vague prompts plus ultrathink just means the AI spends more time being confused.
Through trial and error, I found that having the AI create an implementation plan before writing code makes a significant difference. Pass requirements as bullet points, and ask it to outline which files to change, which functions to create, step by step. Adding this planning phase alone dramatically improves the AI's understanding.
The recommended sequence looks like this:
- Use Plan Mode to create the plan. Get the full picture of changes organized
- Review and agree on the plan, then proceed to implementation with ultrathink
- If things feel off during implementation, stop and return to planning
A critical signal to watch for: if the AI starts taking unusually long, it may be a sign of intent misalignment. When response times spike or diffs start touching files across the entire project, the AI likely doesn't understand what you actually want.
I used to wait it out, thinking "maybe a smarter answer is coming," only to get diffs that touched unrelated files and created a mess. When the root cause of slow output is misaligned intent, cancel early and revise your prompt.
SECTION 05
Practical Commands and Setup in Claude Code
Enabling ultrathink is as simple as writing the thinking depth instruction in natural language within your prompt. No special CLI flags or configuration file edits are required. Claude Code interprets the prompt content and adjusts internal reasoning tokens.
Here are some example prompt patterns:
- "Use ultrathink to identify the root cause of this bug"
- "Think hard and create a refactoring plan for this module"
- "Think deeply and audit the architecture for issues"
If writing it every time feels tedious, you can embed thinking instructions in your CLAUDE.md file. Place a rule like "use ultrathink before implementing changes that span multiple files" in your project root's CLAUDE.md, and deeper thinking applies automatically for matching tasks.
However, setting permanent ultrathink in CLAUDE.md is not recommended. As discussed, applying deep reasoning to every task inflates both cost and wait time. Keep the condition specific and narrow.
Another practical technique is using /clear to reset the context before re-submitting with ultrathink. Long conversations dilute the AI's attention. When bug fixes or design tasks aren't working out, clearing the context and providing only the essential information often restores accuracy.
SECTION 06
When It's Slow, Overthinking, or Producing Heavy Output
Once you start using ultrathink, encountering unusually slow responses is inevitable. But "slow" doesn't necessarily mean "thinking smartly." More often than not, slowness signals the AI is lost and doesn't grasp the intent of your instructions.
The fundamental fix is "don't wait — cancel". Waiting a long time only to get a diff that touches unrelated files is an experience I've had more than once. Accepting that quality doesn't scale linearly with wait time is essential.
Here are the specific troubleshooting patterns:
- Extremely slow response → The prompt is likely too vague. Cancel and make instructions more specific
- Diffs spreading across too many files → The task granularity is too coarse. Split the prompt and work incrementally
- Repeatedly trying to fix the same area → Context is polluted. Reset with /clear
Claude Code's Rewind feature makes it easy to try a heavy operation and roll back if the result is poor. When attempting large changes with ultrathink, treating it as an experiment with Rewind as your safety net makes the process much less stressful.
Ultimately, the key mindset is not treating ultrathink as a magic wand. Deep thinking is a tool, and like any tool, its effectiveness depends on the quality of instructions from the person using it. When things feel slow, questioning your own prompt first is always the fastest path forward.
SECTION 07
Role Sharing with Other Models and Tools
Trying to cover every development task with ultrathink alone isn't realistic. Using advanced reasoning for design and delegating execution to lower-cost models strikes the best balance between cost and quality.
This principle extends to AI agent architecture: start with a powerful reasoning model for planning, then hand off execution to cheaper models. The way you use ultrathink follows exactly the same logic — concentrate heavy thinking on planning and judgment phases.
The current development tool landscape is in constant flux, with the competitive rankings shifting nearly every week. Betting everything on a single tool carries real risk, and switching by context is the pragmatic approach.
Here's how the role-sharing breaks down:
- Design, planning, complex judgment → The domain where ultrathink and advanced reasoning models earn their cost
- Routine implementation and code generation → Normal mode or faster models are perfectly sufficient
- UI and design work → Choose tools with stronger visual capabilities
What matters most is maintaining flexibility rather than depending on any single tool. Today's best practice may not hold next month. Ultrathink itself will evolve, so internalizing the decision-making "pattern" serves you longer than memorizing specific configurations.
SECTION 08
Practical Workflow | From Decision to Execution
Pulling everything together, here's how to integrate ultrathink into your daily development as a concrete workflow. The key is turning decisions into patterns rather than debating each time.
Step 1: Assess the task. If it's a variable rename or boilerplate generation, use normal mode. If it involves multi-file design decisions or bug diagnosis, it's a candidate for ultrathink. When in doubt, start with normal mode.
Step 2: Add a planning phase. Once you've decided to use ultrathink, don't jump straight to implementation. Have Plan Mode create the plan first. Plan quality determines implementation accuracy, so don't skip this step.
- Pass requirements as clear bullet points
- Specify target files and functions explicitly
- Review the plan before moving to implementation
Step 3: Implement and verify. With an agreed plan, proceed to implementation with ultrathink. If the response is too slow or diffs are spreading too wide, cancel without hesitation. Rewind lets you roll back, so approach it experimentally.
SECTION 09
Judging Cost and Wait Time Trade-offs
When deciding whether to use ultrathink, the trade-off between cost and wait time is unavoidable. Deeper reasoning consumes more tokens and takes longer to respond. Whether this counts as an "investment" or "waste" depends entirely on the task.
The investment pays off when the cost of redoing work exceeds the cost of ultrathink. Considering the effort to fix an architecture mistake after the fact, paying for deeper upfront thinking is a bargain. Conversely, waiting 30 seconds for a fix that takes 5 seconds normally is clearly not worth it.
Here's a quick decision guide:
- Worth the ultrathink investment: Broad-impact design decisions, hard-to-reproduce bugs, production-facing changes
- Normal mode is sufficient: Small local fixes, adding test code, documentation updates
An often-overlooked factor is the impact on your development rhythm. Ultrathink wait times can feel several times longer than normal mode, and inserting them during high-tempo work sessions breaks concentration. Batching heavy-thinking tasks together protects your flow state.
On the cost management side, building a habit of monitoring your plan limits matters. Overusing ultrathink in the first half of the month leaves you short later. When important work is coming up, deliberately conserving capacity with a planned usage strategy makes a real difference.
