How does extended thinking differ from asking follow-up questions across multiple turns to guide the model?
The two produce similar effects (both give the model more room to clarify a problem), but they work differently. Multi-turn follow-up is the user actively intervening, guiding the model step by step toward the right direction through conversation. Extended thinking is the model doing a round of internal reasoning and self-checking within a single response, without needing user intervention.
When the user already knows exactly how the problem should be broken down, multi-turn follow-up may be more precise (since a human is steering the direction). But if the user themselves isn't sure how to break the problem down, letting the model attempt that breakdown itself via extended thinking can actually be more efficient, since it avoids several rounds of back-and-forth to find the right direction.
If extended thinking is on, does that guarantee Claude won't make mistakes?
No. What extended thinking reduces is the likelihood of multi-step cascading errors, not the possibility of all errors. If a task involves current information the model's training data doesn't cover (like real-time stock prices or the latest regulations), no amount of extended thinking can produce information the model simply doesn't have. If the problem description itself is ambiguous or contradictory, extended thinking might just "rationalize" that ambiguity more thoroughly, making a wrong answer sound more convincing.
Extended thinking addresses the rigor of the reasoning process, not the accuracy or completeness of the underlying information—these are two separate issues, and turning on the feature alone shouldn't be assumed to guarantee a foolproof result.
Roughly how much does extended thinking cost in compute, and is there a way to estimate it?
Extended thinking's cost is directly tied to how many tokens the model's internal reasoning process consumes—the more complex the task and the more reasoning steps required, the more tokens get used, which typically shows up in billing. There's no universal fixed multiplier, since the reasoning depth needed varies significantly by task—a simple logical judgment might add very little, while a complex multi-step proof could add substantially more.
A more reliable practical approach is to test a representative sample task both with and without extended thinking, comparing actual token consumption and response quality, then deciding whether it's worth enabling broadly for a similar batch of tasks—rather than applying it to everything based on a hunch.
If I'm not sure whether to turn it on, is there a middle-ground approach?
A few compromise approaches: First, run the task once in standard mode without extended thinking—if the answer looks logically disjointed or skips an obvious condition, rerun that specific request with extended thinking enabled, rather than turning it on across the board from the start. Second, if the task is a recurring, fixed type (like running a similar multi-step analysis every day), invest in an A/B test once to compare the actual difference between the two modes, then set your default strategy for that type of task going forward. Third, split the task apart—if only a few steps within a larger task genuinely need deep reasoning, enable it only for those steps and keep the rest in standard mode, which is more cost-effective than enabling it for the entire task throughout.
Claude has a feature called extended thinking. When enabled, the model spends time doing internal reasoning before producing a final answer—breaking down the problem, checking its own logic, ruling out wrong paths—before responding. It sounds like a feature you can't lose by turning on—more thinking time should mean a more accurate answer, right? But the reality is more nuanced: using it in the wrong place just slows things down and adds cost without a meaningful accuracy gain.
Extended thinking is particularly helpful for tasks that require multi-step reasoning where a single misstep in any part can throw off the entire final answer—complex mathematical proofs, logic puzzles requiring cross-referencing multiple conditions, or debugging involving many interacting variables. What these tasks have in common is that a single miscalculation or overlooked condition anywhere along the way can derail the entire outcome, and the "think before answering" space extended thinking provides noticeably reduces the odds of that kind of cascading error.
If a question already has a clear-cut answer and doesn't require multi-step reasoning—looking up a factual detail, a simple format conversion, or directly following an explicit instruction—the accuracy gain from extended thinking is minimal, while response time and compute cost still go up in practice. The bottleneck for these tasks was never "not enough thinking time"—it's whether the model has the right context and clear instructions. Extended thinking can't fix a lack of information.
A simple test: ask yourself, "If a human expert were doing this, would they need to work it out on paper, listing intermediate steps?" If yes (like deriving a complex formula), extended thinking is usually worth turning on. If no (like looking up a definition or translating a passage), extended thinking is likely just spending extra time for little gain. Another signal: if you notice that without extended thinking, Claude frequently skips a condition midway through a multi-step task or produces logically disjointed answers, that's a clear sign it's time to turn it on.
Extended thinking genuinely consumes more tokens and lengthens response time. If you're using Claude heavily via the API or a usage-based plan, blanket-enabling extended thinking for everything adds up to meaningful extra cost over time without a guaranteed corresponding accuracy gain. The more cost-effective approach is to assess task type first, enabling it only when multi-step reasoning is genuinely needed, and keeping simple, direct tasks on standard mode—striking a better balance between accuracy and cost.