Why Sub-Agents Can Burn a Week's Quota in 30 Minutes
Every tool call round-trip resends the entire history
Run 5 sub-agents in parallel for 30 minutes and quota can drain dozens of times faster than a single conversation — because every tool-call round trip resends the entire conversation history accumulated so far.
Four key facts
Resends the full history
Most multi-turn/tool-calling APIs are stateless — every request has to resend the system prompt, all prior messages, and every prior tool-call result as input.
Cumulative usage grows roughly quadratically with turns
If a task takes N rounds of tool calls, and each round's average history size grows linearly with the round count, cumulative token usage grows roughly on the order of N squared.
Running multiple sub-agents at once compounds it
Every sub-agent running in parallel independently maintains and resends its own history — M parallel sub-agents roughly multiply a single conversation's usage by M.
Prompt caching saves money, not necessarily quota
Some vendors' prompt caching lowers the billed cost of repeated prefixes, but rate/quota limits are usually still calculated on actual tokens processed — don't treat caching as a cure-all for quota problems.
What's actually behind token resending
Most mainstream conversational/agentic APIs are 'stateless' — every request must carry the full context (system prompt, every message so far, every tool call's input and output); the model itself doesn't remember the previous request. That means for a task requiring N rounds of tool calls, round 1 sends only the initial context, round 2 has to include round 1's results too, and round N has to include everything from all N-1 prior rounds — cumulative tokens sent grow roughly quadratically with the number of rounds, not linearly. This is the root reason long tasks and multi-turn agentic loops are especially quota-hungry.
Why parallel sub-agents make this much more visible
When you kick off multiple sub-agents in parallel to work on different sub-tasks, each one independently does this same 'resend the history' dance, usually at the same time — token usage stacking up in a short window can easily reach several to dozens of times a single conversation's usage. This is the actual technical root of the common complaint: 'I ran a few parallel agents and burned through a week's quota in 30 minutes.'
Timeline
Stateless APIs resending the full history on every round has been the common architecture for mainstream conversational/agentic APIs all along.
The spread of parallel sub-agents and multi-agent workflows makes the drain from this inherent behavior much more directly noticeable to users.
Techniques like prompt caching ease the billing cost, but quota/rate-limit calculations usually haven't loosened accordingly.
Confirmed vs. common misreading
Confirmed
The stateless nature of mainstream multi-turn/agentic APIs, and the roughly quadratic cumulative usage caused by resending full history every round, are publicly documented, general behaviors of this kind of API architecture, consistently described in official docs and developer discussion.
Common misreading
Many people assume 'using prompt caching means I won't hit the quota limit quickly' — caching mainly affects billed cost; quota/rate limits are usually still calculated on actual tokens processed or request characteristics, so you can't fully rely on caching to control quota drain.
How to estimate and reduce usage
How to estimate
Estimate the expected number of tool-call rounds and the average history size per round, and roughly project total usage as quadratic rather than a simple linear 'per-round usage × round count' calculation.
How to reduce it
Periodically summarize/compress history, keep only the tool-call results the task actually needs instead of everything verbatim, and cap the number of parallel sub-agents and the max rounds per sub-agent — all common reduction tactics.
What to actually do
First, cap the maximum number of tool-call rounds per task — once a threshold is hit, trigger a history summary/compression instead of accumulating indefinitely. Second, keep only the parts of tool-call results the task genuinely needs, instead of stuffing entire raw logs/output into context. Third, cap how many sub-agents run in parallel at once, or assign non-critical sub-agents to a cheaper, shorter-context model. Fourth, treat quota consumption as an input to task planning — estimate roughly how much quota a complex task will use ahead of time, rather than discovering you're about to hit the limit only after it's already running.
What to do on QCode
Parallel sub-agents can easily fill up one model's quota in a short window; routing different sub-agents through one QCode key to different model families spreads out the quota pressure, so a single model hitting its limit doesn't stall the entire multi-agent task.
FAQ
Why do sub-agents drain quota so much faster than a single conversation?
Each sub-agent independently maintains and resends its own conversation history, so M parallel sub-agents roughly multiply a single conversation's usage by M; combine that with a single sub-agent's own cumulative usage already growing roughly quadratically with rounds, and the short-window drain gets amplified significantly.
Can prompt caching solve this problem?
It lowers the billed cost of repeated prefixes, but quota/rate limits are usually still calculated on actual tokens processed or request characteristics — you can't fully rely on caching to avoid hitting the limit.
How do I roughly estimate how much quota a task will use?
Estimate the expected number of tool-call rounds and the average history size per round, and project it as roughly quadratic rather than a simple 'per-round usage × round count.'
Does capping parallel sub-agents hurt task efficiency?
There's a trade-off — more parallelism finishes the task faster, but also raises the quota-drain pressure in a short window; you need to weigh this against your remaining quota and how urgent the task is.
Does every agent framework have this problem?
In principle, any agent framework built on mainstream stateless conversational APIs has this characteristic; the better a framework's history-compression/summarization strategy, the lower the drain you actually feel, but the underlying architectural cause is shared.
What happens to a running multi-agent task when it hits a quota limit?
The model/account that hit the limit will reject new requests, and the task usually stalls or errors out; proactively routing some sub-agents to other models is a common way to avoid the whole task getting stuck on a single model's limit.
Sources
The architectural fact that stateless conversational/agentic APIs resend full history every round is publicly documented and consistently described in mainstream model providers' documentation and developer communities; this page makes no claims about any single vendor's private implementation. Compiled 2026-08-27.
Don't let a multi-agent task get stuck on a single quota
One QCode key routes different sub-agents to different models, spreading out quota pressure.
Related reading
Claude's 5-Hour Rolling Window Explained
The layer of limits most likely to get hit during short bursts of heavy use.
Subscription vs. API: will a 24/7 agent eat through your plan?
The economics of long-running automated tasks.
How to rotate quota across multiple tools
Sensibly combining quota across multiple models/tools.
This page is general cross-vendor technical explanation and makes no claims about any single vendor's private implementation. Actual behavior depends on the specific model and client documentation you use.