Extended thinking doesn't always improve the answer — on simple tasks it just adds latency and cost. The real skill is knowing when to turn it on and how deep.
Extended thinking lets Claude generate an internal reasoning chain — `thinking`-type blocks — before producing the final visible response. In current models (Opus 4.6 family onward, Sonnet 5) the recommended mode is adaptive reasoning (`thinking: {type: "adaptive"}`), where the model itself decides how much and when to reason based on the complexity it detects in the task, instead of the developer setting a reasoning token budget upfront.
The complementary parameter is `effort`, inside `output_config`, with levels from low to max (including `xhigh` on the most recent models). It controls reasoning depth and total token spend; combined with adaptive reasoning it gives the best cost-quality balance for most cases.
An important detail: by default, the `thinking` field on these blocks comes empty (`display: "omitted"`) — if your product needs to show the reasoning to the user (for example, for transparency in a financial-analysis tool), you need to explicitly set `display: "summarized"`.
The question to ask isn't "is this task hard" in the abstract, but "does the most likely error come from insufficient reasoning or from missing information?" Extended thinking helps when the task requires multiple chained logic steps where an early error propagates — debugging a bug with a non-obvious cause, planning a migration with cross-cutting dependencies, solving math or algorithmic problems, or the planning phase of an agent that must decide a sequence of tool actions.
It doesn't help, and can actually hurt latency, on simple classification tasks, structured data extraction with a clear format, low-risk content generation, or any task where the correct answer doesn't depend on chaining several logic steps but on applying a direct pattern.
It's tempting to treat `effort: "max"` as the safe default, but in practice the `high` level is frequently the optimal point: higher levels can show diminishing returns and, in some cases, over-analyze problems that don't need it. The operational recommendation is to start at `high` as a baseline, measure on your own evaluation set, and adjust per path: `xhigh` for the most demanding coding and agentic tasks, `medium` when cost is a real constraint, and `low` for subagents or routine steps within a larger flow.
A frequent production pattern is varying effort by subtask type within the same agent: the initial planning phase with `effort: "high"`, and routine execution steps delegated to subagents with `effort: "low"` — this reduces total spend without sacrificing quality on the step that actually needs it.
For long-running agentic flows (many chained tool calls), there's also the concept of a "task budget" — a token ceiling the model is aware of throughout the entire execution, distinct from `max_tokens` (which is a hard per-response limit the model has no notion of). With a task budget, the model sees a countdown and prioritizes work to finish in an orderly way instead of getting stuck mid-task when the budget runs out.
This is particularly useful in long-running autonomous agents where you want to cap spend without necessarily knowing in advance how many steps it'll take to solve the task.
As with any parameter that affects cost and latency, empirical validation on your own set of cases is worth more than intuition. The recommended practice is to run a sweep of effort levels (low, medium, high) over a representative sample of your real queries, and pick the level based on the quality-latency-cost relationship observed for your specific domain — not based on what worked well in a different use case. For tasks where latency is critical and visible to the user (interactive chat), this measurement should include real perceived time, not just token count, because adaptive reasoning can add several seconds of wait before the first visible response token if you don't configure streaming with a thinking summary.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel