Extended Thinking: Controlling Claude's Reasoning Effort on Purpose

1. What Extended Thinking technically does

Extended Thinking is a separate output channel in which Claude formulates a structured reasoning process before the actual answer: checking assumptions, weighing alternatives, discarding or pursuing intermediate results. This thinking text is not a marketing gimmick but a genuine part of inference. The model uses the additional tokens to play out several solution paths in context before the final answer, instead of committing to the first plausible path immediately.

For developers, what matters is that the thinking text is separate from the final answer and handled differently depending on the client. In Claude Code it appears as a collapsible block before the actual answer, in the API as its own thinking content element next to the text element. Anyone who wants to follow the reasoning steps, for example to understand why a particular solution path was discarded, can expand them deliberately instead of treating them as a black-box delay.

// Excerpt from an API response with Extended Thinking
{
  "content": [
    {
      "type": "thinking",
      "thinking": "The bug only occurs on concurrent requests. That points to a race condition on the cache access. Let me check first whether the read-modify-write cycle is atomic..."
    },
    {
      "type": "text",
      "text": "The root cause is a missing lock on the cache access..."
    }
  ]
}

2. When a higher reasoning effort pays off

A higher reasoning effort pays off above all on tasks where several plausible but differently good solution paths exist and a wrong choice gets expensive. Classic examples are architecture decisions with several viable options, say choosing between event sourcing and a classic CRUD structure for a new module, or debugging tricky bugs where the cause is not obvious and several hypotheses need to be weighed against each other.

The effect also shows clearly on migration planning, complex concurrency, or analyzing performance regressions in distributed systems: the model visibly discards clearly wrong approaches during the thinking phase before they end up in the answer. That reduces the number of iterations a developer would otherwise have to go through themselves after a first, too-quickly-formulated answer turns out to be a dead end.

# Claude Code: request a high reasoning effort for a complex task
claude "Analyze why our checkout intermittently duplicates orders \
  under load (200 req/s). Use extended thinking with a high \
  effort, check idempotency, retries, and database locks."

3. When high effort just costs time and tokens

On simple, clearly scoped tasks a high reasoning effort brings barely any measurable benefit but noticeably lengthens the response time and increases token consumption. A simple CRUD task like adding a new repository endpoint following an already established pattern in the project does not need minutes of weighing several solution paths, because the solution path is already dictated by the existing codebase. Here the team just pays for extra thinking steps that deliver no new insight.

On tasks with a clearly correct, mechanical answer too, such as formatting a file, renaming a variable across several files, or filling in a known boilerplate pattern, high effort is wasted budget. In interactive sessions with many small requests in a row, this delay adds up quickly to noticeable wait time without the quality of the answers improving measurably.

4. The thinking budget: tokens, time, and cost together

Technically, Extended Thinking is controlled through a token budget available to the model for the reasoning process. A larger budget allows more intermediate steps, more discarded approaches, and more explicit self-correction, but costs proportionally more compute time and more tokens, which count toward billing exactly like the visible answer. A budget that is set too tight can cut the reasoning process off mid-deliberation, which noticeably degrades the quality of the final answer.

In practice, a tiered approach pays off: low or no thinking budget as the default for everyday development work, a medium budget for tasks with several solution paths, and a high budget reserved for the few tasks per week where a wrong decision would get expensive. This tiering shows up directly in cost, which is why teams with high request volume should deliberately fix the effort tier per task type instead of leaving it to chance in each session.

5. Controlling reasoning effort in Claude Code in practice

In Claude Code, reasoning effort can be influenced through model choice and through explicit hints in the prompt. A simple addition like think hard or think longer in the prompt signals to the model that a larger thinking budget is appropriate, while a short, direct prompt without such hints triggers the default behavior with lower effort. For recurring task types, it pays off to capture these phrasings as a team convention instead of reinventing them for every request.

In addition, the choice of model itself influences the sensible effort range: a larger model with high reasoning effort is meant for rare, critical architecture questions, while a faster, smaller model with low effort remains the better choice for the many small everyday intermediate steps, such as writing a single test. This combination of model choice and effort hint is the actual lever, not a single global switch.

