Workflow tool: auto-authored fan-outs inherit expensive model by default and lack cost visibility — 70 agents drained plan limit in <10 min
Summary
Auto-authored Workflow scripts default to expensive model inheritance and unbounded fan-out. One auto-authored workflow spawned 70 subagents and exhausted my plan limit in under 10 minutes. (Corrected 2026-06-12: originally reported as 140 — .meta.json sidecars were miscounted as agent transcripts.)
What happened
In a Claude Code session, the model auto-authored a Workflow (epic-619-plan-impl-review, a plan/implementation review with find → adversarial-verify phases). I approved it via the standard permission dialog. It then spawned 70 subagents:
- 6 finder agents on
claude-opus-4-7, running 36–103 turns each (one agent alone read ~14M tokens via cache) - 64 verifier agents — one agent PER finding — with no
modeloverride, inheriting the session model (Fable 5) witheffortLevel: xhigh. Only ~19 produced output; the other ~45 died at setup (possibly a second bug worth looking at).
Totals for the single workflow run: 69M cache-read tokens, 5.9M cache-write, 1.5M fresh input, 334k output.
Why I consider this a product bug (inconsistent behavior), not just a gap
- The product contradicts its own recommendation. The official cost docs recommend Sonnet/Haiku for subagent tasks, but the Workflow tool spec instructs the authoring model to "default to omitting" the
modeloption — which inherits the most expensive session model. The recommended behavior and the default behavior are opposites. - The only user decision point is uninformed. The approval dialog shows workflow name + description only — no projected agent count, no model tiering, no cost estimate. I approved without the information that would have made approval meaningful.
- The budget mechanism is opt-in. The
budgetdirective exists and works as a hard ceiling, but if the authoring model doesn't emit it, the fan-out runs until the 1000-agent cap or the user's plan limit — whichever comes first. - No deterministic config exists. There is no
workflow.maxAgents, no default subagent model setting, no warning threshold. Model tiering and fan-out shape depend entirely on the authoring LLM's judgment.
Suggested fixes
- Show projected agent count + per-phase model tiering in the approval dialog
- Make a token budget mandatory (or default-capped) for workflows above N agents
- Auto-tier workers to smaller models, or invert the "omit model" guidance for large fan-outs
- Warn when a single stage maps 1 agent per item over a large list
Repro / evidence
Session ID: c7fad4f3-07aa-42bf-8280-0b01c4fbef7d · Workflow run: wf_7d716daf-ac2
I'm happy to provide more details and authorize sharing the session logs/transcripts with Anthropic if useful — just ask here.
🤖 Generated with Claude Code
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is doubly bad when using Fable. Fable needs fewer agents and spawns more. Highly recommend putting a "HARD LIMIT: 10 agents at a time, and you probably need less than half that. They're 1M context window Opus agents and fully capable of long-running work. Spawn fewer and combine workloads into single agents."
Else, overhead of agent spawning eats usage limits faster than high-context high-total-workload agents.
Correction + follow-up findings.
Correction: the original report said 140 subagents. The real count is 70 (6 opus finders + 64 verifiers) — I had counted
.meta.jsonsidecar files alongside the.jsonltranscripts. Title and body are now fixed. The token totals were always correct (69M cache-read / 5.9M cache-write / 1.5M input / 334k output), so the substance is unchanged — if anything stronger: half the agents burned the same limit. Side note: of the 64 verifiers only ~19 actually produced output; ~45 died at setup, which may be a separate bug.Why I think the fix must be structural, not prompt-level: I surveyed dynamic-workflow implementations in the pi coding agent ecosystem.
pi-dynamic-workflows(a Workflow-tool clone) has the exact same gaps — LLM-judgment-only fan-out and model inheritance. Butnicobailon/pi-subagentsdeclarative chains makeexpand.maxItemsa required field that hard-fails validation when missing: an unbounded fan-out is unrepresentable, not merely discouraged. That's the pattern I'd suggest here — make a fan-out cap / budget a validated property of the workflow script or the approval dialog, rather than guidance to the authoring model.As a stopgap I now run a PreToolUse hook that statically rejects Workflow scripts lacking a fan-out cap, model tiering, batching, and a budget guard — happy to share it, and the session logs remain available on request.
The "70 Opus agents drained in <10 min" data point in this report is a good illustration of what makes fan-out cost visibility different from the usual "I spent more than expected" billing complaint.
The problem is structural: the workflow tool auto-authors the fan-out, so the user has no pre-flight opportunity to review agent count or model selection. By the time the cost is visible (post-run, via /usage), the quota is gone. Standard rate-limit UX assumes the user chose to make N requests; this pattern assumes the orchestrator did.
The fixes that would actually help:
maxCostUSDormaxAgentsparameter in the workflow definition that hard-stops the fan-out if either limit is hit. This is opt-in so it doesn't break existing workflows.The "auto-authored fan-out + expensive default model + no visibility" combination is the specific failure mode here. Addressing any one of the three would reduce the severity.