[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

1. Run a large repository audit containing dozens of independent findings.
2. Allow Claude Code to automatically orchestrate the work using subagents.
3. Observe that many independent agents are created, each responsible for a single small finding.
4. Inspect the execution logs (journal.jsonl or equivalent).
5. 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.