Claude Code Extended Thinking in Agentic Loops: When to Turn It On and What It Costs You

Most cost overruns in Claude Code sessions stem from a single misunderstood setting: extended thinking enabled by default across all loop types. Engineers enable it for the first complex refactor, forget it's on, then wonder why a 300-turn code review session just burned through $80 in API credits. The problem is not that extended thinking lacks value—it's that teams apply it uniformly when different agentic loop types demand radically different strategies.

Extended thinking adds 5-15 seconds of model deliberation before each response, sending additional internal reasoning tokens you pay for but never see. In a fresh 10-turn session this overhead barely registers. In a 200-turn session with full conversation history re-sent every turn, that hidden tax compounds into the dominant cost factor. The session still delivers correct code, but you just paid 3-4x what a selective approach would have cost.

flowchart LR
    A("Start agentic session") --> B("Enable extended thinking")
    B --> C("Run 200-turn refactor loop")
    C --> D("Hidden reasoning tokens compound")
    D --> E("Session costs 3-4x baseline")
    style E stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7

The correct pattern toggles extended thinking per task complexity, not per session. Simple CRUD generation runs in standard mode. Multi-file refactors with type propagation enable it. Test auto-fix loops use it only when the first attempt fails. This granular control cuts median session costs by 60% while preserving output quality on the tasks that actually need deep reasoning.

flowchart LR
    A("Start agentic session") --> B("Task complexity check")
    B --> C("Simple CRUD: standard mode")
    B --> D("Complex refactor: extended thinking")
    C --> E("60% cost reduction maintained")
    D --> E
    style E stroke:#34d399,fill:#0b3b2e,color:#d1fae5

That covers the core tension. Now the mechanics.

Key Takeaways

• Extended thinking adds 5-15 seconds and hidden reasoning tokens per turn, compounding severely in 200+ turn sessions where full history re-sends every message.
• Different agentic loop types (generation, refactor, test-fix, review) have wildly different extended thinking ROI—simple CRUD needs none, multi-file refactors justify the cost.
• Toggling extended thinking per task type instead of leaving it on by default cuts median session costs by 60% with no quality loss on routine tasks.
• The cost math is non-linear: turn 50 in a session costs more than turn 5 because context window grows, so extended thinking overhead scales with session length.
• Interleaved thinking mode (chunks of standard + extended turns) balances cost and correctness better than always-on or always-off for medium-complexity loops.

What Extended Thinking Actually Does in Agentic Loops

Extended thinking is a model-level feature that adds an internal deliberation phase before the assistant generates its visible response. The model receives the prompt, spends 5-15 seconds reasoning through edge cases and constraints in a hidden scratchpad, then produces the final answer using those conclusions. Developers never see the scratchpad tokens, but they pay for them in the API bill.

In agentic loops—where Claude Code runs multi-turn sessions to generate, refactor, test, or review code—extended thinking changes the failure modes. A standard-mode loop that misses a type constraint on turn 12 will produce broken code and require a correction turn. An extended-thinking loop often catches that constraint during internal reasoning and ships correct code on the first attempt. The tradeoff is immediate: one fewer turn, but higher per-turn cost.

The value equation depends entirely on loop length and task complexity. A 5-turn simple component generation loop gains nothing from extended thinking because the model rarely needs course correction on trivial tasks. A 150-turn refactor loop that touches 40 files gains significantly because avoiding even three correction turns saves more tokens than the extended thinking overhead cost.

flowchart TD
    A("User prompt arrives") --> B("Extended thinking enabled?")
    B -->|Yes| C("Model enters deliberation phase")
    B -->|No| D("Model generates response immediately")
    C --> E("Hidden scratchpad reasoning")
    E --> F("Conclusions feed final response")
    D --> G("Response sent to user")
    F --> G
    G --> H("Agentic loop continues or ends")
    style C stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px
    style E stroke:#7c9cf0,fill:#142544,color:#eaf2ff

The implication here is that extended thinking is not a quality toggle—it's a token allocation strategy. Developers who enable it globally are betting that the model's internal reasoning will save more correction turns than it costs in overhead. That bet wins on complex tasks and loses on simple ones. The failure mode is treating it as a default-on setting instead of a precision tool.

