Claude Agent vs. Subagents: When to Delegate

When people say "Claude agent," they usually mean one of two very different things:

• The main agent — the long-running session that already has your whole conversation: what you asked for, what it tried, what broke, what you corrected.
• A subagent — a fresh, isolated agent instance dispatched mid-conversation to do one bounded piece of work, then report back.

A subagent can even run a different model than the one that dispatched it. What it never gets is a shared starting point — and that difference is the whole ballgame.

What a subagent actually costs

A subagent has no memory of anything said before it was spawned. If the task needs three paragraphs of "here's what I already ruled out and why," those three paragraphs have to be written into the dispatch prompt — every single time. That's not free: it's tokens, it's latency, and it's a chance for something to get lost in translation between what you actually know and what you bothered to write down.

The payoff is that everything the subagent reads, greps, or tries stays in its context window, not yours. A broad codebase search that touches forty files and produces two useful lines of insight is exactly the kind of work that should happen somewhere else and come back as a two-line answer — not as forty files' worth of noise sitting in the conversation you're trying to keep coherent.

There's one deliberate exception to all of this: a fork, which inherits the entire parent conversation instead of starting fresh. A fork trades away the isolation — it costs the same context a subagent would otherwise save — in exchange for not having to re-explain anything. Reach for one when a task needs so much of what the main agent already knows that writing a self-contained dispatch prompt would cost more than just letting it see everything.

A rule that's held up

Delegate to a subagent when the work is:

• Independent — it doesn't need the judgment calls already made earlier in the conversation.
• Bulky in, thin out — the search/read/run volume is large, but the useful answer is small.
• Parallelizable — three unrelated investigations can run at once instead of serially eating the same context.

Keep it in the main agent when:

• The next step depends on a decision made two messages ago.
• The task is one short, well-scoped edit — spinning up a subagent to change a single line costs more in re-derived context than it saves.
• The user needs to weigh in right now, not after a report comes back from somewhere else.

Named agents change the calculus

Everything above assumes a generic subagent — spun up fresh, given a prompt, and never seen again. You can also define a named agent: a persistent role with its own system prompt and its own tool access, saved once and reused every time you delegate that kind of work. A QA agent that always writes the test first, checks edge cases, and runs the full suite before calling something done. A full-stack dev agent that already knows the project's conventions — which layer owns validation, which folder a new component belongs in — without any of that traveling through the dispatch prompt.

The tool access can be scoped just as tightly as the prompt. Give the QA agent Read, Grep, and Bash — enough to run the suite and inspect output — and leave Edit/Write out of the list entirely: it's not merely told to leave the code alone, it has no tool whose job is rewriting a file. Give the full-stack dev agent Read, Edit, Write, Grep, and Glob instead: built to author changes, not to execute anything. Same underlying model, structurally different capabilities.

Send the exact same one-liner — "add coverage for the new pricing tier" — to each, and they diverge immediately: the QA agent turns it into a test pass, the full-stack dev agent turns it into a feature implementation. Same model, same words in, completely different work out, because the identity behind the agent is doing the deciding, not the prompt.

That convenience has a cost a generic subagent never accumulates: drift. A QA agent whose test conventions changed six months ago and never got updated will confidently keep applying the old ones. A generic subagent can't go stale that way — it has no memory to go stale in, because you rewrite its instructions from zero every time.

Rule of thumb: define a named agent for a role you delegate to often enough that "explaining the role" would otherwise dominate the dispatch prompt — QA, code review, a specific framework's conventions. Reach for a generic subagent for anything that won't recur, or where the task is small enough that writing the one-off context is cheaper than maintaining a standing definition.

The token math

Every dispatch — named agent or generic subagent — starts a fresh context window, so a cold start is unavoidable somewhere. The difference is where the tokens actually go.

A generic subagent's dispatch prompt is written fresh each time, so none of it is reusable across dispatches, and the orchestrating agent spends its own reasoning tokens working out what context that specific task needs. A named agent's system prompt, by contrast, is fixed and identical across every dispatch to that role — which makes it a good candidate for prompt caching. The mechanics: a cache write costs about a quarter more than a normal input token, a cache read runs at roughly a tenth of the price, and the cache stays warm for about five minutes after the last hit (a 1-hour window is available too, at double the write cost).

What that buys you: route the same kind of task through the same named agent a few times in a burst and the system-prompt portion gets cheap fast; route a one-off task through a differently-worded prompt every time and it never gets that benefit. The catch is a length floor, and it moves with the model — north of 500 tokens on the smallest models, up to a few thousand on the larger ones — so a two-line agent identity may not even clear the bar, while a fully fleshed-out one comfortably does.

That's the argument against over-splitting work into subagents by default: every dispatch pays for its own cold start before it does a single unit of real work, so a task cheap enough to finish in the main agent's already-warm context can end up costing more once it's forced through someone else's cold one.

The failure mode to watch for

The mistake isn't using subagents — it's using them as a way to avoid writing down what you actually want. "Based on your findings, fix the bug" handed to a subagent isn't delegation, it's punting the understanding onto something that has none of your context. A good dispatch prompt has to prove the synthesis already happened: file paths, line numbers, what specifically changed and why — not "go figure it out."

Once that's the bar for a dispatch prompt, the tool mostly de-risks itself. If you can't write a self-contained prompt for the subagent, that's usually a sign the task wasn't ready to leave the main conversation yet.