Workflow fan-outs silently inherit the session model with no budget or rate-limit gate — 82-agent run on a top-tier model destroyed a Max 5-hour window

Environment

• Claude Code 2.1.220, VS Code extension host, macOS 15
• Claude Max subscription; session model claude-fable-5
• Workflow tool (background multi-agent orchestration)

What happened

An orchestrating session launched two Workflow runs (36 agents, then 52). Every agent() call omitted the model option, so all sub-agents inherited the session model — the top tier. Combined sub-agent spend was ~5.2M tokens. Mid-way through the second run the account's 5-hour utilisation hit 101%: 26 of 46 agents died with "You've hit your session limit", the verification half of the run was destroyed, and the user — watching the window get consumed in real time — had to switch accounts mid-session to keep working. A large share of the weekly limit went with it.

The orchestrator should have checked headroom before launching; that failure is the agent's. But the product's defaults made the failure this easy and this expensive, which is the feedback:

Product gaps

1. Model-omission guidance is a cost footgun. The Workflow tool docs say to default to omitting model because inheriting the main-loop model "is almost always correct". In a top-tier session that turns every unmarked fan-out into a top-tier fan-out. Omission reads as the safe default; it is the most expensive one.
2. No pre-flight cost gate. A script that will spawn 50+ agents launches with no estimated-cost surface and no confirmation. The size guideline is advisory prose; nothing structural stands between one tool call and tens of frontier-model agents.
3. No rate-limit-headroom awareness in the scheduler. The unified rate-limit headers are available client-side, yet the workflow kept launching agents into an already-exhausted window, converting the remaining queue into 26 guaranteed failures instead of pausing/parking the run.
4. Failure reporting hides completed side effects. Agents that die at the wall have typically already edited files; the failure list reads as "nothing happened", which invites wrong recovery decisions (the working tree said 43 files changed; the failure list implied ~8).

Asks

• A budget/confirmation gate above a threshold (agent count or estimated tokens), showing the effective model tier before launch.
• Headroom-aware scheduling: check the unified limit before and during fan-out; pause and preserve the run rather than failing the tail.
• Reframe the omit-model guidance, or surface the effective sub-agent model in the Workflow permission dialog.
• Distinguish "failed after partial side effects" from "failed, no changes" in workflow failure reporting.

User-side mitigations are now in place (explicit tier decisions per call, a pre-launch limit probe), but the defaults should not require a burned Max window to discover.