Thinking Modes & Extended Reasoning

Claude Code can show you its thinking process. For complex problems, it can engage extended reasoning—thinking deeply before responding. Understanding these modes helps you leverage Claude’s full problem-solving capability.

What Is Thinking?

When Claude works on a problem, it thinks through the solution internally. You can see this thinking process displayed in the interface:

<thinking>
The user wants to add authentication. I need to consider:
- Which auth method fits their stack?
- What security requirements apply?
- How does this integrate with existing code?
</thinking>

Based on your Flask setup, I recommend JWT authentication...

Why Thinking Matters

Visible thinking helps you:

• Understand Claude’s reasoning - See why it chose an approach
• Catch misunderstandings early - Notice if Claude misread requirements
• Learn problem-solving patterns - Observe how to break down complex tasks
• Trust the output - Verify the logic behind suggestions

Normal vs Extended Thinking

Claude has two thinking modes:

Mode	When Used	Characteristics
Normal	Most tasks	Quick, focused reasoning
Extended	Complex problems	Deep, multi-step reasoning

Normal Thinking

For standard tasks, Claude thinks briefly:

> add input validation to the login form

<thinking>
Need to validate email format and password requirements.
Check existing validation patterns in the codebase.
</thinking>

I'll add validation to the login form...

Extended Thinking (Ultrathink)

For complex problems, Claude engages extended reasoning automatically:

> debug why the payment webhook fails intermittently

<thinking>
This is a complex debugging task. Let me think through this systematically:

1. Intermittent failures suggest:
   - Race condition?
   - Network timeout?
   - Webhook signature validation timing out?

2. Need to check:
   - Webhook logs for patterns
   - Signature verification code
   - Database transaction handling

3. Common causes for Stripe webhooks:
   - Idempotency key issues
   - Database locks during high traffic
   - Signature timestamp expiry (5 min window)

Let me start by examining the webhook handler code...
</thinking>

I'll investigate the webhook handler. Based on the symptoms...

Ultrathink

“Ultrathink” is the community term for Claude’s extended reasoning mode. When you see longer thinking blocks with numbered steps and deep analysis, Claude has engaged extended reasoning.

When Claude Uses Extended Reasoning

Claude automatically engages extended reasoning for:

1. Complex Debugging

> the authentication flow works locally but fails in production
> users report intermittent login issues
> no obvious errors in logs

Why extended thinking helps: Multi-variable problems require systematic elimination of possibilities.

2. Architecture Decisions

> should we use microservices or a monolith for this new feature?
> consider: team size (4 devs), traffic (10k DAU), deployment complexity

Why extended thinking helps: Weighing tradeoffs requires considering multiple factors simultaneously.

3. Security Reviews

> review this authentication module for security vulnerabilities
> focus on: injection attacks, session handling, cryptographic issues

Why extended thinking helps: Security analysis requires thinking like an attacker, considering edge cases.

4. Performance Optimization

> this endpoint is slow (p95: 2 seconds)
> profile and suggest optimizations

Why extended thinking helps: Performance issues often have multiple contributing factors requiring systematic analysis.

5. Refactoring Complex Systems

> refactor the legacy order processing system to use event sourcing
> maintain backward compatibility during transition

Why extended thinking helps: Large refactors require understanding dependencies and planning migration paths.

Requesting Extended Reasoning

You can explicitly request deeper thinking:

> think carefully about the best approach for [problem]
> before implementing, analyze all the edge cases
> use extended reasoning to debug [complex issue]

Keywords that trigger extended thinking:

• “think carefully”
• “analyze thoroughly”
• “consider all possibilities”
• “systematic analysis”
• “what are all the ways this could fail?”

Reading Thinking Output

Structure of Extended Thinking

<thinking>
1. Problem analysis
   - What we know
   - What we don't know
   - Assumptions to verify

2. Possible approaches
   - Option A: [pros/cons]
   - Option B: [pros/cons]

3. Recommendation
   - Why this approach
   - Risks and mitigations
</thinking>

What to Look For

Good signs:

• Breaks problem into components
• Considers multiple approaches
• Identifies assumptions
• Thinks about edge cases

Warning signs:

• Jumps to conclusions
• Ignores constraints you mentioned
• Missing obvious considerations