# Low effort: quick, mechanical task without a thinking-budget hint
claude "Rename the variable userDta to userData, project-wide."

# Higher effort: explicit hint for an architecture decision
claude "Think hard: should we use read replicas for the new \
  reporting module or build a separate event stream instead? \
  Weigh consistency, operational overhead, and latency."

6. The thinking parameter in the API in detail

Anyone calling the Claude API directly instead of using Claude Code controls Extended Thinking through an explicit parameter in the request that sets a token budget for the reasoning process. This budget must be understood as separate from the regular max_tokens limit of the answer and needs to be planned for separately in a cost model, because thinking tokens and answer tokens are billed separately. For automated pipelines, say a CI step that evaluates commit messages, a deliberately low budget pays off because the task is repetitive and mechanical.

For agentic workflows that independently call several tools in sequence and need to evaluate intermediate results, a higher budget is often justified instead, because wrong decisions in an early phase otherwise propagate through several subsequent tool calls. It is important not to set the budget statically for the whole application but to parameterize it per task type, for example through a configuration file that maps different endpoints to different effort tiers.

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-opus-4-6",
    max_tokens=4096,
    thinking={"type": "enabled", "budget_tokens": 8000},
    messages=[{
        "role": "user",
        "content": "Design a migration strategy for moving from a "
                    "monolithic order pipeline to an event-driven "
                    "architecture with Kafka.",
    }],
)

for block in response.content:
    if block.type == "thinking":
        print("Reasoning:", block.thinking[:200], "...")
    elif block.type == "text":
        print("Answer:", block.text)

7. Practical example: tracking down a race condition with Extended Thinking

A realistic example from everyday development: a team reports that occasional duplicate payment bookings occur under load, even though the code looks idempotent at first glance. Without Extended Thinking, Claude often delivers a plausible but too shallow first guess, say a missing unique index. With high reasoning effort, the model systematically works through several hypotheses in the visible thinking process: missing transaction boundaries, an overly generous retry mechanism in the payment gateway, and a race between two worker processes reading the same idempotency key at the same time.

In the visible thinking text, it is possible to follow which hypothesis was discarded for which reason, for example because the database log shows no parallel writes in the relevant time window. This traceability is the actual value over a black-box answer: an experienced developer can specifically check and correct the reasoning instead of accepting a wrong answer unchecked or discarding a correct answer out of distrust.

8. Common antipatterns in effort control

The most common antipattern is setting a project to maximum reasoning effort across the board, on the assumption that more thinking surely cannot hurt. In practice this leads to noticeably longer wait times on trivial requests and a bloated token budget that shows up in the bill at the end of the month, without response quality actually benefiting on most tasks. The second common antipattern is the exact opposite: disabling reasoning effort entirely, even for the rare, truly critical decisions, just to keep the team convention simple.

A third, more subtle antipattern is requesting the thinking text but never reading it. If nobody on the team reviews the visible reasoning steps, the actual benefit of Extended Thinking is lost, namely the chance to spot a questionable chain of reasoning before it lands in production code. The thinking text should be treated as part of the code review on critical decisions, not as optional extra that gets clicked away unread.

9. Team conventions for handling reasoning effort

Teams that use Claude Code regularly benefit from a short, documented convention on which task types justify which effort level. Such a convention can be captured directly in the project-wide CLAUDE.md, so that every team member and every automated call uses the same basis instead of deciding the question anew for each individual request. That reduces not only cost but also the spread in answer quality across different developers on the same project.

A three-tier split works well: default effort for everyday tasks like refactoring following a known pattern, medium effort for tasks with several equally valid options, and high effort reserved for architecture decisions, security analysis, and debugging production-critical failures. This split should be reviewed regularly, because both the capabilities of the models and the requirements of a growing project change over time.

10. Summary

11. FAQ: Extended Thinking and Reasoning Effort: The Essentials