[Bug] Parallel agent spawning causes excessive token consumption before crashing or hitting limits

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/65920
2. https://github.com/anthropics/claude-code/issues/66867
3. https://github.com/anthropics/claude-code/issues/67343

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is a known failure mode in multi-agent orchestration — models default to "spawn more agents" as a first-resort pattern when they should be doing serial decomposition. Three things I've found effective:

1. Agent budget as a hard constraint, not a suggestion: Before the orchestrator spawns anything, pre-compute the budget. If your task fits in 1-2 agents of context, cap spawns at 2. Fable 5 doesn't have a native budget gate, but you can enforce one via the task prompt: "You have exactly N agent slots. If you need more, decompose the task differently."

1. Token budget per sub-agent: The real cost isn't just spawn count — it's that each spawned agent gets a full context window. 10 agents × 200K tokens each = 2M tokens before they do anything useful. A two-pass pattern works better: first agent scopes the problem (cheap read-only), second agent does the work (writes). This caps the blast radius at 2 agents regardless of task complexity.

1. Serial > parallel for exploratory work: Parallel agents shine when each has a clearly scoped independent task (lint, test, typecheck simultaneously). For "go figure out this codebase" tasks, serial agents with progressively narrower scopes produce higher-quality output AND use fewer tokens. The orchestrator should default to serial and only parallelize when subtasks are genuinely independent.

The $500-1000 consolidated account request is an interesting signal — multi-agent users are hitting cost ceilings that single-account limits weren't designed for. Until platform-side limits adjust, operator-side budget gating is the reliable fix.

I'll add, this is a new issue because it's Fable, not in ultracode mode. 15 agents to review 15 skills. 70k tokens of up-front read for each one to audit skills that were a grand total of 5-10k tokens each. With better instruction from me later, Fable condensed to 8-15 skills per Opus agent which didn't eat my entire week's worth of context or get rate limited.

Key points: Not workflows. Not ultracode. Fable 5, 06-11-2026, with no explicit request to use ANY agents in the prompt.

The "spawn more agents at a lower cost per decision" failure mode you're describing is the invisible half of what makes parallel orchestration expensive: the visible cost is tokens, the invisible cost is the fact that the orchestrator has no budget signal at spawn time.

We ran into a structurally similar problem building the Claudiverse polling runner — a Rust service that coordinates multiple Claude Code agent dispatches across project namespaces. The pattern that worked: a pre-flight token budget check before each dispatch, combined with a hard cap on simultaneous agent slots. When the budget check fails, the dispatch is deferred to the next cycle rather than spawning anyway.

Three things that helped on our end:

1. Explicit fan-out budget: Before any parallel spawn, estimate the minimum cost of a well-structured serial path. Reject fan-outs that exceed serial_cost * N_agents * overhead_factor before they start.

1. Per-agent slot limits + SIGKILL on the process group: When an agent crashes or hits limits, kill the whole process group — not just the parent process. Claude CLI spawns MCP descendants that keep running (and accumulating) if you only kill the direct child.

1. Deferred retry, not immediate respawn: A crashed agent in a fan-out should not respawn in the same cycle. Defer and let the next invocation decide whether the work is still needed.

None of this is a substitute for the model being smarter about when to fan out, but it does put a hard floor under the blast radius when it over-spawns.

(We're building Claudiverse to help manage exactly this kind of multi-agent lifecycle complexity — session budgeting, cross-session coordination, lifecycle observability. Still in beta but the problem space matches what you're hitting.)

ugh, claude spawning 10 agents that did a bunch of reads then crashed and cost u a few million tokens is brutal, ur parallel agent defaults need a hard cap or backoff. fwiw wozcode cut my token spend about 50% with better caching, might help https://wozcode.com