Chain of Thought and Extended Thinking

Reasoning before answering improves accuracy on anything multi-step: maths, planning, code analysis, nuanced classification. There are two ways to get it. Chain-of-thought prompting asks the model to write its reasoning as part of the visible response. Extended thinking gives the model a separate, structured reasoning phase before the response, exposed through the API as thinking content blocks. The exam tests when each applies, how extended thinking is configured across model generations, and the rules for handling thinking blocks in multi-turn and tool-use conversations.

Chain-of-thought prompting

The simplest form is an instruction: "Think step by step before answering." Better is to structure it: "Reason inside <thinking> tags, then give the final answer inside <answer> tags." The structured version lets your code strip the reasoning and return only the answer, or stop generation after </answer> with a stop sequence. Chain of thought costs output tokens and latency, so apply it to tasks that benefit and not to simple lookups. Because the reasoning is ordinary output, it is subject to max_tokens and is visible to the user unless you remove it.

Extended thinking

Extended thinking moves reasoning into a dedicated phase. The request carries a thinking parameter; the response contains one or more thinking blocks before the text block.

response = client.messages.create(
    model=MODEL,
    max_tokens=16000,
    thinking={"type": "adaptive"},            # current models
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": problem}],
)
for block in response.content:
    if block.type == "thinking":
        log(block.thinking)        # may be a summary, or empty, depending on display settings
    elif block.type == "text":
        answer = block.text

Configuration has changed across generations and the exam expects you to know the principle for each:

• Earlier models use thinking: {"type": "enabled", "budget_tokens": N}. The budget is a target for reasoning tokens; it must be at least 1,024 and less than max_tokens, because thinking tokens count towards the output limit.
• Current models use adaptive thinking ({"type": "adaptive"}), where the model decides how much to think per request. Depth is steered with output_config.effort (low through high, with higher levels on some models) rather than a token budget; sending budget_tokens to these models is rejected. On the newest models thinking is on by default and cannot be disabled.

Always check the model's page in the documentation for which configuration applies.

Thinking tokens are billed as output tokens. Recent models return a summarised version of the reasoning, or omit the text entirely by default; the full reasoning is never exposed, but you are billed for the thinking the model actually did, not the summary length.

Handling thinking blocks

Two rules govern multi-turn use. First, during a tool-use exchange the assistant turn containing thinking blocks and tool_use blocks must be passed back unchanged, including any redacted_thinking blocks (encrypted reasoning the API may emit); altering or dropping them produces an error. Second, thinking blocks from earlier completed turns do not need to be resent and, where sent, are not billed as input; on older models the API strips them from context, which has prompt-caching consequences in agent loops. Thinking blocks are also bound to the model and conversation that produced them; replaying them to a different model or after editing earlier history can cause them to be dropped or rejected.

Extended thinking is incompatible with assistant prefill and, on most models that support it, with changes to sampling parameters such as temperature.

Interleaved thinking with tools

Current models can think between tool calls within a single turn: reason, call a tool, reason about the result, call another. This is what makes agentic tasks tractable without hand-written chain-of-thought scaffolding. It also means a long agentic turn may spend most of its budget thinking, so size max_tokens generously and stream.

Choosing between them

Situation	Approach
Model supports extended thinking and the task is complex	Extended thinking with effort tuned per route
You need the reasoning visible to users as part of the answer	Chain-of-thought prompting with tags
Latency-sensitive, simple task	Neither; or effort: low
Agentic loop with many tool calls	Extended (interleaved) thinking
Model without extended thinking	Chain-of-thought prompting

Prompting a thinking-enabled model to "think step by step" is usually redundant; give it the problem and the success criteria instead. Prompts written to force reasoning from older models often over-constrain newer ones.

Cost control

Effort is the first lever: lower it for routine routes, raise it where accuracy matters, and measure on real traffic before changing a default. Pin thinking and effort settings per route rather than varying them per request, because changing them invalidates the cached conversation prefix.

Exam focus

• Chain of thought is visible reasoning in the output; extended thinking is a separate phase returned as thinking blocks.
• Older models configure thinking with budget_tokens (minimum 1,024, less than max_tokens); current models use adaptive thinking steered by output_config.effort, and reject budget_tokens.
• Thinking tokens are billed as output; summaries or omitted text do not reduce the bill.
• In a tool-use exchange, thinking and redacted_thinking blocks must be passed back unchanged; earlier-turn thinking is not billed as input.
• Extended thinking is incompatible with prefill and with non-default sampling parameters.
• Pin thinking and effort per route; changing them invalidates the messages cache.