Claude Code 子智能體會更快耗盡使用限額嗎？
Do subagents burn your Claude Code limit faster?
Sam Stull 以單一帳戶兩日數據測量 Claude Code 子智能體，發現每次呼叫消耗約 0.071% 的 5 小時限額，與主執行緒的 0.072% 相近。消耗差異主要來自呼叫數：典型子智能體約用 1.9% 限額，五個並行約 10%，而最長的一個約用 10.1%。他建議每個子智能體預留約 2% 限額，並為長任務設定明確的範圍和停止點；數據來自一個帳戶、約兩日，工作組合不同會有差異。
Subagents are the usual suspect when a Claude Code limit runs out early. I measured what they actually cost on my account, using the same fit as in How many tokens is 1% of your Claude Code limit?
Per model call, no. A subagent call cost about the same share of my 5-hour limit as a main-thread call: roughly 0.07%. Subagents burn the limit because of how many calls they make. A typical subagent cost about 2% of a 5-hour window, so five in parallel cost about 10%.
Per call: about the same
Over two days (23–25 October), on one account:
| Model calls | New tokens per call | Cached tokens per call | Limit per call | Share of the limit used | |
|---|---|---|---|---|---|
| Main thread | 4,234 | 6.6k | 353k | 0.072% | ≈ 60% |
| Subagents | 2,895 | 8.4k | 223k | 0.071% | ≈ 40% |
These two days end a few hours later than the ones in the first post, so its subagent share (42%) and this one (40%) differ slightly.
The two cancel out. The main thread re-reads a bigger context on every call (353k cached tokens against 223k), but cached tokens count about 1/67 as much as new ones. Each subagent writes its own context into the cache from scratch, so its calls carry more new tokens (8.4k against 6.6k), and new tokens are what move the meter.
Per subagent: about 2% of a window
The same two days had 93 subagents. Priced against the 5-hour limit:
| Typical subagent (median) | 16 calls | ≈ 1.9% of a 5-hour window |
| Average | ≈ 2.3% | |
| 1 in 10 cost more than | ≈ 4.1% | |
| Largest | 86 calls | ≈ 10.1% |
The costliest tenth of subagents used 29% of everything subagents used. Most subagents are cheap; a few long ones are not, and a batch of them started at once is what ends a window early.
What to do with this
- Count before you fan out. Budget roughly 2% of a 5-hour window per subagent. Ten parallel subagents near the end of a window are a fifth of it.
- Watch the long ones. A subagent that keeps working for 80+ calls costs as much as five typical ones. Give it a narrow task and a clear stopping point.
- Don't count on the model alone. 97% of my subagent calls already ran on Sonnet, and they were still 40% of the limit. The number of calls matters more.
- Stop new ones when the window is nearly gone. That's what limitcast's guard does: when a window is on pace to run out within 30 minutes, it blocks new subagents in Claude Code and Codex, and while a window is tight it starts them on Sonnet.
The caveats
- One account, one plan, about two days. Your mix of work will give different numbers.
- The fit doesn't separate models. My main thread ran a lot of Opus and my subagents almost all Sonnet. If Anthropic counts Opus tokens more heavily, the main thread's real share is higher than shown and the subagents' lower.
- "Limit per call" applies the measured weights to each call's tokens; it isn't read off the meter call by call. The readings are whole percentages.
Measure your own
npm install -g limitcast
limitcast install # records your limit readings from the status line
# use Claude Code for a day or two, then:
limitcast results # what moves your meter: new vs cached tokens
limitcast report # Pro: tokens by day, project, model and session, and the subagent share
The free version is local-only and never uses your Claude login.
Originally published at limitcast.dev. limitcast is a local-only command-line tool that forecasts when your Claude Code, Codex and Grok usage limits run out.
來源：DEV Community · dev.to