Thinking Modes & Extended Reasoning

Default mode is fast. Sometimes you need deep.

By default, Claude Code jumps straight to an answer. That's great for simple tasks. But for complex problems: architecture decisions, tricky bugs, multi-step plans: you want it to think first, not just react.

Claude Code has three ways to control how deeply it thinks before doing anything.

Thinking modes in action

Extended thinking

Extended thinking means Claude "thinks out loud" internally before giving you an answer. It reasons through the problem step by step, considers edge cases, and arrives at a more careful response.

When it's worth it:

Complex debugging where your first approach already failed
Architecture decisions with real trade-offs
Security reviews where you can't afford to miss something
Refactoring that touches 10+ files

How to enable it: Set the thinking effort level in settings, or just ask: "think carefully about this" or "reason through this step by step" in your prompt.

What it costs: Extended thinking uses output tokens for the reasoning process. You pay for the thinking. For complex tasks, the quality improvement is usually worth it. For a simple bug fix, it's overkill.

All three models (Opus 4.6, Sonnet 4.6, Haiku 4.5) support extended thinking with their 1M token context windows.

Plan mode

Plan mode is the most practical thinking feature for daily use. Instead of diving into code changes immediately, Claude proposes a plan first. You review it, adjust if needed, then it executes.

Toggle it: Shift+Tab in the terminal, or /plan as a slash command.

What happens:

You give Claude a task
Claude proposes a step-by-step plan
You review and approve (or adjust)
Claude executes the approved plan

Use plan mode when:

Any task touching more than 2-3 files
You're not sure about the approach
Destructive operations (deleting files, resetting databases)
Onboarding a new team member who needs to see the steps

Skip plan mode when:

Quick fixes ("change this color from blue to green")
Single-file edits
Tasks you've done the same way dozens of times

# Enable plan mode for the session
/plan

# Or toggle with keyboard shortcut
# Shift+Tab (toggles on/off)

Effort levels

Some tasks need deep thinking. Others just need a quick answer. Effort levels let you control the balance without switching models:

Level	What it means	Example
Low	Quick, surface-level response	"What does this function do?"
Medium	Standard analysis (default)	"Fix this bug"
High	Deep reasoning, considers edge cases	"Design the auth system"

You can hint at the effort level in your prompt. "Quick question..." signals low effort. "Think carefully about..." signals high effort. "Consider all edge cases..." signals maximum depth. Claude picks up on these cues.

Combining thinking modes

The real power is mixing these together.

Plan mode + Opus: For architecture decisions. Claude thinks deeply AND shows you the plan before executing. Maximum safety, maximum quality. Use this when you're redesigning something load-bearing.

Quick mode + Haiku: For rapid iteration. Fast answers, low cost. Great for "does this look right?" checks throughout the day.

Extended thinking + Sonnet: The daily sweet spot. Sonnet thinks through the problem carefully but doesn't take as long (or cost as much) as Opus. This is what I use for most non-trivial tasks.

Same task, three effort levels

Practical patterns

The "think then do" pattern

"Before you make any changes, analyze this codebase and tell me:
1. What's the current architecture?
2. What are the risks of changing X?
3. What's your recommended approach?

Then wait for my approval before making changes."

This forces Claude to think first even without plan mode. Useful when you want the reasoning visible but don't want to toggle a mode.

The "rubber duck" pattern

"I'm stuck on this bug. Don't fix it yet. Just think through 
what could be causing it. List your hypotheses from most to 
least likely."

Use Claude as a thinking partner, not just a code generator. Sometimes the most valuable thing it does is help you articulate the problem clearly.

The "pre-mortem" pattern

"I'm about to deploy this change. Before I do, think about 
what could go wrong. What edge cases am I missing?"

Extended thinking plus a pre-mortem catches issues that quick mode would miss entirely. I run this before any deploy that touches auth, payments, or data migrations.

Patterns