The 4 Loop Types and Where Extended Thinking Fits

Agentic loops fall into four categories, each with a different extended thinking profile. The distinction is critical because the cost-benefit ratio shifts dramatically between them.

Generation loops create new code from a spec. These are typically 5-20 turns: requirements clarification, initial implementation, linting fixes, maybe one refactor pass. Extended thinking rarely pays off here because the model handles routine CRUD generation well in standard mode, and the short session length means correction turns cost less than the extended thinking overhead would.

Refactor loops modify existing code across multiple files, often with type propagation and dependency updates. These run 50-300 turns in production codebases. Extended thinking becomes valuable around the 100-turn mark because multi-file refactors have high correction costs—a missed type update on turn 80 can cascade into 10 correction turns as the model fixes downstream errors. The hidden reasoning catches these cascades before they ship.

Test-fix loops generate tests, run them, read failures, and fix bugs until all tests pass. These are hybrid: the initial test generation is simple (no extended thinking), but the fix phase often needs it. A test failure that reveals a subtle async race condition benefits from extended thinking on the fix turn, while a simple typo fix does not.

Review loops analyze code for issues and suggest improvements. These are read-heavy with sparse edits, so extended thinking overhead dominates. Most review comments come from pattern matching ("this variable name violates convention"), not deep reasoning. Extended thinking should stay off unless the review is checking formal correctness properties like "does this state machine have unreachable states?"

%% alt: Four agentic loop types with extended thinking recommendations
flowchart LR
    subgraph Generation["Generation Loops (5-20 turns)"]
        A("CRUD from spec")
    end
    subgraph Refactor["Refactor Loops (50-300 turns)"]
        B("Multi-file type propagation")
    end
    subgraph TestFix["Test-Fix Loops (hybrid)"]
        C("Simple: standard mode")
        D("Complex fix: extended thinking")
    end
    subgraph Review["Review Loops (read-heavy)"]
        E("Pattern checks: standard mode")
    end
    
    A --> F("Extended thinking: OFF")
    B --> G("Extended thinking: ON after turn 100")
    C --> F
    D --> G
    E --> F
    
    style F stroke:#34d399,fill:#0b3b2e,color:#d1fae5
    style G stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px

The practical implication is that extended thinking is a mid-session tool for long, high-stakes loops. Turning it on at the start of every session is a mistake. Turning it on never is also a mistake for teams running 200+ turn refactors. The correct pattern is task-type awareness.

When to Turn Extended Thinking On: Real Decision Matrix

The decision to enable extended thinking comes down to three factors: task complexity, session length, and correction cost. Here's the matrix that production teams use.

Turn extended thinking ON when:

• Session is projected to exceed 100 turns and involves multi-file edits
• The task requires formal correctness (state machines, type system refactors, async coordination)
• Correction turns would require re-analyzing large context (architectural changes, framework migrations)
• Initial attempts in standard mode failed and you're on the retry pass

Turn extended thinking OFF when:

• Session is under 50 turns
• Task is CRUD generation, boilerplate, or single-file edits
• You're in a read-heavy review loop with sparse suggestions
• Cost budget is tight and you can tolerate one extra correction turn per 20 turns

Use interleaved mode (toggle mid-session) when:

• Test-fix loops where fixes vary in complexity
• Refactors where some files are trivial renames and others are complex type rewrites
• Exploratory sessions where you don't know task complexity upfront

The key metric is correction-turn cost. If a mistake on turn 80 cascades into 8 correction turns, and extended thinking would have caught it, you saved net tokens even though extended thinking costs more per turn. If mistakes are cheap to fix (one-turn corrections), extended thinking overhead dominates.

%% alt: Decision flowchart for enabling extended thinking
flowchart LR
    A("Start task") --> B("Session projected >100 turns?")
    B -->|No| C("Task requires formal correctness?")
    B -->|Yes| D("Multi-file edits involved?")
    C -->|No| E("Standard mode")
    C -->|Yes| F("Enable extended thinking")
    D -->|No| C
    D -->|Yes| F
    E --> G("Monitor for failures")
    F --> H("Lower correction turn rate")
    G --> I("Retry with extended thinking if fails")
    style F stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px
    style E stroke:#34d399,fill:#0b3b2e,color:#d1fae5
    style I stroke:#fbbf24,fill:#3a2f0b,color:#fef3c7

