Bug Report: Uncontrolled Sub-Agent Recursive Loop Caused ~800k Token Consumption & $27.60 Unexpected Charge

Additional Evidence — Screenshot of Usage Page

Attaching a description of the usage screenshot taken immediately after the incident (screenshot will be uploaded manually):

Settings → Usage page shows:

| Metric | Value |
|--------|-------|
| Current session | 90% used (resets in 3h 33min) |
| Weekly — All models | 25% used |
| Weekly — Sonnet only | 12% used |
| Usage Credits spent | $27.60 — 100% used |
| Usage Credits reset | July 1 |
| Monthly spend limit | $0.00 (was not set by user) |
| Usage Credits toggle | OFF (currently disabled — user turned it off after discovering the charge) |

Key Points from Screenshot

1. The Usage Credits toggle is currently OFF — meaning the user did not intentionally have this enabled as an ongoing preference. It was triggered during the incident and subsequently disabled.
2. The $27.60 charge is 100% depleted, confirming the full amount was consumed — not partially.
3. The monthly spend limit shows $0.00, which indicates no spend cap was configured. This is a UX gap — users are not prompted to set a spend cap during onboarding, leaving them exposed to unexpected charges.
4. The session is at 90% used at the time of the screenshot, confirming the sub-agent recursive loop consumed the vast majority of the session quota.

Additional UX Issue Identified

The Usage Credits monthly spend limit defaults to $0.00 with no cap. Users are not guided to set a spending limit during onboarding. Combined with the lack of a confirmation dialog before Usage Credits are first triggered, this creates a situation where a single bug or accidental action can result in unbounded charges.

Suggested improvement: Set a default monthly spend cap (e.g., $10) for new users, with a clear prompt to adjust it. Require explicit confirmation the first time Usage Credits would be charged.

---

Screenshot to be attached manually to this issue.

<img width="1910" height="1416" alt="Image" src="https://github.com/user-attachments/assets/e4459ffc-d843-42f3-bec9-0620cd582021" />

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68110
2. https://github.com/anthropics/claude-code/issues/69332
3. https://github.com/anthropics/claude-code/issues/41461

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

The root cause you're hitting -- agents recursively spawning with no depth cap -- is a known gap in Claude Code's built-in supervision. What makes it expensive is that there's no ambient monitoring layer watching token burn across sessions before the damage is done. I've been building Claudiverse (https://claudiverse.ai) as a Mac-native control plane for exactly this: it wraps local Claude Code sessions and surfaces real-time spend + agent activity so you can catch runaway subagent trees before the bill hits. Disclosure: I'm the founder. No fix for the underlying bug here, but wanted to surface it since your report describes the gap pretty precisely.

Confirming this is a system design issue, not user error.

The root cause is skill document scope bleeding: when a sub-agent receives a skill that says "decompose multi-target tasks by spawning sub-agents," the sub-agent has no way to know that instruction was meant for the top-level orchestrator only. Every agent in the tree acts as if it is the root.

A few things that would have contained this without waiting on a platform fix:

1. Explicit depth tagging in system prompts. Something like AGENT_DEPTH=1 passed at spawn time, with skill documents checking if AGENT_DEPTH > 0: do not spawn additional agents. Clunky, but it works today with hooks.

1. Token budget as a circuit breaker. The parent agent can cap each sub-agent's token allowance at spawn. If the sub-agent exhausts it, it fails loudly rather than spawning more agents to compensate.

1. Fanout confirmation gate. A pre-tool-use hook on Agent (or Task) that fires when agent count in the current session exceeds N, requiring an explicit user approval before continuing.

The Usage Credits trigger without real-time blocking confirmation is the sharpest edge here. A vague past toggle should not constitute consent for a $27 charge. That part needs a platform-level fix, not a workaround.

Worth cross-referencing #69635 (ultra workflow auto-scaling to 130 agents triggering IP blocks) and #69732 (notification routing bugs that cause stalled chains to silently retry). These seem to share a root of "the system makes resource decisions the user cannot observe or interrupt in real time."

The missing depth limit is the scary part — a flat token cap doesn't really save you because the spawn tree explodes faster than you'd notice. I hit the OS-level version of this: an agent stuck re-spawning subprocesses took my Mac to load average 307 before I caught it. A dollar/token cap was always too late, so I ended up killing the process tree on the "high resource use + no output progress" signal instead. Doesn't patch the depth-limit gap in the harness, but it stops the machine going down with the run: https://github.com/IgorGanapolsky/mac-yolo-safeguards

On recursive sub-agent depth / token burns: an outer watchdog that kills the session when tool thrash produces no new progress has been more reliable for me than hoping the model self-stops. Open-source sketch: https://github.com/IgorGanapolsky/mac-yolo-safeguards

Not a Claude Code fix — just an operator-side belt if others are still getting $20+ no-output loops.

The recursive subagent loop that burned 800k tokens with almost zero output is exactly why we need a real control layer.

MartinLoop adds hard budget caps, verification before apply, rollback on failure, and full audit receipts. No more silent explosions or lost intermediate work.

This pattern is showing up everywhere right now. Repo if you want to see the direction: https://github.com/keesan12/martin-loop