Claude Code can delegate a task to a subagent — a separate instance that runs with its own context window, does the work, and returns a summary instead of its raw tool output. The pitch is simple: a 40-file grep-and-read exploration doesn’t need to live in your main conversation’s context; let a subagent eat that cost and hand back the three facts you actually needed. A week of real feature work with it, on a mid-sized Node/Postgres service, is enough to say where that pitch holds up and where it doesn’t.
Where it genuinely pays off: open-ended research
The clearest win: “where in this codebase does X happen, and what calls it” on a repo you don’t have memorized. Spawning a search-focused subagent for that keeps dozens of file reads and grep hits out of the main session’s context entirely — you get back a file:line table, not the scaffolding that produced it. On a repo with a few hundred files, that’s the difference between a context window that’s still fresh after an hour of work and one that’s already asking to summarize.
This matters more than it sounds: context that fills up with search noise doesn’t just cost tokens, it pushes earlier decisions and constraints further back, where they’re more likely to get contradicted later in the same session. Keeping exploration out of the main thread is a correctness benefit, not just a cost one.
Where it’s a wash: small, bounded edits
For a single-function rewrite or a one-line fix, delegating to a subagent adds a full round trip — spin up fresh context, re-derive what the task even is from a cold prompt, do the edit, report back — for work that would’ve taken fewer total tokens done inline. The break-even point, in practice, landed somewhere around “does this touch more than 2-3 files, or does it need actual exploration first.” Below that line, delegating is pure overhead dressed up as delegation.
The other place it’s a wash: when the task needs the conversation’s accumulated context — a decision made three messages ago, a constraint the user mentioned in passing, a convention established earlier in the session. A fresh subagent doesn’t have any of that. It starts cold. If the prompt handed to it doesn’t restate every relevant fact explicitly, it will make a locally-reasonable choice that’s wrong for the actual situation — not because the subagent reasoned badly, but because it was never told the thing that would have changed its answer.
The failure mode worth knowing: confident wrong summaries
The sharper issue: a subagent’s final report describes what it believes it did, not necessarily what actually happened on disk. Most of the time these match. Occasionally, on a task where the subagent hit an unexpected branch (a lint failure it silently worked around, a test it skipped, a file it created instead of edited), the summary still reads as confident and complete — because from the subagent’s own vantage point, it is. Nothing about the report format distinguishes “I did exactly this” from “I did something adjacent to this and I’m describing it as if it matches.”
The practical mitigation that actually worked: treat every subagent
report as a claim, not a fact, and check the actual diff before
reporting the parent task done. This isn’t a knock specific to Claude
Code’s implementation — it’s the generic cost of delegation to anything
that can’t show its work inline. The fix costs one git diff; skipping
it costs a feature that looked finished and wasn’t.
Verdict
For research and multi-file exploration on an unfamiliar area of a codebase: genuinely useful, not a gimmick — the context savings are real and compound over a long session. For anything small enough to just do directly, or anything that leans on context only the main conversation has: skip it, and don’t let “delegate more” become a reflex just because the tool exists. The rule that held up all week: delegate the search, do the surgery yourself, and always check the diff.
Used subagents differently and found a sharper line than “small vs.
exploratory”? Drop it in #ai on Discord.