DEV Community

Cover image for Extended Thinking: How to Make Claude Actually Think Before It Answers
Rajesh Royal
Rajesh Royal

Posted on

Extended Thinking: How to Make Claude Actually Think Before It Answers

#tutorial #claudecode #productivity #beginners

Unlock Claude's step-by-step reasoning for complex problems that deserve more than a quick response

From: x.com/adocomplete

Introduction

Have you ever asked Claude a complex question and received an answer that felt... too fast? Like it didn't fully consider all the implications, edge cases, or trade-offs before responding?

You're not imagining it. By default, Claude generates responses token by token, which is incredibly fast but doesn't always allow for the kind of deep reasoning that complex problems require. It's like asking someone to explain quantum physics while they're speed-walking to a meeting—they'll give you something, but it won't be their best work.

Extended Thinking changes this equation entirely. It's a feature that gives Claude a dedicated space to reason through problems step by step before formulating a response. Think of it as giving Claude a whiteboard and some quiet time before it has to present its solution.

The Problem

Not all questions are created equal. Some are simple lookups: "What's the syntax for a Python list comprehension?" Others require genuine reasoning: "How should I architect this microservices system to handle 10x traffic growth while maintaining data consistency?"

The challenge is that Claude's default behavior treats both questions similarly. It starts generating a response immediately, which is perfect for simple queries but suboptimal for complex ones.

What happens without extended thinking:

  • Claude begins formulating an answer before fully understanding the problem
  • Subtle edge cases get missed
  • The first approach that "works" gets proposed, not necessarily the best one
  • Complex trade-offs aren't fully explored
  • You often have to ask follow-up questions to get Claude to consider aspects it initially overlooked

The real cost:
You end up in a back-and-forth loop: "But what about X?" "Oh, good point, let me reconsider..." "And what about Y?" This iterative refinement burns tokens and time. Worse, sometimes Claude commits to an initial approach and has difficulty pivoting even when better alternatives exist.

The Solution

Extended Thinking is activated through the API by adding a thinking configuration to your request. When enabled, Claude explicitly shows its reasoning process in dedicated thinking blocks before providing its final response.

How to Use It

Add this to your API request:

{
  "model": "claude-sonnet-4-20250514",
  "max_tokens": 16000,
  "thinking": {
    "type": "enabled",
    "budget_tokens": 5000
  },
  "messages": [
    {
      "role": "user",
      "content": "How should I design a rate limiting system that works across multiple server instances?"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

The key parameter is budget_tokens—this is how many tokens Claude can use for its internal reasoning before responding. Think of it as thinking time.

What You Get Back

With extended thinking enabled, Claude's response includes thinking blocks that show its reasoning:

[Thinking]
Let me break down this rate limiting problem:
- Multi-instance means we need shared state
- Options: Redis, distributed counters, or sticky sessions
- Redis is most common, but adds infrastructure dependency
- Need to consider: token bucket vs sliding window algorithms
- Edge cases: clock skew between servers, race conditions...
[/Thinking]

For a multi-instance rate limiting system, I recommend using Redis with a sliding window algorithm. Here's why and how to implement it...
Enter fullscreen mode Exit fullscreen mode

You see exactly how Claude arrived at its recommendation.

Pro Tips

Adjust budget based on complexity:

// Simple reasoning (architecture decisions)
"budget_tokens": 3000

// Medium complexity (system design)
"budget_tokens": 5000

// High complexity (debugging intricate issues)
"budget_tokens": 10000

// Maximum reasoning (novel research problems)
"budget_tokens": 20000
Enter fullscreen mode Exit fullscreen mode

Use extended thinking for specific problem types:

  • System architecture decisions
  • Debugging complex, multi-file issues
  • Code review with security implications
  • Performance optimization strategies
  • Designing APIs and data models

Don't use it for everything:
Extended thinking adds latency and cost. For simple questions ("How do I import useState in React?"), it's overkill. Reserve it for problems where you genuinely need Claude to think deeply.

Read the thinking blocks:
The reasoning process is often as valuable as the final answer. You'll learn how Claude approaches problems, and you can intervene if you see it going down a wrong path.

Combine with specific prompts:
Extended thinking works best when you give Claude something substantive to think about:

"Analyze the trade-offs between using PostgreSQL vs MongoDB 
for this use case. Consider: query patterns, scaling needs, 
team expertise, and long-term maintenance."
Enter fullscreen mode Exit fullscreen mode

Real-World Use Case

The Scenario:
You're building a payment processing system and need to decide on an idempotency strategy. This is a high-stakes decision—get it wrong and you might double-charge customers.

Without Extended Thinking:

You: "How should I implement idempotency for my payment API?"

Claude: "You should use idempotency keys. Store them in your 
database and check before processing. Here's a basic implementation..."
Enter fullscreen mode Exit fullscreen mode

This answer isn't wrong, but it's surface-level. It doesn't consider your specific constraints or edge cases.

With Extended Thinking:

You: "How should I implement idempotency for my payment API? 
We use PostgreSQL, expect 10k transactions/hour, and our 
payment provider is Stripe."

[Thinking]
Payment idempotency is critical - double charges destroy trust.
Let me consider the full picture:

1. Stripe has built-in idempotency - should we rely on it 
   entirely or add our own layer?
2. At 10k tx/hour, we need efficient key storage and lookup
3. PostgreSQL options: dedicated table, JSONB field, or Redis sidecar
4. Key considerations:
   - Key expiration (Stripe: 24 hours)
   - Race conditions during concurrent requests
   - What happens if our DB write succeeds but Stripe fails?
   - Retry behavior and exponential backoff
5. Edge case: distributed system means possible duplicate 
   requests to different servers...
[/Thinking]

Given your setup with PostgreSQL and Stripe, I recommend a 
two-layer idempotency strategy...
Enter fullscreen mode Exit fullscreen mode

The extended thinking version catches the Stripe integration detail, considers race conditions, and thinks about failure modes—all before responding.

Conclusion

Extended Thinking is like giving Claude permission to pause and reflect before answering. In a world that often rewards speed over depth, this feature is a reminder that some problems deserve more than an instant response.

The best part? You're not just getting better answers—you're getting a window into how Claude reasons. This transparency helps you understand when to trust its recommendations and when to push back. It turns Claude from a black box into a thinking partner whose reasoning you can follow and critique.

For complex decisions, enable extended thinking. Watch Claude work through the problem. Engage with its reasoning. You'll end up with better solutions and a deeper understanding of the problem space.

Coming up tomorrow in Day 4: Session Management—because your laptop dying mid-debug shouldn't mean losing an hour of context. Learn how to never lose your work again. See you then!

This is Day 3 of the "31 Days of Claude Code Features" series. Follow along to discover one powerful feature every day that will transform how you use Claude Code.

Top comments (0)