Claude Extended Thinking Prompts: A Production Guide

Claude extended thinking prompts unlock a qualitatively different mode of reasoning: the model reasons privately before responding, using an internal scratchpad to explore constraints, check assumptions, and revise plans before committing to an answer. When you craft prompts specifically for this mode, output quality on complex tasks improves substantially enough to matter for both production deployments and exam performance alike.

Domain 4 of the CCAR-F (Prompt Engineering & Structured Output) carries 20% of the exam weight, per Anthropic's official exam guide, making it one of the two heaviest domains alongside Claude Code Configuration. Extended thinking scenarios appear regularly in Domain 4 because they demand the proportionate judgment the exam rewards: matching capability to task complexity rather than always enabling the most powerful option. Our Prompt Engineering & Structured Output concept library maps every Domain 4 task statement to practical techniques, including the patterns we cover here.

How does extended thinking work at the API level?

Extended thinking is activated by passing a thinking object to the Messages API. The budget_tokens field sets an upper bound on internal reasoning tokens. Claude then returns one or more thinking content blocks before its final text block. These blocks are the model's internal scratchpad and are not exposed to end users in most production deployments.

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=16000,
    thinking={"type": "enabled", "budget_tokens": 10000},
    messages=[{"role": "user", "content": "Analyse this contract and identify every liability cap."}]
)
for block in response.content:
    if block.type == "thinking":
        print("Thinking:", block.thinking)
    elif block.type == "text":
        print("Answer:", block.text)

One critical constraint: max_tokens must exceed budget_tokens by at least the expected output length. A safe default is max_tokens = budget_tokens + expected_output_tokens + 500. Setting max_tokens below budget_tokens is an API error; setting it only marginally above leaves almost no room for the final text block.

When does extended thinking justify its cost?

Extended thinking increases both latency and token cost. The task type determines whether the investment pays off.

The CCAR-F exam consistently rewards proportionate solutions. An item describing a trivial extraction task expects you to recognise that enabling extended thinking would be over-engineered; an item describing a multi-constraint compliance check expects you to recommend it.

What prompt patterns work best with claude extended thinking prompts?

State outcomes, not procedures

The most common mistake is over-specifying how Claude should think. When you list steps ("read the document, then identify clauses, then rank them"), the thinking budget executes your script rather than genuinely reasoning about the problem. This parallels the goal-based vs step-based prompts distinction from Domain 1 of the exam: state what to achieve and let Claude determine how.

# Less effective: step-based
Step 1: Read the contract.
Step 2: Identify liability clauses.
Step 3: Rank by exposure.

# More effective: goal-based
Identify every liability cap, rank by maximum financial exposure, and flag
any clause whose scope is ambiguous. Justify your ranking.

The outcome-first version leaves Claude free to determine the optimal reasoning path during its thinking phase. The step-based version turns extended thinking into an expensive compliance exercise.

Front-load constraints in labelled sections

With extended thinking, constraints placed early in clearly labelled XML sections are more reliably respected than constraints buried mid-prompt. Claude references them during its reasoning pass without needing them restated in the user turn:

<constraints>
- Cite clause numbers for every liability figure.
- Mark ambiguous caps as "disputed" rather than estimating a value.
- Output valid JSON matching the schema provided.
</constraints>

Separating what Claude must satisfy (constraints) from what Claude must produce (schema) is a core technique in the Prompt Engineering & Structured Output domain. On the exam, this pattern distinguishes prompt-based constraint enforcement from schema-based enforcement.

Add a self-verification instruction

Extended thinking creates a natural second-pass opportunity. When the cost of an error is high, instruct Claude to re-examine its reasoning before finalising:

After completing your analysis, review your thinking and confirm that no
liability clause was missed. If you find a gap, revise your answer.

This mirrors the high-stakes enforcement decision rule: when consequences are severe, add a verification layer rather than relying on a single reasoning pass. The exam rewards this pattern in both Domain 4 and Domain 5 compliance scenarios.

Combine extended thinking with tool call schemas

Extended thinking and structured output via tool calls are complementary. Thinking helps Claude satisfy complex constraints without violations; a tool call schema guarantees the final output is machine-parseable regardless of how Claude phrases its internal reasoning.

