Prompting with Extended Thinking

Knowing when to enable extended thinking is half the battle. The other half is knowing how to write prompts that work with it rather than against it. The counterintuitive finding from working with extended thinking is that the prompting style that works best is often the opposite of what most prompt engineers expect.

---

The Central Insight: High-Level Goals, Not Step-by-Step Instructions

When extended thinking is enabled, Claude uses its internal scratchpad to plan and reason through the problem. If you've already provided a detailed step-by-step breakdown of how to approach the problem, you've taken that responsibility away from Claude — and often constrained it to a reasoning path that isn't optimal.

Without extended thinking, explicit step-by-step instructions are often helpful. They substitute for Claude's limited working memory in a single forward pass.

With extended thinking, those same instructions can hurt performance. They force Claude to follow a predetermined path rather than discovering the best approach during its internal reasoning phase.

The shift in mental model: instead of writing a procedure for Claude to execute, write a problem for Claude to solve.

---

What Changes in Your Prompt Style

Without Extended Thinking	With Extended Thinking
Break the task into numbered steps	State the goal and constraints clearly
Tell Claude exactly what to do first	Let Claude decide its own approach
Specify the reasoning path	Specify the quality criteria for the output
"First do X, then do Y, then do Z"	"Solve X. Requirements: Y. Output format: Z."

This doesn't mean being vague. It means shifting from prescribing the method to describing the problem and the desired outcome.

---

The "Think Deeply About X" Pattern

One effective pattern is a direct invitation to reason thoroughly, without specifying how. This simple framing signals to Claude that deep analysis is expected and appropriate.

Compare these two approaches for a complex code architecture task:

Constrained (less effective with thinking):

First, list all the components we'll need.
Then, for each component, describe its responsibilities.
Next, define the interfaces between components.
Finally, identify any potential bottlenecks.

Goal-oriented (more effective with thinking):

Think carefully about the best architecture for this system.
Requirements: [list requirements]
Constraints: [list constraints]
Produce a complete design with justification for each major decision.

The second version lets Claude use its thinking phase to explore the design space before committing. The first version locks it into a structure before that exploration happens.

---

Thinking Budget Optimization

On current Claude models you do not set a thinking budget in tokens. Thinking is adaptive, and you steer how deeply Claude reasons with the effort setting in output_config.

Practical starting points:

• low: simple, high-volume, or latency-sensitive tasks
• medium: a balance of speed, cost, and quality
• high: complex reasoning, hard coding problems, and agentic tasks
• xhigh and max: the hardest long-running work, where you have measured a gain

The default level depends on the model. Start with the default or high for a hard problem. If quality is already good, try one level lower. You may get the same result at lower cost. If quality is insufficient, go one level higher. Test on your own tasks, because the right level differs by model and by workload.

Token budgets (budget_tokens) apply only to older models. Claude 4.7 and later models reject them.

---

Using Thinking for Code Generation and Debugging

Extended thinking is particularly valuable for:

Architecture from scratch — designing a system before any code exists, where the thinking phase explores different structural approaches and their tradeoffs.

Root cause analysis — when a bug has multiple plausible causes and systematic elimination is required. The thinking phase works through candidates before settling on an explanation.

Refactoring decisions — evaluating whether to restructure code and what the safest migration path looks like.

For code tasks, your prompt should describe what the code needs to do and the constraints it operates under, not the implementation steps. Let the thinking process explore the implementation.

---

Known Limitations

No response prefilling. Current Claude models do not accept a prefilled response at all, with or without thinking. To control the output format, use structured outputs, format instructions, or XML tags, as covered in the prefilling lesson.

You see a summary of the thinking at most. The API never returns the raw reasoning. A display setting on the thinking configuration controls what you get: summarized returns a readable summary, and omitted returns empty thinking blocks. On the newest models the default is omitted, so you receive only the final output unless you ask for the summary. Either way, you are billed for the full reasoning as output tokens.

Thinking adds latency. Deeper reasoning takes longer. For very fast tasks, lower the effort setting. On current models Claude may then skip thinking on easy requests. On older models that still use budget_tokens, the minimum budget is 1,024 tokens.

---

Prompt Templates for Extended Thinking

These templates show the high-level, goal-oriented structure that works best.

---

Try It: A Complex Reasoning Task

The prompt below is structured using the goal-oriented style suited for extended thinking. Run it, then experiment by rewriting it as step-by-step instructions to see how the output changes.

---

---

Key Takeaways

• With extended thinking enabled, high-level goal descriptions outperform step-by-step instructions
• The thinking phase is for internal reasoning. Let Claude determine its own approach rather than prescribing it
• Use the pattern: describe the problem, state the constraints, specify what a good output looks like
• Prefilling does not work on current Claude models. Use structured outputs, format instructions, or XML tags for format control
• On current models, steer thinking depth with the effort setting. Start lower and raise it one level at a time based on output quality
• The API returns a summary of the thinking at most, and on the newest models it returns none by default. You are still billed for the full reasoning