Extended Thinking in Claude: When Deep Reasoning Pays For Itself

Last updated: October 18, 2026

Updated October 18, 2026: The code samples check out against @anthropic-ai/sdk 0.135.0, but some guidance around them contradicted Anthropic's extended thinking and thinking docs. Temperature and top_k are incompatible with thinking (and newer models reject any non-default temperature), so the "default to temperature 0" advice and the A/B result behind it are gone. budget_tokens is a target, not a strict cap, must be at least 1,024 and below max_tokens. The thinking text you get back is a summary (or empty when display is omitted), billed at the full thinking token count. Changing the budget between requests invalidates message-level cache breakpoints.

Extended Thinking Is A Power Tool, Not A Default#

Extended thinking is the Claude feature that most teams either ignore or turn on for everything. Both are wrong. It is a budget item - every reasoning token is billed, and a single thinking call can spend 3 to 10x the tokens of a normal completion. Used on the wrong workload, it is a slow, expensive way to get the same answer. Used on the right workload, it is the difference between a model that ships a buggy refactor and one that catches the off-by-one before it merges.

This is the version of the docs I wish I had the first time I plugged thinking into a real product. We will cover what the mode actually does under the hood, the cost-benefit math at the token level, the SDK code you should ship, and the task patterns where the ROI is obvious versus the ones where you are setting cash on fire.

We walked through several live examples in our Extended Thinking Real-World Examples video on YouTube. This post is the long-form, production-grade companion.

What Extended Thinking Actually Does#

Extended thinking gives Claude a private scratchpad. When you enable it, the model emits thinking blocks before it produces the user-visible response. The reasoning is real tokens - it costs real money - but what comes back in the block is never the raw chain of thought: it is a summary, and on models where display defaults to "omitted" the thinking field is empty. Either way you are billed for the full reasoning, which usage.output_tokens_details.thinking_tokens reports. Nothing is shown to your user unless you choose to surface it.

The mechanism is closer to learned chain-of-thought than to a separate reasoning model. The same Claude model is doing the reasoning; you are just paying for the room to do it. Three things change versus a normal call:

1. Cost goes up. Thinking tokens bill at the same rate as output tokens. A task that spends 4k thinking tokens before a 500-token answer costs roughly 9x what the bare answer would.
2. Latency goes up. Time to first user-visible token is no longer milliseconds; it can be 3 to 15 seconds depending on the budget.
3. Quality on hard tasks goes up. Math, multi-step logic, code design, and debugging are dramatically better. Factual lookups and formatting are unchanged.

That last point is the whole game. If your task does not benefit from deliberation, thinking is pure overhead.

The Cost-Benefit Math, In Real Numbers#

Let's put numbers to it. Assume Sonnet pricing of roughly $3 per million input tokens and $15 per million output tokens, with thinking tokens billed at the output rate.

A typical RAG-flavored coding-help call:

• Input: 8k tokens (system + tools + retrieved chunks + user message)
• Output: 600 tokens
• Cost without thinking: 8000 x $3/1M + 600 x $15/1M, roughly $0.033

Same call with a 4k thinking budget:

• Input: 8k tokens
• Thinking: 4k tokens
• Output: 600 tokens
• Cost with thinking: 8000 x $3/1M + 4600 x $15/1M, roughly $0.093

Thinking tripled the bill. That is fine if it caught a bug that would have cost a developer 30 minutes of debugging. It is a disaster if the model was going to give the same answer anyway.

The break-even rule we use:

• Use thinking when the cost of a wrong answer is greater than 5x the call cost. Code generation, architecture decisions, debugging, math.
• Skip thinking when the cost of a wrong answer is small or easy to detect. Summarization, classification, formatting, factual extraction.
• Selective thinking is the production sweet spot: turn it on only for the requests that need it, not for the whole endpoint.

On Fable 5 this dial moved from token budgets to named tiers, and Fable 5 effort levels explained covers what low through xhigh actually cost. In Claude Code, the ultrathink keyword now runs one turn at xhigh on supported models.

For teams running thousands of these per day, eyeballing this math is not enough. We built CodeBurn precisely to surface thinking-token spend per route so you can see which prompts are paying for reasoning they don't need.

The TypeScript Code You Should Actually Ship#

Here is a minimal but production-shaped extended-thinking call using the official Anthropic SDK. Note the explicit budget_tokens and the response handling for thinking blocks.

import Anthropic from "@anthropic-ai/sdk";

const client = new Anthropic();

async function deepReason(userQuestion: string) {
  const response = await client.messages.create({
    model: "claude-sonnet-4-5",
    max_tokens: 8000,
    thinking: {
      type: "enabled",
      budget_tokens: 4000,
    },
    messages: [
      {
        role: "user",
        content: userQuestion,
      },
    ],
  });

  let thinking = "";
  let answer = "";

  for (const block of response.content) {
    if (block.type === "thinking") {
      thinking += block.thinking;
    } else if (block.type === "text") {
      answer += block.text;
    }
  }

  return {
    thinking,
    answer,
    usage: response.usage,
  };
}

