Why Token Limits Never Add Up When Running Parallel AI Agents
Why Token Limits Never Add Up When Running Parallel Agents
You look at your plan's token allocation, divide by the number of agents, estimate per-agent budget, and think you have plenty. Then you run out halfway through the day. The token math never adds up the way you'd expect.
The Hidden Overhead
Every agent interaction starts with context loading - system prompts, project files, conversation history. This "cold start" tax eats into your budget before any real work happens. With a single agent, you pay it once. With five parallel agents, you pay it five times.
On a macOS app build, each agent reads the same Package.swift, the same shared utilities, the same CLAUDE.md configuration. None of that work is shared across agents. Each one burns tokens independently reading identical content.
Compiler Error Loops Are Token Sinks
Swift's strict compiler means agents often enter fix-compile-fix cycles. Each cycle sends the full error output back to the LLM, which generates a fix, which gets compiled again. A single type mismatch can cost thousands of tokens to resolve through iteration.
Multiply that across five agents, each hitting their own compiler issues, and the burn rate is staggering.
What Helps
A few practical strategies reduce waste. Keep agent tasks small and well-scoped so context windows stay lean. Use aggressive context clearing between tasks rather than letting conversation history pile up. Pre-compile shared modules so agents aren't all fighting the same build errors.
Most importantly, accept that the effective token budget per agent is roughly 40-60% of the theoretical allocation. Plan your work decomposition around that reality, not the number on the billing page.
The gap between advertised capacity and practical throughput is the real cost of parallel agent development.
Fazm is an open source macOS AI agent. Open source on GitHub.