Extended thinking

Your prompt is clear, specific, well-structured, and has good examples. You've run it through evals. The score is almost where you need it but not quite — the remaining errors are all on the gnarliest reasoning cases, the ones where even a human would want to stop and think for a minute before answering. Extended thinking is the feature designed for exactly this case. It lets Claude allocate a scratch-pad of tokens to work through a problem before producing the final response.

What extended thinking is

Extended thinking is an advanced reasoning mode where Claude explicitly generates a chain of thought in a dedicated "thinking" block before producing its user-facing answer. Think of it as giving Claude a whiteboard to work things out on. You see the reasoning. The model doesn't jump straight to a conclusion — it writes out its steps, catches its own mistakes, and then produces the final answer.

Two practical benefits:

• Higher accuracy on hard reasoning problems. Multi-step math, complex logic puzzles, tricky edge cases in structured analysis — tasks where the gap between "plausible answer" and "correct answer" is a bunch of intermediate reasoning.
• Transparency into the thought process. You can log the thinking block, inspect it when something goes wrong, and use it to understand why Claude gave a particular answer.

And two real costs:

• More tokens per response. You pay for the thinking tokens as well as the output tokens.
• Higher latency. The thinking step adds seconds (sometimes tens of seconds) before the final answer starts.

The response structure changes

Normally a Claude response is a single text block. With extended thinking enabled, you get a structured response with at least two blocks:

• A thinking block (or, occasionally, a redacted thinking block — more on that in a moment) containing the reasoning.
• A text block containing the final user-facing answer.

Your code has to handle both. text_from_message from Module 6 still pulls just the user-facing text (it filters by block.type == "text"), so the thinking block is automatically skipped when you're rendering to users. For debugging or logging you can iterate the content list and extract the thinking block on its own.

Redacted thinking and cryptographic signatures

Two security considerations show up with extended thinking.

Signatures. Every thinking block comes with a cryptographic signature — a token that authenticates the thinking as genuinely produced by Claude. This matters when you're passing Claude's thinking back into a subsequent request: the signature lets Anthropic verify you haven't edited the reasoning. Tampering with a model's stated reasoning could push follow-up generations somewhere unsafe, and the signature is how that's prevented.

Redacted thinking. Occasionally Claude's thinking gets flagged by internal safety systems. When that happens, you receive a redacted thinking block instead of readable text — the content is present but encrypted. You can't read it, but you can still pass the block back to Claude in a follow-up request, which preserves the conversation's reasoning continuity without exposing the redacted text.

Your code needs to handle redacted thinking gracefully. If your pipeline tries to print or render every thinking block as plain text, a redacted one will crash it. Check for the redacted type and either skip it or display a placeholder. Anthropic provides a test string you can send that triggers a redacted response reliably — use it to verify your handling path before shipping.

Implementation

Extend the chat helper from Module 6 with two parameters:

def chat(
    messages,
    system=None,
    temperature=1.0,
    stop_sequences=[],
    tools=None,
    thinking=False,
    thinking_budget=1024,
):
    params = {
        "model": model,
        "max_tokens": 4096,  # must be greater than thinking_budget
        "messages": messages,
        "temperature": temperature,
        "stop_sequences": stop_sequences,
    }

    if system:
        params["system"] = system
    if tools:
        params["tools"] = tools
    if thinking:
        params["thinking"] = {
            "type": "enabled",
            "budget": thinking_budget,
        }

    return client.messages.create(**params)

Three constraints worth internalising:

• thinking_budget has a minimum of 1024 tokens. Smaller budgets aren't accepted.
• max_tokens must be greater than thinking_budget. Otherwise the model runs out of room for the actual answer after thinking.
• Extended thinking is incompatible with some other features, notably message prefilling and a non-default temperature. Check Anthropic's docs for the current compatibility list before combining thinking with another feature — it's the single most common foot-gun when enabling thinking on an existing prompt.

Call it:

chat(messages, thinking=True)

Or with a bigger budget for really complex problems:

chat(messages, thinking=True, thinking_budget=8192)

When to turn thinking on

Use your evals to decide. This is the honest, eval-driven answer, and it's the only one that's not just a vibes call:

1. Run your prompt without thinking first. Measure the score.
2. Optimise the prompt using every technique from Module 5 — clarity, specificity, XML structure, examples. Measure again after each change.
3. If the score still isn't meeting your accuracy bar after the prompt is as good as you can reasonably make it, enable extended thinking. Measure one more time.
4. If thinking closes the gap, ship it. If it doesn't, thinking isn't your problem — the prompt is.

Skipping step 2 is the common mistake. Extended thinking is not a substitute for a well-written prompt; it's a capacity multiplier on top of one. A vague prompt with thinking enabled will produce a vague answer more slowly and for more tokens. A sharp prompt with thinking enabled will produce a sharp answer with better reasoning depth.

Cost discipline

Thinking tokens are real tokens you pay for. Two habits that keep the cost sane:

• Only turn thinking on for the endpoints that need it. A customer-support chatbot that mostly handles "where's my order" doesn't need thinking on every turn. Enable it selectively for the hard queries.
• Don't over-budget. thinking_budget=1024 is the minimum and is enough for many problems. Bumping it to 8192 triples your cost and may not move the accuracy needle — measure first.

Extended thinking is a powerful tool when you need it and a cost trap when you don't. The rule is the same as every other advanced feature in this module: evals first, feature second.