A few non-obvious things this code captures:

• budget_tokens is a target, not a strict cap, per Anthropic's docs. The model can stop well before it; max_tokens is the hard ceiling on total output. The minimum budget is 1,024 tokens.
• budget_tokens must be less than max_tokens, because thinking tokens count toward max_tokens and the budget has to leave room for the answer. The API rejects a request that breaks this rule; the one exception is interleaved thinking, where the budget spans all thinking blocks in a turn.
• The response is multi-block. You must iterate over content and dispatch on block.type. A single response.content[0].text will throw at runtime when thinking is enabled.

Prompts That Benefit From Thinking, And Prompts That Don't#

The biggest mistake is assuming "harder prompt = more thinking helps." That is roughly true, but the shape matters more than the difficulty.

Tasks where thinking dramatically lifts quality:

• Multi-step reasoning with intermediate decisions (planning a migration, designing a schema)
• Adversarial debugging where the surface symptom is misleading
• Math and formal logic where the model needs to track state across steps
• Code review of nontrivial diffs where correctness depends on cross-file context
• Constraint satisfaction problems (scheduling, resource allocation)

Tasks where thinking is overhead:

• Lookup and summarization ("what does this paragraph say")
• Structured extraction with a clear schema
• Format conversion (markdown to JSON, SQL to ORM)
• Classification with well-defined labels
• Anything you would write a regex for

A useful heuristic: if you can write a deterministic test that checks the answer in under five lines of code, you probably do not need thinking.

Combining Thinking With Tool Use#

Thinking and tool use are designed to work together, and this is where the real production wins live. The model can reason about which tool to call, call it, see the result inside a thinking block, reason about the result, and call another tool. This is exactly what an agent loop should do.

The mechanics are slightly subtle. When you append a tool_result to the conversation and re-invoke the model, the previous thinking block is preserved in the assistant turn. You must include it in the messages array on the next call, or the model loses its reasoning chain. The SDK helpfully returns thinking blocks with a signature field; pass them back unchanged.

async function agentTurn(messages: Anthropic.MessageParam[]) {
  return client.messages.create({
    model: "claude-sonnet-4-5",
    max_tokens: 8000,
    thinking: { type: "enabled", budget_tokens: 4000 },
    tools: TOOLS,
    messages,
  });
}

Strip thinking blocks before showing the conversation to a user. Keep them when you re-invoke the model. Mixing those up is the most common bug we see.

On newer models, keep the rest of the prefix stable too: changing the system prompt or tools array mid-conversation can invalidate earlier thinking blocks. The Claude API's inline tool definitions add or change a tool in an appended system message instead, so earlier thinking and the cached prefix survive.

Production Gotchas Worth Pinning To Your Wall#

1. Thinking tokens count toward your output rate limits. A 4k thinking budget plus a 1k answer is a 5k output call for rate-limit purposes. Plan capacity accordingly.

2. Thinking content is not deterministic. Two calls with the same prompt can produce wildly different reasoning. If you log thinking for debugging, do not assert on it in tests.

3. You cannot stream a thinking block as plain text. Streaming returns event types that include thinking_delta. If your frontend assumes all deltas are user text, you will leak the model's internal monologue into the UI. Filter on event type.

4. Hold the thinking configuration stable when you cache. The budget value is rendered into the prompt, so changing budget_tokens or switching thinking modes between requests invalidates message-level cache breakpoints, and on some models the tool and system breakpoints too. Pick a budget per route and keep it for the life of a cached conversation. With that in place, a long cached system prompt plus tool definitions with a thinking call on top is the cheapest deep-reasoning configuration we have shipped.

5. Leave temperature alone. Per Anthropic's thinking docs, temperature and top_k are incompatible with thinking on older models (top_p is allowed between 0.95 and 1), and on newer models such as Opus 5.5, Sonnet 5.5 and Haiku 5.5 any non-default temperature, top_p or top_k returns a 400 on every request. Forced tool use (tool_choice of any or a specific tool) is also incompatible with manual extended thinking.

6. Empty thinking blocks happen. On easy questions the model sometimes emits a tiny or empty thinking block and then answers. This is normal. You still pay the request overhead but not the budget.

Selective Thinking: The Production Pattern#

The pattern that delivers ROI in real apps is selective thinking - a router that decides whether the incoming request deserves reasoning. The cheapest router is a Haiku call with a one-line classifier. The most accurate is a small static heuristic plus a Haiku fallback.

