All payments made in the preview are in test mode. Read more
claudetokenoptimization.com

Optimize

Extended Thinking / Reasoning Token Costs on Claude

Thinking tokens are billed as output tokens — even when the scratch work never appears in the reply. Cap depth with budgets or effort, reserve deep reasoning for hard tasks, and compare that spend to routing a cheaper model first.

Figures last verified 2026-09-19

This page is part of the Optimize hub, which covers the whole topic end to end.

Last updated 19 September 2026. This page explains claude extended thinking cost and adaptive reasoning spend as an operational problem: what thinking is, how it shows up in usage, why it multiplies cost vs short answers, when it is worth paying for, and how budgets / effort / max_tokens bound it. Billing rules, model defaults (adaptive vs manual budget_tokens), and seat-plan metering evolve — confirm live behavior in Anthropic’s Thinking and pricing docs. Where list prices appear for orientation (Haiku 4.5 $1/$5, Sonnet 5 $2/$10, Sonnet 4.6 $3/$15, Opus 4.5+ / Opus 5 $5/$25 per MTok in/out), they were checked against Anthropic’s published Claude API pricing on that date. [VERIFY: 2026-09-19]

Not affiliated with Anthropic. Claude Token Optimization is an independent site and audit service. Claude® and related product names are trademarks of Anthropic PBC. Plan prices, model rates, thinking modes, and usage limits change; always confirm on Anthropic’s own docs. [VERIFY: 2026-09-19]

Searches for claude extended thinking cost, reasoning token pricing, and “why did one answer cost so much” usually want the same answer: the model may generate thousands of hidden reasoning tokens before a short final reply — and those tokens are billed like any other output.

This spoke sits under the Optimize hub. Pair it with API pricing, model routing, tool-use costs, and the context window guide. Soft CTA to a written review at the end — no dollar price on this page.

What extended / adaptive thinking is

Without thinking, Claude answers in a single pass: no scratch work, no abandoned approaches, no mid-course correction. For a proof, a tricky bug, or a long agentic task, that first pass is often not the best one.

When thinking is active, Claude works through the problem in internal reasoning blocks before the visible answer. Those blocks arrive as thinking content ahead of text. What you see (if anything) is typically a summary of the reasoning, not the raw chain of thought — controlled by a display setting such as summarized or omitted. [VERIFY: 2026-09-19]

Anthropic’s API currently distinguishes two configuration styles (names and defaults vary by model generation — confirm the per-model table in their Troubleshooting docs): [VERIFY: 2026-09-19]

  • Adaptive thinkingthinking: { type: "adaptive" }. Claude decides whether and how deeply to think. Depth is steered with effort (soft guidance). Preferred on Claude 4.6+ generations and required on many 4.7+ / 5.x models.
  • Manual extended thinking thinking: { type: "enabled", budget_tokens: N }. You set a thinking token budget (minimum 1,024). Still the mode on many Claude 4.5 and earlier thinking models; deprecated on 4.6 (still works); rejected with a 400 on 4.7+ where only adaptive is supported.

For cost control, treat both as the same physics: reasoning tokens are generated, billed, and counted toward output limits — whether you chose a fixed budget or let adaptive + effort decide.

How thinking shows up in usage

The important billing rule, verified against Anthropic’s Thinking docs on 2026-09-19: tokens Claude spends reasoning are billed as output tokens, even when the thinking text is not returned to you. They also count toward max_tokens alongside the visible response. [VERIFY: 2026-09-19]

SignalWhat it meansCost implication
usage.output_tokensAuthoritative total output for the turnIncludes thinking + visible text (and related output)
output_tokens_details.thinking_tokensPortion attributed to internal reasoningSame output $/MTok as the rest of output_tokens
Empty / omitted thinking displaySummary hidden; signature may still round-tripLatency may improve — cost does not disappear
Prior-turn thinking (keep-all models)Earlier thinking blocks retained in contextBilled as input when shown to the model again
Where to look — confirm field names in current API responses.

Two traps that inflate surprise bills:

  1. Visible length ≠ billed length. A three-sentence answer can sit on top of 8k–32k+ thinking tokens. Summarized or omitted display does not erase the charge — Anthropic bills full thinking tokens generated, not the summary you read. [VERIFY: 2026-09-19]
  2. Multi-turn retention. On models that keep prior turns’ thinking (including Opus 4.5+ and Sonnet 4.6+ per Anthropic’s preservation defaults), those blocks re-enter context and are billed as input like other history. Last-turn-only models strip older thinking automatically. See the context window spoke for window pressure. [VERIFY: 2026-09-19]

