minorrunaway-loopunverifiedcollected
/code-review fanned out to 10 subagents and burned a 5-hour quota in 4 minutes (unverified report)
An automatic pre-push `/code-review` in Claude Code started 10 subagents at once instead of one. The first run used up the 5-hour session limit in 8 minutes; the second did it in 4, and all ten stopped mid-review.
Cause
Per the author, three changes landed on the same day: the model moved from Opus 5 to Opus 5.5, effort was raised from high to max, and the desktop app updated (2.1.275 to 2.1.280). Better delegation plus a wider review scope, under a default ceiling of 20 concurrent subagents, produced the fan-out. The exact trigger was never isolated.
Consequence
26 subagents across two incidents, 16 of them cut off before finishing, and the weekly quota gone three days after the new model launched. The author puts each incident at about $31 of usage at API prices, absorbed by a Pro plan; subagents made up about 40% of the conversation's usage.
Fix
The author replaced the multi-agent review with a single subagent that checks correctness only; it went on to find two real bugs. Not yet tried: lowering the concurrent-subagent limit, turning off automatic invocation, lowering effort. Change one of model, effort and app version at a time, and cap parallelism before you need to.
What happened
The author, a small-business owner who is not a programmer, had Claude Code
run /code-review automatically before every push. On September 23, 2026,
that review suddenly started ten subagents at the same time instead of the
usual one. Eight minutes later the 5-hour session limit was gone.
The chaos on the ground
The next attempt was worse: the limit ran out in four minutes and all ten subagents stopped halfway, so the review produced nothing usable. Across the two incidents 26 subagents were started and 16 were cut off. Three days after the new model came out, the week’s quota was already spent. The author only noticed because the quota was falling faster than usual, and then had Claude read its own conversation logs to confirm that the agents had really run in parallel.
Root cause
Three things changed at once that day: the model (Opus 5 to Opus 5.5), the effort setting (high to max), and the app version. The author’s reading is that the newer model delegates more readily, max effort widens what a review covers, and nothing stopped it from running many agents at once, since the default limit allows 20. Because all three changed together, there is no way to say which one tipped it over.
The fix
The author dropped the multi-agent review and wrote a single reviewing subagent limited to correctness: reading line by line, behaviour changes, tracing across files, language pitfalls and value handling. That narrower review found two genuine bugs the original code had missed. Lowering the concurrency limit, turning off the automatic review, or lowering effort were left untried.
For anyone automating agents, two habits would have made this cheaper: change one of model, effort and version at a time so the cause of a jump is visible, and set a low ceiling on parallel agents before a smarter model decides to use all the room it has.