Choose the Right Thinking Level for the Problem

The mistake most people make is defaulting to ultrathink for everything the moment a problem gets hard. The intermediate levels are faster, cheaper, and often sufficient — and for many problems, think hard gets you the same answer in half the time.

Use think when:

• The question has a clear answer but needs care
• You want Claude to reason through trade-offs before recommending an approach
• You're asking about potential issues or edge cases in existing code

think

Review this middleware — what are the edge cases that could
cause a request to bypass authentication?

Use think hard or think harder when:

• Debugging a non-obvious bug where the root cause isn't immediately apparent
• Comparing architecture approaches where the right answer genuinely isn't obvious
• Designing something that needs to be correct before you build it

think hard

We're seeing intermittent failures in our payment webhook handler.
The logs show the handler runs successfully but payments aren't
being recorded. What could cause this?

Reserve ultrathink for:

• Distributed system design where subtle concurrency issues matter
• Security architecture where missing an edge case has real consequences
• Algorithm design where you need exhaustive analysis of trade-offs

A useful heuristic: if you could solve it with a second read-through of the docs, think is enough. If you've been stuck for hours, that's an ultrathink problem. Everything in between lives at think hard.

See the ultrathink tip for a deeper look at when maximum reasoning is worth the wait.

Match the thinking level to the problem — most hard things don't need maximum effort, just more careful effort.