Why thinking multiplies cost vs short answers

Output tokens are the expensive side of Claude API pricing on every current tier. Orienting rates checked 2026-09-19: Sonnet 5 at $2/$10, Sonnet 4.6 at $3/$15, Opus 4.5+ / Opus 5 at $5/$25, Haiku 4.5 at $1/$5 per million input/output tokens. Thinking rides the output column. [VERIFY: 2026-09-19]

Illustrative (not a quote — your workload will differ). Suppose a Sonnet 4.6 request produces 500 visible answer tokens and 10,000 thinking tokens:

  • Visible-only mental model: 500 × $15 / 1M ≈ $0.0075
  • Actual output bill: 10,500 × $15 / 1M ≈ $0.1575 — about 21× the “short answer” intuition

At Opus output rates the same shape is steeper still. Stack that with tool-use rounds (thinking between tool calls on interleaved / adaptive flows) and one “simple” agent goal can burn what felt like a whole chat session.

Latency compounds the operational cost: deep thinking lengthens time-to-first-text and can push long requests toward timeouts — Anthropic recommends batch processing when thinking budgets push past roughly 32k tokens per request. [VERIFY: 2026-09-19]

When deep thinking is worth it

Pay for thinking when quality failures are more expensive than tokens: proofs, multi-constraint planning, hard debugging, high-stakes analysis, long agentic coding where a wrong first approach burns ten tool rounds. Skip or lower it when the task is retrieval, formatting, classification, short rewrites, or anything a cheaper model without deep reasoning already nails.

WorkloadThinking postureWhy
Hard reasoning / novel bugs / proofsAdaptive + higher effort, or a tuned budgetOne correct pass beats cheap retries
Routine CRUD / summaries / FAQThinking off or low effort / minimum budgetThinking tax with little quality upside
Agent planning stepOften lower-effort or cheaper modelSee model routing before max effort
Final synthesis after toolsSelective deeper thinkingPay once at the end, not every tool hop
Decision heuristic — measure quality and $/task, not vibes.

If you cannot name the failure mode thinking prevents, default lower. Raise effort (or budget) only after a quality gate fails — the same discipline as cutting token usage before buying capacity.

Caps, budgets, and effort

Anthropic separates soft steering from hard ceilings. Verified language from their Thinking / Effort docs: [VERIFY: 2026-09-19]

  • effort — soft guidance on how much work (including thinking depth) the model puts in under adaptive mode. Lower effort first when you want lower cost or latency on a thinking-enabled workload.
  • budget_tokens — target for manual extended thinking (min 1,024; must leave room under max_tokens for the final answer, with interleaved-thinking exceptions). A target, not a perfect meter — actual usage varies; Claude may stop early.
  • max_tokens — strict limit on thinking + visible output for the turn. Use this when you need a hard spend ceiling. Effort alone is not a hard cap.
  • thinking: { type: "disabled" } — where the model allows it (e.g. Sonnet 5 can turn thinking off; some newer models reject disable). Check the per-model table before relying on this. [VERIFY: 2026-09-19]

Practical tuning: start near the minimum budget (or low effort) for simple tasks; raise only when evals show quality lift. Hold budgets / effort stable across cached conversations — changing thinking configuration invalidates prompt-cache breakpoints. [VERIFY: 2026-09-19]

Vs routing to Opus (or Sonnet) without thinking

Deep thinking on Sonnet and “just use Opus” are substitutes only sometimes. Compare cost per finished correct task, not sticker rates:

  • Thinking on a mid-tier model can beat Opus on pure reasoning tasks when the answer quality converges and you avoid Opus’s higher input+output rates on large contexts.
  • Opus without thinking (where disable is allowed) may still win on judgment-heavy writing with short outputs — you pay Opus rates but avoid a 10k thinking surcharge.
  • Haiku / Sonnet routing for triage and easy steps, then escalate — usually beats “max effort everywhere.” Details: model routing.

A common waste pattern from audits: Opus plus high effort / large budgets on every turn of an agent. That stacks the expensive model with expensive reasoning. Prefer cheap planning → expensive synthesis, or adaptive thinking that skips easy turns.

API vs consumer / seat surfaces