If thinking goes off track, interrupt:

> stop - your thinking is missing [important constraint]
> reconsider with this additional context: [clarification]

Impact on Performance & Cost

Token Usage

Extended thinking uses more tokens:

Mode	Typical Token Cost	Example
Normal thinking	+100-300 tokens	Simple feature
Extended thinking	+500-2000 tokens	Complex debugging

The thinking tokens count as input tokens in your usage.

Response Time

Extended reasoning takes longer:

• Normal: 2-10 seconds
• Extended: 10-30 seconds (or more for very complex problems)

Caution

Extended thinking is worth the cost for complex problems but overkill for simple tasks. Don’t request “think carefully” for straightforward work like “add a comment to this function.”

Best Practices

1. Let Claude Choose

For most tasks, let Claude decide whether to use extended reasoning:

# Good: Let Claude assess complexity
> debug the payment processing issue

# Unnecessary: Forcing extended thinking for simple tasks
> think deeply and carefully about adding this print statement

2. Use for Decision Points

Request extended thinking when making important decisions:

> we need to choose between PostgreSQL and MongoDB for user data
> think through the tradeoffs given our requirements: [list requirements]

3. Interrupt Bad Reasoning

If thinking goes wrong, stop it early:

> your analysis is missing the fact that we use Redis for caching
> restart your thinking with that in mind

4. Save Complex Thinking

When Claude produces good analysis, save it:

> save this analysis to docs/architecture-decisions/auth-approach.md

Future sessions can reference it without re-thinking.

Thinking vs Plan Mode

Thinking and plan mode serve different purposes:

Feature	Thinking	Plan Mode
Purpose	Internal reasoning	User interaction
When	Always (visible or not)	When planning complex features
Output	Thinking blocks	Clarifying questions + plan
Your role	Observer	Participant (answer questions)

They work together:

# Plan mode with extended thinking
> [in plan mode] add a notification system

<thinking>
Complex feature. Need to clarify:
- Notification types (email, push, in-app)
- Delivery mechanism
- User preferences
- Scale considerations
</thinking>

[Claude uses AskUserQuestion tool to clarify]

<thinking>
Based on answers:
- Email + in-app notifications
- Using SendGrid for email
- Need: templates, queueing, user prefs
</thinking>

Here's the implementation plan...

Common Questions

”Can I disable thinking?”

You can’t disable thinking (it’s core to how Claude works), but you can request more concise responses:

> be concise, minimal explanation

“Why doesn’t Claude always use extended reasoning?”

Extended reasoning is expensive (time + tokens). Claude uses it when the problem requires it. For simple tasks, normal thinking is sufficient and faster.

”Can I see thinking for past responses?”

Thinking is shown during generation. If you missed it, you can ask:

> explain your reasoning for that last suggestion

“Does thinking affect output quality?”

Yes—extended thinking improves quality for complex problems. Research shows LLMs perform better on hard tasks when they “think out loud.”

Examples by Task Type

Bug Investigation

> the webhook endpoint returns 200 but payments aren't processed

<thinking>
Intermittent issue. Possible causes:
1. Race condition in payment processing
2. Database transaction not committed
3. Webhook processed but business logic fails silently
4. Return 200 before async job completes

Need to check: logs, database, async job queue
</thinking>

Architecture Choice

> should we use WebSockets or Server-Sent Events for real-time updates?

<thinking>
Requirements: real-time updates to browser clients

WebSockets:
- Pro: Bidirectional, widely supported
- Con: More complex, requires connection management
- Con: Harder to load balance

Server-Sent Events:
- Pro: Simpler, auto-reconnect built-in
- Pro: Works over standard HTTP
- Con: One-way only (server → client)

Given the use case (server pushes updates, client doesn't need to send data):
SSE is simpler and sufficient.
</thinking>

Code Review

> review this authentication code for security issues

<thinking>
Security review checklist:
1. Password storage: bcrypt/argon2? ✓
2. Session handling: secure cookies?
3. SQL injection: parameterized queries?
4. Rate limiting on login?
5. Password reset token expiry?

Checking each...
</thinking>

Pro Tip

When Claude engages extended thinking on a complex problem, that’s your signal the problem genuinely is complex. If you expected a simple answer but see extended thinking, re-examine your assumptions.