This matters because the default behavior in most Claude Code setups is to inherit the setting from the previous session. If you ran a complex refactor yesterday with extended thinking on, today's simple component generation inherits that setting unless you explicitly toggle it off. Teams that don't check this waste 40-60% of their budget on unnecessary overhead.

The Cost Math: Extended Thinking in Long Sessions

The token economics of extended thinking are non-linear because Claude Code re-sends the entire conversation history with every turn. A fresh session sends ~20K tokens per turn. A 200-turn session sends ~200K tokens per turn because the context window includes all prior messages. Extended thinking adds 3-8K hidden reasoning tokens per turn on top of that base.

Here's the actual math for a 200-turn refactor session:

// Cost model for 200-turn refactor session
interface SessionCost {
  turnsCompleted: number;
  avgContextTokensPerTurn: number;
  extendedThinkingTokensPerTurn: number;
  pricePerMillionTokens: number;
}
 
function calculateSessionCost(config: SessionCost): number {
  const {
    turnsCompleted,
    avgContextTokensPerTurn,
    extendedThinkingTokensPerTurn,
    pricePerMillionTokens,
  } = config;
 
  // Standard mode: only context tokens
  const standardModeCost =
    (turnsCompleted * avgContextTokensPerTurn * pricePerMillionTokens) /
    1_000_000;
 
  // Extended thinking mode: context + hidden reasoning tokens
  const totalTokensPerTurn =
    avgContextTokensPerTurn + extendedThinkingTokensPerTurn;
  const extendedModeCost =
    (turnsCompleted * totalTokensPerTurn * pricePerMillionTokens) / 1_000_000;
 
  return extendedModeCost - standardModeCost;
}
 
// Real scenario: 200-turn refactor with growing context
const refactorSession: SessionCost = {
  turnsCompleted: 200,
  avgContextTokensPerTurn: 180_000, // Context grows over session
  extendedThinkingTokensPerTurn: 5_000, // Conservative estimate
  pricePerMillionTokens: 3.0, // Claude Sonnet 4 pricing
};
 
const overhead = calculateSessionCost(refactorSession);
console.log(`Extended thinking overhead: $${overhead.toFixed(2)}`);
// Output: Extended thinking overhead: $3.00
 
// This is the ADDITIONAL cost on top of base session cost
const baseCost = (200 * 180_000 * 3.0) / 1_000_000;
console.log(`Base session cost: $${baseCost.toFixed(2)}`);
// Output: Base session cost: $108.00
 
const totalWithExtended = baseCost + overhead;
console.log(`Total with extended thinking: $${totalWithExtended.toFixed(2)}`);
// Output: Total with extended thinking: $111.00

The overhead looks modest in absolute terms ($3 on a $108 session), but it compounds if you run five such sessions per week. More importantly, the cost-benefit flips based on how many correction turns extended thinking prevents. If it saves you 10 correction turns in that 200-turn session, each avoided turn saves ~$0.54 in context re-send costs, totaling $5.40 saved—a net win. If it saves zero correction turns because the task was simpler than expected, you burned $3 for nothing.

The failure mode is not tracking this per session. Teams that leave extended thinking on by default across all session types pay the overhead every time, but only realize the savings on the 20% of sessions complex enough to need it. The result is a 40-60% higher monthly bill with no corresponding quality improvement on most tasks.

Interleaved Thinking vs Manual Mode: Performance Trade-offs

Interleaved thinking—toggling extended thinking on and off within a single session—is the optimal pattern for medium-complexity loops where task difficulty varies by file or subtask. The model runs standard mode for routine edits, extended thinking for the hard parts, and you pay only for what you need.

The implementation is manual in most Claude Code setups. You send a message asking the assistant to enable extended thinking for the next N turns, then send another message to disable it. Some platforms expose this as a per-turn header (anthropic-enable-extended-thinking: true), but the conversational interface requires explicit instructions.

The performance tradeoff is latency. Extended thinking adds 5-15 seconds per turn. In a tight refactor loop where you're approving edits every 30 seconds, that delay is noticeable. In a long-running test-fix loop where you check back every 5 minutes, it's irrelevant. Interleaved mode lets you apply the delay only where it matters.

