[BUG] Agent fan-out pays ~47K uncached startup tokens per small task, causing multi-million-token usage
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Claude Code's orchestrator created one new agent for each small finding during a large audit.
Each agent incurred approximately 47.7K input tokens before performing any useful work. Analysis of the execution logs shows that around 71% of the total token usage was spent on repeated agent initialization rather than repository inspection or reasoning.
The sampled agents were already well scoped (typically reading only 1 to 5 files), so redundant file reads were not the primary cause.
The main issue appears to be that every agent started from scratch with an identical large prompt, while a small variable at the beginning of each generated prompt prevented effective prompt-cache reuse. High parallelism further reduced cache effectiveness.
This resulted in approximately 4.9M total tokens, of which about 3.5M were repeated startup overhead.
What Should Happen?
The orchestrator should optimize for total token efficiency when dispatching many small homogeneous tasks.
Instead of spawning one fresh agent per finding, it should reuse a smaller number of persistent agents that process multiple findings sequentially.
It should also preserve a stable prompt prefix whenever possible to maximize prompt-cache reuse, and estimate the startup cost before large fan-outs.
For example, processing 73 findings with 8 persistent agents would dramatically reduce repeated initialization costs while preserving parallelism.
Error Messages/Logs
Steps to Reproduce
- Run a large repository audit containing dozens of independent findings.
- Allow Claude Code to automatically orchestrate the work using subagents.
- Observe that many independent agents are created, each responsible for a single small finding.
- Inspect the execution logs (journal.jsonl or equivalent).
- Compare the initial input token usage for each agent before any repository files are read.
Expected:
Startup cost should be amortized across multiple findings.
Observed:
Each agent pays roughly the same ~47K-token initialization cost independently, resulting in millions of repeated input tokens.
Claude Model
Sonnet (default)
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.207
Platform
Anthropic API
Operating System
Ubuntu/Debian Linux
Terminal/Shell
iTerm2
Additional Information
Measurements from one production run:
- Findings: 73
- Total token usage: ~4.9M
- Estimated repeated startup overhead: ~3.5M tokens
- Startup overhead: ~71% of total usage
- Useful repository work: ~29%
Sampled agents typically inspected only 1–5 files and showed almost no redundant file reads.
The bottleneck was repeated agent initialization rather than repository scanning.
It also appears that generated prompts differed at the very beginning due to a per-finding identifier, preventing prompt-cache reuse. This may be an implementation detail worth investigating.
Reducing the number of agents (for example, 8 persistent agents processing findings sequentially) would likely reduce token consumption dramatically.
3 Comments
The token startup cost pattern you're describing is one of the harder ones to work around from outside the harness, because the large shared prompt is the most natural way to give each subagent context -- and there's currently no first-class mechanism to cache that base prompt across the fan-out.
A few things that have helped in setups I've run (a GTM polling coordinator that dispatches multiple Claude agents on a cron schedule, so similar cold-start-per-task shape):
None of these are substitutes for native prompt caching across subagents -- that would be the right fix. But they're useful interim options if you're hitting this today.
What's the rough structure of the audit -- is the orchestrator generating one subagent per file, per finding, or per category?
Thanks, these are good suggestions, and they’re useful regardless.
In our case though, I think the core issue is slightly different.
We weren’t just paying the normal cold-start cost of multiple subagents. The orchestrator repeatedly re-read and re-expanded large parts of the same context and repository during the workflow, resulting in millions of unnecessary input tokens being consumed. In one run it burned about 5.2M tokens before we realized the workflow itself was mismatched to the requested audit.
Your suggestions would definitely reduce startup overhead, but I don’t think they explain the scale of what we observed. It looks more like repeated context reconstruction and/or redundant repository traversal than just prompt fan-out.
If needed, we can share the traces that led us to file the issue.
This is painful. Spawning a fresh agent for every small finding sounds parallel and smart until you realize each one is paying a massive uncached startup cost. You end up with millions of tokens just to initialize before any real work happens.
We’ve been focused on making the orchestration layer reuse context and agents more intelligently instead of treating every subtask like it needs a brand new cold start. The current model feels like it’s burning a ton of money on setup tax.
You seeing this kind of overhead consistently when you fan out work?
MartinLoop might help