On the Claude API (Messages), thinking is an explicit request parameter. You get usage.output_tokens (and often output_tokens_details.thinking_tokens) so you can attribute the surcharge. Pricing is the model’s normal output rate for those tokens — there is no separate “thinking SKU” in the published pricing table checked on 2026-09-19. [VERIFY: 2026-09-19]

On consumer / seat products (claude.ai, Claude Code, Cowork, Pro / Max / Team), deep reasoning still consumes capacity — session and weekly bars (and usage credits when enabled) — but the UI may not break out “thinking tokens” the way the API usage object does. Product surfaces also differ in whether thinking is always on, user- toggled, or model-default. Treat seat burns as the same physics with coarser meters: Settings > Usage plus your own task notes. Confirm current product behavior in Anthropic help docs; do not assume API field names appear in the consumer UI. [VERIFY: 2026-09-19]

If you are deciding seats vs API for thinking-heavy workloads, attribute cost per finished task once you have logs — see API pricing and your seat plan pages — rather than guessing from a single surprising answer.

Monitoring tips

  1. Log output_tokens and thinking_tokens (when present) per request id, model, and feature flag (thinking on/off, effort, budget).
  2. Alert when thinking share of output exceeds a threshold you set (e.g. >70% on a route that should be short-form).
  3. Sample high-cost outliers weekly: was the task hard, or was thinking left on by default?
  4. In agents, attribute thinking per tool round — interleaved thinking can fire between calls. Pair with tool-use cost logging.
  5. After changing effort or budgets, expect a prompt-cache miss on the next request; hold config steady for steady-state cost.
  6. For budgets above ~32k thinking tokens, prefer Batch API to avoid long-connection issues. [VERIFY: 2026-09-19]

When a written audit is the right next step

Self-serve this page when one lever is obvious — for example, thinking is on for FAQ classification and you only need to disable it or lower effort. Hand off when several stack: adaptive thinking at high effort on Opus, uncapped agent loops, and a weekly bar you cannot split between chat vs reasoning vs tools.

A written Claude token audit maps the paste (system prompts, thinking config, one run transcript with usage), ranks drivers, and returns a Monday change list — soft path, no call required. Price lives only on the audit checkout page so it cannot drift across optimize spokes.

Ready when reasoning tokens are eating the week: start the Claude token audit — paste prompts / usage samples, get a written report, leave with a Monday plan.

FAQ

Are thinking tokens billed separately from output?

No separate SKU in the published pricing table checked 2026-09-19: thinking tokens are billed as output tokens at the model’s output rate. Use output_tokens_details.thinking_tokens (when present) to see the share inside output_tokens. [VERIFY: 2026-09-19]

Does hiding thinking (display omitted) save money?

No. Omitted / summarized display can improve latency and UX; Anthropic still bills the full thinking tokens generated. [VERIFY: 2026-09-19]

Is budget_tokens a hard cap?

It is a target for manual extended thinking. Actual usage varies; max_tokens remains the hard ceiling on thinking plus visible output. Prefer adaptive + effort on models where budget_tokens is deprecated or rejected. [VERIFY: 2026-09-19]

Should I always use Opus with max effort?

Usually no. Route easy work to cheaper models or lower effort; reserve Opus + deep thinking for tasks where quality failures dominate. See model routing.

Do prior thinking blocks cost input tokens later?

On keep-all models, yes — retained prior thinking counts as input like other history. On last-turn-only models, older thinking is stripped. Confirm your model’s preservation default. [VERIFY: 2026-09-19]

Is this only for API builders?

No. Seat and product users hit the same token physics through coarser meters. API teams see thinking in usage objects; seat users see unexplained capacity drain when deep reasoning runs often.

Next steps

  1. Confirm whether each production route uses adaptive thinking, manual budgets, or thinking disabled — and what the model defaults are.
  2. Log output_tokens vs thinking_tokens for one week of traffic.
  3. Lower effort / budgets (or disable thinking) on short-form and classification routes.
  4. Compare remaining hard tasks: deeper thinking on Sonnet vs Opus vs a routed cascade — model routing.
  5. Cap agent loops so interleaved thinking cannot run unbounded — tool-use costs.
  6. If several waste patterns stack, paste for a written audit.

Extended thinking is how Claude earns hard answers. The reasoning token bill is how that quality shows up on the invoice — manage it with the same Measure → Attribute → Reduce → Monitor loop as every other optimize spoke.

Keep reading