Extended Thinking / Reasoning

The internal reasoning models perform before output — structurally load-bearing for complex autonomous work, expensive to serve, and contested when providers reduce it.

Also known as: extended thinking / thinking tokens / thinking depth, extended thinking, thinking tokens, thinking depth, reasoning models, chain-of-thought, redact-thinking / thinking redaction

How authors use it

Oldest first (extraction date when no publication date is known).

AuthorTheir termTheir meaning
Claude Code: Best practices for agentic coding
anthropic.com · 2025-04-18
extended thinkingA mode giving Claude additional computation time to evaluate alternatives, triggered by escalating keywords 'think' < 'think hard' < 'think harder' < 'ultrathink' that map directly to progressively larger thinking-budget allocations
[MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates #42796
stellaraccident (via https://github.com/anthropics/) · 2026-04-02
extended thinking / thinking tokens / thinking depthThe internal chain-of-thought reasoning the model performs before producing output; measured via content length or signature-length proxy. The report treats this as the causal mechanism for output quality.
[MODEL] Claude Code is unusable for complex engineering tasks with the Feb updates #42796
stellaraccident (via https://github.com/anthropics/) · 2026-04-02
redact-thinking / thinking redactionAnthropic's staged deployment (Feb 12 onward) that hid thinking content from users, making it impossible to externally verify thinking depth. The report distinguishes between redaction (hiding) and reduction (actual decrease in thinking tokens).
Guest post: AI Inference Is Breaking Unit Economics
Turing Post · 2026-05-07
reasoning modelsModels that perform extended chain-of-thought or multi-step reasoning, consuming an order of magnitude more compute per query than standard models

Documents (8)

Propositions touching this concept (19)

By publication month, oldest first (extraction month when no publication date is known).

2024-10

2025-04

2026-03

2026-04

2026-05

2026-07

2026-09

Tensions

Is the model a swappable, commoditized component (so selection is a cost decision), or is model choice load-bearing (so selection is a capability decision)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: Both camps are right about different task strata, and the tie is broken by the routing camp's own artifact. Commoditization holds on the bulk/background tier (musistudio and the Pragmatic Engineer are correct that a cheap or open model suffices for a large share of tokens), but model choice is load-bearing exactly on the hard tier — the 'hardest 40%' the routing camp routes AWAY (the Pragmatic Engineer's own gap notes 60%-of-token-spend is not 60%-of-value). nrehiew's 6.5x over-editing spread and stellaraccident's collapse are measured on precisely that hard tier. The clincher the swap camp does not concede: musistudio's OWN per-model transformers (tooluse, enhancetool, reasoning, deepseek, gemini) prove the harness is NOT model-agnostic — every model needs bespoke request/response rewriting just to work behind Claude Code, so the 'any model' artifact self-refutes. Delangue even concedes the frontier gap himself. Verdict: select cheap-and-swappable for bulk, and treat the model as a load-bearing capability decision for the hardest slice — the two positions are not competitors but a partition of the task distribution.
Effort/reasoning: does more thinking make output better, or does more reasoning make it worse (over-engineering / over-editing)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: This looks like a head-on collision but is really the corpus resolving a category error, so I keep it as a divergence-under-adjudication rather than a live two-camp fight. The two things bundled into one 'effort' dial are separable: reasoning DEPTH (deliberation and research before acting — what stellaraccident measures as the Read:Edit ratio) versus action SCOPE (how much the model rewrites — what nrehiew measures as over-editing). They are separable but DEFAULT-COUPLED: more reasoning, unconstrained, tends to produce more scope. nrehiew is the empirical bridge — constrained reasoning models are the MOST faithful, proving depth and tight scope combine positively when you address them separately. Fable 5 already acts on this, pairing 'reduce effort' with a distinct anti-over-engineering instruction. The actionable verdict: do NOT cut reasoning depth to fix over-editing (that is stellaraccident's exact grievance and it backfires into shallow, edit-first behavior); keep the depth and add an explicit scope constraint. The failure is treating one knob as if it controls both correctness-depth and edit-scope.
Who selects the model/effort/context — a human deciding per task, or an automatic router — and who is trusted to hold the dial?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: The human-vs-auto axis is less about capability than about (a) whether task difficulty can be detected a priori and (b) who bears the principal-agent risk. No router in the corpus actually measures difficulty — musistudio routes by token-count and static scenario, and the Pragmatic Engineer's routers infer 'good enough' without a demonstrated oracle — so 'auto' today means 'static-heuristic', not 'optimal'. Automation is safe when the user owns the policy (musistudio) and dangerous when the router profits from the choice (Cursor Auto) or when the provider adjusts the dial invisibly (stellaraccident). Verdict: keep the human holding the difficulty judgment and the effort dial until routers can both measure adequacy and prove neutral incentives; automate only the mechanical dispatch, over rules you own and can audit.

Open gaps (23)