flowchart TD
    A("Refactor session starts") --> B("Turn 1-20: Trivial renames")
    B --> C("Standard mode: fast edits")
    C --> D("Turn 21: Complex type rewrite")
    D --> E("Enable extended thinking")
    E --> F("Model deliberates 12 seconds")
    F --> G("Correct type propagation on first try")
    G --> H("Turn 22-40: More renames")
    H --> I("Disable extended thinking")
    I --> C
    style E stroke:#c084fc,fill:#3b0764,color:#f3e8ff,stroke-width:4px
    style G stroke:#34d399,fill:#0b3b2e,color:#d1fae5

The key insight is that extended thinking is most valuable at decision points—the turns where a wrong move cascades into expensive corrections. In a test-fix loop, that's the first fix attempt after a failure. In a refactor loop, that's the turn where the model propagates a type change across module boundaries. In a generation loop, it's usually never because there are no cascades.

The failure mode is forgetting to toggle it back off. Extended thinking stays enabled until you explicitly disable it, so if you turn it on for a hard turn then forget about it, the next 50 routine turns all pay the overhead. This is why interleaved mode requires discipline—you need to track when it's on and turn it off as soon as the hard part finishes.

Practical Patterns: Toggling Extended Thinking Per Task Type

The cleanest pattern is a task-type classifier at session start. You declare the session type (generation, refactor, test-fix, review) and a rule set determines the extended thinking strategy. This eliminates decision fatigue and ensures you apply the right setting without manually toggling every session.

Here's a practical implementation for a CI agentic loop that runs Claude Code for automated test generation and fixes:

type AgenticTaskType = "generation" | "refactor" | "test-fix" | "review";
 
interface ExtendedThinkingStrategy {
  enableByDefault: boolean;
  toggleAtTurn?: number;
  toggleOnCondition?: (context: SessionContext) => boolean;
}
 
interface SessionContext {
  currentTurn: number;
  filesModified: number;
  lastActionFailed: boolean;
  estimatedTotalTurns: number;
}
 
function getExtendedThinkingStrategy(
  taskType: AgenticTaskType,
): ExtendedThinkingStrategy {
  switch (taskType) {
    case "generation":
      // CRUD generation: never enable unless it's >50 turns
      return {
        enableByDefault: false,
        toggleAtTurn: 50,
      };
 
    case "refactor":
      // Multi-file refactor: enable after turn 100 or if >10 files touched
      return {
        enableByDefault: false,
        toggleOnCondition: (ctx) =>
          ctx.currentTurn >= 100 || ctx.filesModified > 10,
      };
 
    case "test-fix":
      // Test-fix: enable only after first failure
      return {
        enableByDefault: false,
        toggleOnCondition: (ctx) => ctx.lastActionFailed,
      };
 
    case "review":
      // Review: never enable unless checking formal properties
      return {
        enableByDefault: false,
      };
 
    default:
      return { enableByDefault: false };
  }
}
 
// Usage in agentic loop controller
class AgenticLoopController {
  private extendedThinkingEnabled = false;
  private strategy: ExtendedThinkingStrategy;
 
  constructor(private taskType: AgenticTaskType) {
    this.strategy = getExtendedThinkingStrategy(taskType);
    this.extendedThinkingEnabled = this.strategy.enableByDefault;
  }
 
  async executeTurn(context: SessionContext): Promise<void> {
    // Check if we should toggle extended thinking this turn
    const shouldEnable = this.shouldEnableExtendedThinking(context);
 
    if (shouldEnable !== this.extendedThinkingEnabled) {
      await this.toggleExtendedThinking(shouldEnable);
      this.extendedThinkingEnabled = shouldEnable;
    }
 
    // Execute the actual turn with current setting
    await this.runModelTurn(context);
  }
 
  private shouldEnableExtendedThinking(context: SessionContext): boolean {
    // Turn-based toggle
    if (
      this.strategy.toggleAtTurn &&
      context.currentTurn >= this.strategy.toggleAtTurn
    ) {
      return true;
    }
 
    // Condition-based toggle
    if (this.strategy.toggleOnCondition) {
      return this.strategy.toggleOnCondition(context);
    }
 
    return this.strategy.enableByDefault;
  }
 
