One resumed subagent consumed half a weekly Max 20× Fable allowance unattended — no ceiling, no warning, no knob

Support reference ID (for log correlation): 339504e0-6011-4e93-aa15-6036813aff5e

Symptom 1 — half a weekly allowance, spent unattended

An orchestrating session kept a subagent working on a capped model between the operator's last instruction (23:00) and their next message (07:41). The operator issued nothing in that window and woke to an exhausted weekly limit, three days from reset.

One subagent, resumed 8 times, accounted for 50.7% of that week's entire consumption for the model. Resuming does not reset context, so every segment shared one growing transcript.

462 API turns / 16.7 h → 227.8 M cache read, 71,909 output. The cost of an identical unit of work rose monotonically:

| segment | API turns | cache read | per turn | per shell cmd |
|---:|---:|---:|---:|---:|
| 1 | 129 | 34.8 M | 270 K | 266 K |
| 3 | 48 | 20.6 M | 430 K | 448 K |
| 5 | 69 | 39.5 M | 572 K | 556 K |
| 6 | 79 | 55.4 M | 702 K | 711 K |
| 8 (overnight) | 29 | 21.0 M | 723 K | 749 K |

2.7× more expensive per turn by the end, for the same work. The agent was not idling or looping — 310 of its 459 shell commands wrote files, spread across every segment. Peak context 888,096; many turns emitted 3–17 output tokens while reading >400 K.

Tool results were not the driver: all 478 totalled 0.6 MB, none over 50 K chars. The context was the agent's own output, which becomes permanent input for every later turn. Cost scales ~N² in turns, so splitting the same work across k fresh agents divides it by k.

Nothing bounds this: no ceiling on subagent turns, tokens or wall time; no warning as per-turn cost triples; no live view of subagent spend (#33945); nothing distinguishing an attended session from an unattended one.

Distinct mechanism from #68619's recursive spawning, same outcome. Also reproduces its bug 5 — the agent died mid-task on HTTP 429 and its completed work survived only because it happened to be in a git worktree.

Symptom 2 — the limit fired on the lightest of four weeks

| week | API turns | output | cache read |
|---|---:|---:|---:|
| wk-0 (exhausted) | 1,417 | 2,023,119 | 449.1 M |
| wk-1 | 3,119 | 4,059,388 | 994.5 M |
| wk-2 | 2,865 | 3,715,014 | 1,132.5 M |
| wk-3 | 2,382 | 3,555,225 | 868.8 M |

1.8–2.0× less output and 1.9–2.5× less cache read than the three preceding weeks, and it exhausted ~4 days in with three still to run.

The +50% Claude Code weekly-limit promo expired 2026-08-31 23:59 PT (06:59 UTC) and the limit fired at 07:23 UTC, 24 minutes later — but that timing cannot be the cause:

• To trip the reverted cap, wk-0 must exceed boosted / 1.5 = 67% of boosted.
• wk-1 ran a full week under the boosted cap, so wk-1 < boosted.
• wk-0 is 50% of wk-1, so wk-0 < 50% of boosted — it cannot reach 67%.

Unless metered usage diverges sharply from these token counts, the proximity is coincidence. Two possibilities remain, and either would be a defect:

1. A mid-window cap reduction re-scores spend already made under the previous terms — retroactive enforcement, with no in-product notice. Reverting at the next window boundary would avoid it.
2. It does not re-score — in which case a week measuring ~2× lighter than each of three predecessors tripped a cap they did not, and I cannot reconcile it.

Aggregated from every ~/.claude/projects/**/*.jsonl, deduplicated by message.id — streaming re-serializes a message with its usage block, so counting raw lines inflates totals ~2.1×. Transcripts extend back to April, so no week is truncated; this machine only, all four weeks measured identically. settings/usage exposes no breakdown, so a subscriber cannot verify any of this themselves.

Asks

1. Bound runaway subagent consumption by default — a ceiling and a warn threshold that ship on, not an opt-in setting. The operator who needs it is the one who does not know it exists.
2. Surface capacity changes and usage in-product — nothing indicated a promo-driven cap was ending mid-window, and no breakdown exists to reconcile a limit against observed usage. This took transcript parsing to diagnose at all.

Environment: Claude Code, Max 20×; subagent claude-fable-5, orchestrator claude-opus-5; failure rate_limit HTTP 429. Related: #68619, #33945, #50998, #46047.