async function shouldThink(userInput: string): Promise<boolean> {
  if (userInput.length < 80) return false;
  if (/^(summarize|format|convert|extract)/i.test(userInput)) return false;

  const classifier = await client.messages.create({
    model: "claude-haiku-4-5",
    max_tokens: 5,
    messages: [
      {
        role: "user",
        content: `Does this request require multi-step reasoning, debugging, or design? Answer "yes" or "no" only.\n\n${userInput}`,
      },
    ],
  });
  const text = classifier.content[0].type === "text" ? classifier.content[0].text : "";
  return /yes/i.test(text);
}

In production, this routing pattern typically cuts thinking-token spend by 60 to 80% with zero detectable quality loss on the easy bucket. The classifier costs fractions of a cent. The savings are in dollars per request.

Monitoring Thinking In Production#

Three metrics you should chart from day one:

• Thinking tokens per request, p50 / p95 / p99. Spikes are usually a prompt regression that confused the model.
• Thinking budget utilization. If p99 hits the budget cap, you are clipping reasoning and probably losing quality.
• Wrong-answer rate, with vs. without thinking. This is the only metric that justifies the spend. If it does not move, turn thinking off.

A useful side effect: thinking output is amazing debugging material. When a customer reports a weird answer, the thinking block usually tells you exactly which step the model got wrong. We log it (with PII scrubbing) and review failed requests against it. The 400-Dollar Overnight Bill post-mortem covers the flip side: thinking turned on for the wrong workload, no one watching the meter.

Production Checklist Before You Ship#

• budget_tokens set explicitly, less than max_tokens
• Response parsed by iterating content and dispatching on block.type
• Thinking blocks stripped from user-facing UI
• Thinking blocks preserved when re-invoking with tool results
• Selective routing in front of any high-traffic endpoint
• Thinking-token spend tracked per route, alert on anomalies
• Streaming handlers explicitly filter thinking_delta events
• No temperature or top_k overrides on thinking requests, and no forced tool_choice
• Quality metric (not just cost) tied to the thinking decision

Extended thinking is one of the highest-leverage features in the Claude API on the right workload, and one of the easiest to set fire to your budget on the wrong one. Get the routing right, monitor the spend, and treat the thinking output as the gold mine of debugging data it is.

For more on optimizing Claude in production, see our writeups on prompt caching and tool use patterns.

FAQ#

What is extended thinking in Claude?#

Extended thinking is a Claude feature that gives the model a private scratchpad for reasoning before generating a user-visible response. When enabled, Claude returns thinking blocks containing a summary of its reasoning (or an empty field when display is omitted); the full reasoning is billed as output tokens and can be hidden from end users. It is the same Claude model doing the reasoning - you are paying for the room to think through hard problems.

How much does extended thinking cost?#

Thinking tokens are billed at the output token rate. A call with 4k thinking tokens plus a 600-token answer costs roughly 3x what the same answer without thinking would cost. The break-even rule: use thinking when the cost of a wrong answer is greater than 5x the call cost.

When should I use extended thinking?#

Use extended thinking for multi-step reasoning, adversarial debugging, math and formal logic, code review of nontrivial diffs, and constraint satisfaction problems. Skip it for lookup and summarization, structured extraction, format conversion, classification, and anything you could write a regex for.

How do I enable extended thinking in the API?#

Add a thinking object to your API call with type: "enabled" and a budget_tokens value of at least 1,024. The max_tokens parameter must be greater than budget_tokens. Newer models also support adaptive thinking, where Claude decides how much to think; see Anthropic's thinking docs for which models take which mode. Parse the response by iterating over the content array and checking block.type for thinking or text blocks.

Do thinking tokens count toward rate limits?#

Yes. Thinking tokens count toward your output rate limits. A 4k thinking budget plus a 1k answer is a 5k output call for rate-limit purposes. Plan your capacity accordingly.

Can I combine extended thinking with tool use?#

Yes. Thinking and tool use work together. The model can reason about which tool to call, call it, see the result inside a thinking block, reason about the result, and call another tool. Preserve thinking blocks when re-invoking the model with tool results to maintain the reasoning chain.

How do I stream responses with extended thinking?#

Streaming returns event types that include thinking_delta for reasoning content. Filter on event type before rendering to the UI, or you will leak the model's internal monologue. Only display deltas that are user-visible text content.

Sources#

• Anthropic Extended Thinking Docs
• Anthropic Thinking Overview
• Claude Models Overview
• Anthropic Pricing
• Anthropic TypeScript SDK
• Tool Use Documentation

Continue Reading#

• VibeThinker-3B: A 3 Billion Parameter Model That Outscores Opus 4.5 on Reasoning
• Claude - the model family, pricing, and limits on one page
• Where to Access AI Models - official APIs, cloud platforms, and routers compared