When a person answers a hard question well, it is usually because they paused and worked through it first. Extended thinking — sometimes called adaptive thinking — gives Claude the same option. Instead of producing an answer in one pass, the model spends part of its response budget reasoning through the problem step by step before committing to a final answer. For enterprise teams, the practical question is not how this works internally, but when it is worth paying for and how to deploy it sensibly.
What extended thinking actually is
In a normal request, Claude reads your prompt and generates a response directly. With extended thinking enabled, the model first produces internal reasoning — working notes, in effect — and then produces the answer informed by that reasoning. You are billed for the reasoning tokens as output, so a "thinking" response costs more than a direct one for the same visible answer.
The payoff is quality on genuinely hard tasks: multi-step analysis, tricky document reconciliation, code with subtle constraints, planning problems where the first plausible answer is often wrong. On easy tasks, the payoff is minimal — the model would have gotten it right anyway, and you have paid for reasoning you did not need.
One important fact for platform planners: extended thinking is a core capability, available on all four platforms — Claude Platform on AWS, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry. Unlike the Batch API or the Files API, you do not need to factor platform gaps into this decision. Whichever cloud you chose, thinking is there.
When it earns its cost — and when it doesn't
A useful mental model: extended thinking buys accuracy on tasks where reasoning depth is the bottleneck. It does not fix missing information, vague instructions, or a task that is simply outside the model's competence.
Good candidates include contract clause comparison across long documents, root-cause analysis of an incident timeline, financial calculations with several dependent steps, and code review where correctness matters more than speed. Poor candidates include classification ("which team should handle this ticket?"), short summarization, formatting and extraction tasks, and anything where you already validate the output mechanically. For those, a fast model such as Claude Haiku 4.5 without thinking is usually the better trade.
Operational considerations
Three things change operationally when you turn thinking on.
Latency. Reasoning takes time. Interactive applications should stream responses so users see progress, and you should decide up front whether your use case tolerates a longer wait. For overnight or queued work, latency barely matters — which makes background workloads a natural home for heavy thinking.
Cost. Thinking tokens are output tokens, and output is the expensive side of the bill (for example, Claude Opus 4.8 lists at $25.00 per million output tokens versus $5.00 for input). Budget for the reasoning, not just the visible answer, and monitor actual token usage rather than estimating from answer length.
Evaluation. Because thinking changes output quality and cost at the same time, treat it as a configuration you test, not a switch you flip. Run your evaluation set with thinking off, then on, and compare quality gain against token cost. Many teams land on a tiered design: thinking off by default, on for a defined class of hard requests.
Designing a sensible policy
Rather than enabling thinking globally, write down which request types get it. A support assistant might answer routine questions directly but engage thinking when a case involves conflicting account records. A document pipeline might extract fields without thinking but reason carefully when validation checks fail on the first pass. This keeps the majority of traffic cheap and fast while reserving deeper reasoning for the minority of requests that need it.
Pair the policy with observability: log whether thinking was enabled per request, the tokens consumed, and downstream quality signals such as human corrections. Over time this tells you whether your "hard request" definition is right — and gives finance a defensible answer for why some requests cost more than others.
Where to go next
Extended thinking pairs naturally with model choice — see cutting costs with model tiering for routing easy work to cheaper models, and evaluating LLM features for measuring whether thinking actually improves your outputs. The feature matrix shows what else is available on each platform.