  private async toggleExtendedThinking(enable: boolean): Promise<void> {
    // Send instruction to Claude to enable/disable extended thinking
    const instruction = enable
      ? "Enable extended thinking for the next response."
      : "Disable extended thinking and use standard mode.";
 
    console.log(`[Turn ${Date.now()}] ${instruction}`);
    // In practice, this sends a system message or sets a header
  }
 
  private async runModelTurn(context: SessionContext): Promise<void> {
    // Placeholder for actual model API call
    console.log(
      `Executing turn ${context.currentTurn} with extended thinking: ${this.extendedThinkingEnabled}`,
    );
  }
}
 
// Example: Test-fix loop that enables extended thinking only after failure
const testFixLoop = new AgenticLoopController("test-fix");
 
const mockContext: SessionContext = {
  currentTurn: 15,
  filesModified: 3,
  lastActionFailed: true, // Test just failed
  estimatedTotalTurns: 30,
};
 
await testFixLoop.executeTurn(mockContext);
// Output: [Turn <timestamp>] Enable extended thinking for the next response.
// Output: Executing turn 15 with extended thinking: true

This pattern eliminates the "forgot to toggle" failure mode because the decision logic is encoded in the strategy. A test-fix loop automatically enables extended thinking when it hits a failure, then disables it after the fix succeeds. A refactor loop waits until turn 100 or until it's touched 10+ files, whichever comes first.

The cost savings are immediate. A team running 50 agentic sessions per week with this strategy will see a 50-70% reduction in extended thinking overhead compared to leaving it on by default, with zero quality loss on simple tasks and full benefit on the complex ones.

Frequently Asked Questions

Does extended thinking improve code quality on all task types?

No. Extended thinking improves quality only on tasks where the model would otherwise make mistakes that require correction turns—typically multi-file refactors, complex type propagation, or subtle async bugs. Simple CRUD generation, linting fixes, and pattern-based reviews see no quality gain because the model handles these well in standard mode.

How do you know if extended thinking saved you correction turns?

Track correction turn rate per session type. If your refactor loops average 8 correction turns per 100 turns in standard mode but only 3 per 100 turns with extended thinking enabled, the delta (5 saved turns) times the per-turn cost tells you the net savings. Most teams don't track this and pay overhead without validating the return.

Can you use extended thinking selectively within a single turn?

No. Extended thinking is a session-level or turn-level setting, not a sub-turn feature. You enable it for the entire next response or disable it entirely. The granularity is per-message, which is why interleaved mode requires explicit toggle instructions between turns.

What happens if you forget to disable extended thinking after a complex turn?

Every subsequent turn pays the extended thinking overhead (5-15 seconds latency, 3-8K hidden reasoning tokens) even if the task is trivial. In a 200-turn session, forgetting to toggle off after turn 50 means you pay overhead for 150 unnecessary turns, often doubling the session cost with no benefit.

Is extended thinking worth it for sessions under 50 turns?

Rarely. Short sessions have low correction-turn costs because the context window is small—a mistake on turn 10 only requires re-sending 10 turns of history to fix. Extended thinking overhead often exceeds the correction cost in these cases. The break-even point is around 80-100 turns for most refactor loops.

Conclusion: Extended Thinking Is a Precision Tool, Not a Default

Extended thinking in Claude Code is a cost multiplier that pays for itself only when applied to the right task types at the right session length. Teams that enable it by default across all loops pay 40-60% more than teams that toggle it per task complexity. The decision matrix is straightforward: generation loops and reviews run standard mode, refactors enable it after turn 100 or when touching 10+ files, and test-fix loops toggle it only on failure retries.

The failure mode is treating extended thinking as a quality toggle instead of a token allocation strategy. It does not make the model smarter—it gives the model more budget to deliberate before responding. That budget is wasted on tasks the model handles well in standard mode and essential on tasks where a wrong turn cascades into expensive corrections.

That covers the essential patterns for managing extended thinking in agentic loops. Apply these rules in production and the cost reduction will be immediate, with zero quality loss on the 80% of tasks that never needed the overhead in the first place.