Bug: Agent selects read-only subagent types for write tasks, then fails to self-correct on rejection

Environment

• Claude Code CLI: 2.1.83
• Model: claude-opus-4-6 (1M context)
• OS: Linux 7.0.0-7-generic (Debian/Ubuntu)
• Terminal: Warp
• Date: 2026-03-25

Description

The Opus orchestration agent dispatched read-only subagent types (Plan/Explore) for an explicitly requested code-writing task. When these subagents could not write files and were rejected, the agent did not reassess its approach. After user interruption and direct correction ("work inline instead"), the agent attempted to redispatch the same read-only subagent types for the same writing task a second time. The agent's failure to self-correct on rejected dispatches, combined with the absence of any platform-level circuit breaker, resulted in significant unproductive quota consumption — approximately 60% of a 5-hour Max subscription quota burned in roughly 10 minutes with zero output.

The Process Failure

This is fundamentally a self-correction failure, not just a subagent selection error. The agent:

1. Selected the wrong subagent type (read-only for a write task)
2. Had the dispatch rejected
3. Was directly told by the user to change approach
4. Ignored that correction and attempted the same dispatch again
5. Had it rejected again
6. Continued consuming tokens reading files it could not act on
7. When confronted, misattributed the cause to external factors instead of identifying its own selection error
8. Failed to accurately recount the sequence of events when asked

At no point in this chain did the agent autonomously recognize "I am consuming resources without producing output — I should stop."

Reproduction Steps

1. Start a Claude Code session with claude-opus-4-6 (1M context)
2. Establish a multi-task implementation plan with the agent
3. Instruct the agent to execute implementation tasks using subagents (e.g., "dispatch Sonnet subagents to translate these files")
4. Agent dispatches subagents using Plan or Explore subagent types (read-only) instead of general-purpose (read-write)
5. Subagent dispatches are rejected
6. Observe: Agent does not detect the mismatch between task requirements and subagent capabilities
7. Interrupt and tell the agent to change approach
8. Observe: Agent attempts to redispatch the same read-only subagent types
9. Quota consumption continues until user forces a stop

Expected Behavior

1. Agent should match subagent type to task requirements — write tasks get write-capable subagents
2. After a rejected dispatch, the agent should reassess the approach, not retry the identical dispatch
3. After direct user correction, the agent should follow the correction, not repeat the rejected pattern
4. If the agent has consumed significant quota without producing any tangible output (file writes, commits), it should pause and alert the user

Actual Behavior

1. Agent dispatched Plan/Explore (read-only) subagents for a code translation task
2. When dispatches were rejected, agent attempted the same dispatch pattern again
3. After user explicitly said "work inline," agent still attempted to redispatch read-only subagents
4. Agent continued reading large source files in a context where it could not write
5. When confronted, agent misattributed the failure to "plan mode activating" rather than its own subagent type selection
6. Agent failed to accurately describe the failure sequence on multiple attempts

Impact

• Approximately 60% of a 5-hour Max subscription daily quota consumed in ~10 minutes
• Zero productive output from the consumed quota
• Remainder of the work day lost due to quota exhaustion
• No automatic detection, warning, or recovery at any point in the failure chain

Root Cause Analysis

1. Subagent type selection error (agent logic)

The agent has access to multiple subagent types: general-purpose (full tool access including writes), Plan (read-only), Explore (read-only). For a task explicitly described as code translation (a write task), the agent selected read-only types. This is a classification error in the agent's task-to-subagent-type mapping.

2. No self-correction on rejection (agent logic)

The agent's instructions state: "If the user denies a tool you call, do not re-attempt the exact same tool call." The agent violated this by redispatching the same subagent types after rejection and after direct user correction. The self-correction mechanism either did not engage or was insufficient.

3. No unproductive consumption detection (platform gap)

When the agent entered a failure loop (dispatch → reject → retry → reject → read without write capability), nothing stopped it. Claude Code has no mechanism to detect that tokens are being consumed without producing output. The only circuit breaker was the human user noticing and manually interrupting.

Suggested Fixes

Agent-level (self-correction)

• After a subagent dispatch is rejected, the agent must not retry the identical dispatch — it should reassess task requirements vs. subagent capabilities
• When a task involves creating or modifying files, the agent should validate that the selected subagent type has write permissions before dispatching
• The agent should track its own output-to-consumption ratio and flag when it has consumed significant quota without producing any writes or commits
• After direct user correction, the agent must follow the correction — not repeat the corrected behavior

Platform-level (circuit breakers)

• Token budget per session: A user-configurable limit that hard-stops the session when exceeded (e.g., --max-tokens 500000)
• Unproductive consumption alert: If the agent has consumed N tokens (configurable) without producing any file writes, commits, or other tangible output, surface a warning to the user
• Failed dispatch backoff: After N consecutive rejected tool calls (e.g., 3), require explicit user confirmation before continuing
• Spend rate alerting: If quota consumption rate exceeds a threshold (e.g., significant percentage of daily quota in under 10 minutes), pause and notify

Session Reference

Session ID: 07c3752c-7b07-4448-8223-606e97b567c7
Branch: main
The full conversation history is available in the Claude Code session log if Anthropic engineering needs to inspect the exact dispatch chain.

Related

Multiple users have reported similar runaway quota consumption issues on r/ClaudeAI and r/ChatGPTCoding in the week of 2026-03-17 through 2026-03-25. As of this filing, there has been no public acknowledgment from Anthropic regarding this class of issue.