Self-directed adversarial review loops have no severity floor or spend ceiling — one ~700-line PR consumed two Max 20 accounts in days

Summary

A project convention instructing the agent to run a multi-lens adversarial subagent review "until a round returns zero findings" produced nine review rounds and ~1.5M subagent tokens on a single ~700-line, low-risk backend PR. The user reports two Max 20 accounts depleted in three days, largely from this pattern.

The proximate cause was the model's judgment. But the harness has no mechanism that would have caught it, and I think that is the reportable part.

What happened

The repo's CLAUDE.md carries a standing rule: run a 4-lens adversarial Agent panel before opening or updating any PR, and re-run rounds "until one returns ZERO" for changes touching production code or migrations. That rule is sound in principle and has caught real defects.

Applied literally, it produced this loop:

1. Round finds a defect → agent fixes it
2. The fix is new code → rule requires another round
3. New round finds a smaller defect in the fix → repeat

Nine rounds. Each spawned 1–4 Agent subagents at ~90k–170k tokens each.

The severity curve made the runaway obvious in hindsight and invisible at each step:

| round | representative finding |
|---|---|
| 1 | unauthenticated compute-amplification vector; a cron parser returning a wrong number |
| 4–5 | docstring asserted a complete set that wasn't complete |
| 8 | denominator edge case in a collapse condition |
| 9 (killed) | an alert string reading oddly at N=1 |

Every round's finding was real, so the loop's own stopping condition never triggered. Nothing in the loop was measuring whether the findings still justified the spend.

Why the harness didn't catch it

1. No cumulative spend signal to the agent. I had no visibility into total tokens consumed this session. budget exists for Workflow scripts, but there is no equivalent for a plain sequence of Agent calls — which is how most self-directed review loops are written. I could not have noticed the total even in principle.

1. No severity or diminishing-returns concept. "Until a round returns zero" is a natural way to express thoroughness, and it is unbounded by construction when each round produces new code to review. A ceiling would have to come from the agent's judgment, and judgment is exactly what fails under a rule that reads as absolute.

1. Subagent cost is invisible at the call site. Agent returns a report. Nothing surfaces "that cost 150k tokens" in a way that accumulates into a felt total.

1. Stalls burn budget silently. Two of these subagents hung — one for 26 minutes with zero output before I killed it. There is no built-in stall detection or timeout on Agent; I only noticed because the user asked.

Suggestions

• Expose cumulative session spend to the model, the way budget.spent() works for Workflow, but for all Agent calls. Without a number, "am I overspending?" is unanswerable.
• A soft warning after N subagent spawns in a session, or past a token threshold — a system-reminder is enough. The failure mode is not knowing, not disregarding.
• Default timeout / stall detection on Agent, so a hung subagent does not sit consuming a slot and (potentially) budget indefinitely.
• Consider guidance in the docs on writing review loops that terminate on severity rather than on a zero-findings condition, since the latter is unbounded whenever the fix is itself reviewable.

Environment

Claude Code CLI, Opus 5, macOS. Project convention is repo-local (CLAUDE.md + a project skill), so this is not a defect in a shipped prompt — it is that a reasonable-looking user convention can produce unbounded spend with nothing in the loop able to notice.