response = client.messages.create(
    model="claude-sonnet-4-5",
    max_tokens=12000,
    thinking={"type": "enabled", "budget_tokens": 6000},
    tools=[{
        "name": "submit_analysis",
        "description": "Return structured liability analysis.",
        "input_schema": {
            "type": "object",
            "properties": {
                "clauses": {
                    "type": "array",
                    "items": {
                        "type": "object",
                        "properties": {
                            "clause_id": {"type": "string"},
                            "cap_usd": {"type": ["number", "null"]},
                            "disputed": {"type": "boolean"}
                        },
                        "required": ["clause_id", "cap_usd", "disputed"]
                    }
                }
            },
            "required": ["clauses"]
        }
    }],
    tool_choice={"type": "auto"},
    messages=[{"role": "user", "content": prompt}]
)

The CCAR-F exam distinguishes between asking Claude to "output JSON" in the system prompt (prompt-based and fragile) and using a tool call schema (programmatic and reliable). When downstream systems must parse the response, the tool call approach is the correct answer on the exam.

How should you calibrate the thinking budget?

The relationship between budget_tokens and output quality is not linear. We recommend the following calibration workflow:

1. Start at 5,000 tokens for most analytical tasks.
2. Run your evaluation suite and measure quality against pass criteria.
3. Double the budget if Claude produces shallow justifications or truncated reasoning.
4. Halve the budget if quality metrics are passing and latency is a constraint.
5. Never set the budget below 1,024 tokens for multi-step tasks: truncated reasoning consistently produces worse outputs than no thinking at all.

For latency-sensitive agentic pipelines, consider applying extended thinking only to the orchestrator's planning turn in a hub-and-spoke architecture, routing deterministic sub-tasks to standard API calls without a thinking budget. This captures the quality benefit where it matters most while controlling end-to-end latency.

What mistakes degrade extended thinking quality?

Over-constraining the reasoning process. Adding instructions like "Think step by step: first do X, then Y" turns the thinking budget into a compliance exercise. State the goal; let the thinking determine the path. This is the most common error we observe when practitioners first adopt extended thinking.

Mismatched token budgets. Setting max_tokens only slightly above budget_tokens leaves almost no room for the final text block. Budget for both thinking tokens and output tokens when setting max_tokens, not just one or the other.

Ignoring thinking blocks in evals. If your evaluation pipeline reads only the final text block, you lose the richest diagnostic signal for prompt failures. Logging and inspecting thinking blocks is a core part of context management and reliability for extended thinking pipelines. Circular reasoning, premature conclusions, and missed constraints in the thinking block are prompt-quality signals, not model limitations.

Setting budget_tokens higher than needed. A larger budget increases cost and latency without guaranteed quality gains. Calibrate empirically against eval metrics rather than defaulting to a high budget.

How does this topic appear on the CCAR-F exam?

Extended thinking scenarios in Domain 4 typically ask you to choose between prompt-only formatting versus tool call schemas, low thinking budgets versus high ones, and goal-based prompts versus step-based prompts. The exam penalises probabilistic solutions when deterministic ones exist: a compliance extraction task should trigger tool calls combined with extended thinking, not a system prompt instruction to "please format as JSON."

The five CCAR-F domains are weighted as follows, per Anthropic's official exam guide:

Domain 5 intersects with extended thinking: thinking blocks consume tokens from the context window. In long agentic sessions where extended thinking fires on multiple turns, budget for thinking token accumulation when planning context compaction. A session generating 10,000 thinking tokens per orchestrator turn hits context limits far earlier than one using 1,000. As of 3 June 2026, more than 10,000 individuals have earned Claude Partner Network certifications, per Anthropic's programme figures. The CCAR-F exam costs $125 per attempt and scores on a 100 to 1,000 scale with 720 as the passing mark.

Prompt engineering checklist for extended thinking

Before deploying a prompt with extended thinking in production:

1. Is the task complex enough to justify the latency and cost increase?
2. Is max_tokens set to at least budget_tokens plus expected output length plus 500?
3. Are constraints front-loaded in a clearly labelled XML section?
4. Is the goal stated as an outcome, not a procedure?
5. Is a tool call schema used for any response downstream systems must parse?
6. Does the pipeline log thinking blocks for evaluation and debugging?
7. Has the thinking budget been calibrated against eval metrics, not set arbitrarily?