When to use Claude Code subagents (and when they just burn more tokens)

A subagent call is not free - it spins up its own system prompt and tool schemas before it does anything useful, and if the work it's handling would only ever get read once, that overhead can outweigh just doing it inline. The rule that actually holds: a subagent wins when the alternative is exploration that would otherwise sit in your main thread and get rebilled as a cache read on every turn after it; it loses when the work is small, one-shot, or needs to stay part of the same conversation.

What a subagent actually isolates

A subagent runs in its own context window, with its own system prompt and its own tool access, separate from the conversation that spawned it. It does the work, then hands back a result - not a transcript of everything it read, just whatever it chooses to report. That isolation is the entire mechanism: none of the files it opened, commands it ran, or dead ends it explored get added to your main thread's context. Only its final answer does.

That is also the entire tradeoff. Isolation is free when the work being isolated was going to bloat your main thread anyway. It is wasted motion when the work was small enough that it wouldn't have bloated anything.

Why exploration is the cost, not the question you asked

Across 1,037 real Claude Code sessions measured for this project, 93.9% of billed tokens turned out to be cache reads, not fresh input or output. The mechanic behind that number is simple: Claude Code has no memory between calls, so every turn resends the entire conversation so far, and everything already in context gets billed again as a cache read, turn after turn.

Exploratory reads are the worst offenders because they rarely get removed once they've served their purpose. A grep across forty files, a long git log, three files opened to rule out a hunch that turned out wrong - none of that gets deleted from context once you've learned what you needed from it. It just sits there, recharged on every subsequent turn until you /clear. Cache-read cost compounding this way is the same mechanic behind most Claude Code token complaints; subagents are one specific answer to it, not a separate problem.

The break-even math, worked out

Take an exploration cluster comfortably above the threshold this project's own analysis uses to flag offload candidates: 8,000 tokens of reads and tool output, gathered to answer one question, in a session that runs another twenty turns after that. Left inline, that entire 8,000 tokens sits in context and gets rebilled on every one of those later turns - by turn twenty, that's 152,000 cumulative recharged tokens for a question that got answered once. Routed through a subagent that keeps a roughly 1,500-token summary instead (the size this project's own offload model targets), the same twenty turns recharge 28,500 tokens for the identical answer. The gap is not the tokens the subagent spent doing the work - it already paid those once, in its own isolated context, and they never touch your main thread at all. The gap is what your main thread stops paying, over and over, for context it never needed to keep.

This is a modeled example, not a measured one - your own ratio depends on how big the exploration really is and how many turns follow it. The mechanism is what's real: the value of offloading scales with the size of what you'd otherwise be recharging and the number of turns left to recharge it on.

Where this project's own subagent spend actually went

Custom subagents accounted for about 24% of this project's total measured spend across 766 subagent transcripts, and almost every dollar of it inherited Opus by default rather than a cheaper model chosen for the task. General-purpose agents alone were half of that spend, mostly on exploration and research work that a cheaper model would likely have handled just as well. That's a second, additive lever on top of offloading itself: once you're already routing work to a subagent, which model it runs on matters just as much as whether it ran there at all.

A practical decision rule

Two questions do most of the work: how big is what you're about to explore, and will it need to stay part of this conversation once you've learned from it? Big and disposable (a codebase-wide search, a multi-file investigation, anything you're doing to rule things out rather than to keep) is the clearest case for a subagent - offload it, keep a short summary, let the main thread move on. Small or load-bearing (a single file you're about to edit, a decision the rest of the session needs to reference) is usually cheaper handled inline, because there's nothing large enough to be worth isolating and you'd just be paying the summary-writing step for no reason.

When a subagent just adds overhead

None of this makes subagents free by default. Every subagent call pays its own system prompt and tool schemas before it produces anything, and that cost is fixed whether the task inside takes ten tokens or ten thousand. For a small, one-shot read that was never going to compound - open one config file, answer one question, move on - that fixed overhead can cost more than just doing it inline would have, because there was nothing left to recharge across future turns anyway. Coordination has a cost too: a subagent's summary is a lossy compression of everything it saw, so anything the main thread will need in exact detail later belongs in the main thread, not in a report from an agent that has already forgotten the specifics.

FAQ

• When should I use a subagent instead of just doing the work inline? When the work is exploratory (reads, greps, searches) that would otherwise sit in your main thread's context and get rebilled as a cache read on every later turn, and when the session has enough turns left after it for that recharging to add up. Small, one-shot reads and anything the rest of the conversation needs in exact detail are usually cheaper inline.
• Do subagents actually save tokens, or do they just move the cost somewhere else? Both, depending on size. The subagent still pays for the work it does, in its own isolated context - that part doesn't disappear. What it saves is the main thread never having to carry and recharge that raw exploration turn after turn; only a short summary comes back.
• What's the token overhead of spawning a subagent? A fixed cost from its own system prompt and tool schemas, paid on every call regardless of task size. It's mostly invisible on large exploration tasks and can outweigh the savings entirely on small, one-off ones.
• Does using more subagents always reduce cost? No. More subagent calls for small or non-recurring tasks just adds fixed overhead on top of work that wasn't going to compound anyway. The lever is choosing when to delegate, not delegating by default.
• Which subagent types burn the most tokens in practice? On this project's own measured usage, general-purpose agents were the single biggest slice of subagent spend, and nearly all custom subagent types defaulted to Opus rather than a cheaper model matched to the task - a second lever worth checking alongside whether to offload at all.
• Is there a simple rule of thumb? Big and disposable, offload it; small or something the rest of the session needs to reference exactly, keep it inline. The bigger the exploration and the more turns left in the session, the more a subagent is worth its fixed overhead.

Whether a given subagent call was worth it lives in your own transcripts, not in a rule of thumb - how big the reads actually were, how many turns followed, which agent types ended up on Opus for work a cheaper model could have handled. UsageCut's free scan reads that history locally and shows the real breakdown for your own sessions instead of the modeled example above. The full list of context-reduction levers covers what to fix beyond offloading, and the cost calculator is a quick way to see what those sessions are actually costing you before you decide where to spend the effort first.

Made by Neo

UsageCut by ClockedCode - not affiliated with Anthropic. The figures on this page are measured on real Claude Code sessions and labeled measured or estimated where it matters.