What extended thinking actually is
Extended thinking is Claude working through a problem in its own words before it writes the answer you see. It restates the question, tries an approach, checks the intermediate result, and drops paths that do not hold up. Anthropic's thinking overview describes it that way, and it also states the part most people miss: those reasoning tokens are billed as output tokens even when the thinking text is never shown to you, and they count toward the response length cap.
So thinking is a second pass that costs tokens and time. The question is when that second pass earns its cost and when it just makes you wait longer for the same answer.
One naming note. In the Claude apps the switch is labelled "Thinking" or "Extended" depending on the model. In the API, "extended thinking" now means the older manual mode with a fixed token budget, and the current mode is called adaptive thinking. Same idea, different plumbing.
How to turn it on in September 2026
In the Claude apps
The toggle lives in the model menu next to the send button. Anthropic's support article puts it plainly: for models with effort levels, mouse over "Effort" and switch the "Thinking" toggle on or off; for other models, switch the "Extended" toggle.
Two things worth knowing. First, on Claude Fable 5.1 and Claude Opus 5, thinking cannot be turned off in the app at all. It is always on, and the effort selector (Low, Medium, High, Extra high, Max) controls how much of it you get. Second, this is not a paid-only feature. The claude.com pricing page lists "Extended thinking for complex work" on the Free plan, so the difference between plans is how much you can use, not whether you have it.
In the API
On current models the control is adaptive thinking. Per the thinking docs, thinking is on by default with no configuration on Claude Opus 5, Claude Sonnet 5, and Claude Fable 5.1. On Claude Opus 4.8, 4.7, 4.6 and Claude Sonnet 4.6, it is off until you send thinking: {"type": "adaptive"}. Depth is then controlled by output_config.effort, which takes low, medium, high, xhigh, or max and defaults to high. The effort page is explicit that effort is a behavioral signal, not a strict token budget.
The older manual mode, thinking: {"type": "enabled", "budget_tokens": N}, still exists but is on its way out. The extended thinking page says it is deprecated on the 4.6 models and returns a 400 error on Claude 4.7 and later. If you are on a model that still accepts it, the rules are: minimum 1,024 tokens, the budget must be smaller than max_tokens, and the budget is a target rather than a hard cap. The doc suggests starting near 1,024 for simple tasks and at 16,000 or more for complex ones.
What it costs
Thinking tokens are output tokens. On the current price list, Claude Sonnet 5 output is $10 per million tokens and Claude Opus 5 output is $25 per million, so a response that thinks for 8,000 tokens before writing a 500-token answer costs you the 8,500, not the 500. The steering thinking page adds that you are billed for the full internal reasoning whether you see a summary of it or hide it entirely, and usage.output_tokens_details.thinking_tokens in the response tells you how much of the output was reasoning. My post on reducing AI token costs covers the other levers.
Tasks where thinking pays for itself
My list has stayed short. These are the shapes where thinking changed the answer I got, not just the wait.
Multi-step math and logic. Anything where step four depends on step two being right: margin calculations across three pricing tiers with a discount schedule, date arithmetic across time zones and fiscal quarters. A single-pass answer has no scratch paper. Thinking is the scratch paper.
Ambiguous trade-off decisions. "Should I hire a contractor or a full-time person for this role given these constraints." A model that lays the criteria out, tests each option against them, and notices a conflict does noticeably better than one that pattern-matches to the most common advice.
Code with hidden constraints. Not "write a function that sorts a list." More like "fix this bug without changing the public interface, and it has to keep working on the old database schema too." The constraints interact, and the first fix that comes to mind usually violates one of them. Thinking is where that gets caught before you see the code.
Long-document reconciliation. Two versions of a contract. A quote against an invoice. A spec against the implementation notes. Finding every place they disagree means holding a lot in working memory and cross-checking systematically. This is where I see the biggest gap between thinking on and off.
The common thread: the answer depends on intermediate work that would otherwise be skipped or compressed.
Tasks where it wastes tokens
A shorter list, and I am stricter about it because this is where the money leaks.
Rewrites and edits. "Make this email friendlier." "Cut this to 150 words." There is nothing to reason about. Thinking adds latency and a bill, and the output is the same or slightly stiffer.
Formatting and conversion. JSON to a table, bullet points to prose, a messy paste into clean rows. Mechanical work with no decision in it.
Short factual answers. "What is the capital gains threshold in Ireland." Deliberating does not create knowledge the model does not have. If the answer needs verifying, web search does that, not thinking.
Brainstorming for volume. Fifty headline options. Twenty names for a product. You want breadth and speed, and thinking converges instead of diverging. You get fewer, better-justified options when you wanted a big pile to react to.
Adaptive thinking skips reasoning on easy inputs at lower effort. The steering page describes medium as "may skip thinking for simple queries" and low as "minimizes thinking," but at the default high, Claude "almost always thinks." Feed it rewrites all day at the default and you are paying for reasoning about nothing.
My decision rule
Before I switch it on, I ask one question: if a sharp colleague handed me this answer in thirty seconds, would I trust it, or would I want them to go away and check?
If I would trust the thirty-second answer, thinking is off (or effort is low). If I would want the check, thinking is on. Two refinements: if being wrong costs more than waiting an extra minute, thinking is on regardless; and if I am about to ask the same question three ways to be sure, that is a signal to ask once with thinking on instead.
How to prompt differently when thinking is on
This is where most of the benefit is lost. People turn thinking on and keep prompting the way they did before, so the model reasons hard about a vague question and returns a thorough answer to the wrong thing.
Four changes I make.
State the success criteria. Not "review this plan" but "review this plan against these three criteria, in this priority order." Thinking is a search process. Criteria are what it searches against. Without them it invents its own, and they will not be yours.
State the constraints explicitly, including the boring ones. Budget, deadline, things that cannot change, people who have to sign off. Every constraint you leave out is one the model cannot reason about, and the fix it proposes will step on it.
Ask for a decision, not a survey. "Give me the options" produces a balanced list. "Pick one and defend it" produces reasoning. If you want the alternatives, ask for the decision first and the rejected options second with the reason each was rejected.
Ask for the assumption most likely to be wrong. My favorite single line. It forces the model to find the weakest link in its own chain, which is what you would do with a human analyst's memo, and the flagged assumption is usually the thing I needed to go verify anyway.
One more, from Anthropic's own prompting guidance: prefer general instructions over prescriptive steps. Their wording is that "think thoroughly" often produces better reasoning than a hand-written step-by-step plan, because the model's reasoning frequently exceeds what a human would prescribe. I resisted this, tested it on my own work, and they are right. Give it the goal and the constraints, not the recipe.
"Think step by step" versus real thinking
A prefix like "think step by step" or ULTRATHINK is an instruction inside your prompt. Extended thinking is a setting on the request. How they interact depends on whether thinking is on.
When thinking is off, a step-by-step instruction is the fallback, and Anthropic's guidance lists manual chain-of-thought prompting exactly that way. It helps. It is also weaker than the real thing, because the model reasons and writes the answer in one pass, in public, with no room to abandon a bad path.
When thinking is on, the same phrases become steering. The steering page documents this directly: appending "Please think hard before responding." to a message encourages thinking on that turn, and "Answer directly without deliberating." suppresses it. It also warns that this is wording-sensitive and that lowering effort is the more reliable lever. So a prefix on a thinking-enabled model is a nudge on top of a real mechanism: useful for the one hard turn in a routine conversation, not a replacement for choosing the right effort level. I go deeper on the prefix side in the ULTRATHINK post.
Model choice matters too; my Opus versus Sonnet guide covers when thinking on a smaller model beats no thinking on a larger one.
Four prompts built for thinking mode
Each assumes thinking is on and effort is at least high.
1. The trade-off decision
I need to decide between two options. Think carefully before answering.
Decision: [one sentence, e.g. "whether to move our invoicing to a new tool this quarter or wait until next year"]
Option A: [describe]
Option B: [describe]
Success criteria, in priority order:
1. [most important, e.g. "no disruption to customers during the switch"]
2. [second]
3. [third]
Hard constraints (cannot change): [budget cap, deadline, people or systems that must keep working, approvals needed]
Context you should know: [paste relevant background, 3 to 10 lines]
Give me:
- Your recommendation, one option, stated in the first line.
- The reasoning, tied explicitly to the criteria above in order.
- The single assumption in your reasoning most likely to be wrong, and what I should check to confirm it.
- What would have to be true for the other option to win.
2. Reconciling two long documents
Compare the two documents below and find every place they disagree. Take your time and be systematic. Precision matters more than speed here.
Document 1 ([name, e.g. "signed contract dated 12 May"]):
[paste]
Document 2 ([name, e.g. "supplier invoice INV-2291"]):
[paste]
Rules:
- Only report actual differences in meaning, amounts, dates, names, or obligations. Ignore formatting and wording differences that do not change the meaning.
- Quote the exact text from each document for every difference.
- Rank differences by how much money or risk is attached, largest first.
- If something appears in one document and is missing from the other, list it separately under "Present in one only."
- End with the one difference you are least sure about and why.
3. Fixing code with hidden constraints
Fix the bug described below. Before writing any code, reason through which constraints your fix could violate.
Bug: [describe the observed behavior and the expected behavior]
Code:
[paste the relevant function or file]
Constraints your fix must respect:
- Public function signatures and return types cannot change.
- [e.g. "Must still work with the old database schema where the column is nullable"]
- [e.g. "No new dependencies"]
- [e.g. "Must not break the existing tests in test_orders.py"]
Deliver:
1. The root cause in two sentences.
2. The fix as a minimal diff, with nothing changed that does not need to change.
3. Which constraint your fix came closest to violating and how you avoided it.
4. One test case I should add that would have caught this bug.
4. Multi-step numbers with self-verification
Work through this calculation carefully, then verify your own result a second way before you give me the final number.
Question: [e.g. "What is our blended gross margin next quarter if we move 30% of customers from the Basic tier to Pro?"]
Inputs:
- [e.g. "Basic: 400 customers at 29/month, cost to serve 11/month"]
- [e.g. "Pro: 150 customers at 79/month, cost to serve 24/month"]
- [any other numbers, one per line, with units]
Assumptions you may make: [e.g. "no churn during the move, prices unchanged"]
Assumptions you may not make: [e.g. "do not assume cost to serve changes with volume"]
Show:
- The calculation step by step with each intermediate figure labelled.
- The final answer on its own line.
- A second, independent way of arriving at the same figure, and confirm the two match. If they do not match, say so and explain which one you trust and why.
- Which single input, if I got it wrong by 10%, would move the answer the most.
If you want more patterns in this shape, the ones above are adapted from the reasoning section of the Claude Cheat Sheet, 120 prompt patterns with worked examples and notes on when each one does nothing, $19 once, two free samples on the page.
The short version
Turn thinking on when the answer depends on intermediate work: multi-step numbers, trade-offs with real constraints, code with interacting requirements, documents that need cross-checking. Leave it off, or drop effort to low, for rewrites, formatting, quick facts, and volume brainstorming.
If you are still working out how the pieces of Claude fit together, start with the free 75-page Claude guide, which covers thinking mode alongside the rest of the setup with no card required. When you are ready for prompt patterns you can paste straight into your work, the Cheat Sheet picks up where the guide leaves off.