Agent Lore

Why subagents cost more than they look

A subagent is a fresh context window running its own loop. That means:

1. It re-sends its own system prompt and tool definitions. No sharing with the parent.
2. It does its own exploration, often re-reading files the parent already read.
3. Its result comes back into the parent's context, which the parent then re-sends on every subsequent turn.

Three agents exploring a codebase in parallel do not cost one-third each. They cost roughly three full explorations, plus the summaries flowing back.

When the arithmetic works

Subagents win when the alternative is worse, not when they are cheap.

Good trade: context isolation. Searching a large codebase generates thousands of tokens of dead ends. In the main conversation those stay in context and get re-billed on every subsequent turn for the rest of the session. In a subagent, they evaporate and only the answer returns.

In main context:   8,000 tokens of search noise × 40 remaining turns
                   = 320,000 re-sent input tokens

In a subagent:     8,000 tokens once, 300-token summary returns
                   = 8,000 + (300 × 40) = 20,000

That is a 16× saving, and it grows with session length.

Good trade: genuine parallelism. Four independent investigations that would otherwise run in sequence. You pay four times the tokens to save three-quarters of the wall-clock time. Whether that is worth it depends on what your time costs.

Bad trade: sequential dependency. If agent B needs agent A's output, you have paid for two cold starts to do one job. Keep it in one context.

Bad trade: trivial work. Spawning an agent to read one file costs more in setup than doing it inline.

Routing subagents down a tier

The strongest cost move: subagents doing mechanical work do not need the frontier tier.

Main agent (planning, synthesis):   frontier tier
Search / extraction subagents:      fast tier

At a 5× spread between tiers, running fan-out on the fast tier while keeping the orchestrator on the frontier tier usually costs less than doing everything in one frontier context, because you also avoid the context bloat.

The rule

Reach for a subagent when the work will generate a lot of output you do not want to keep, or when independent tasks can genuinely run at once. Do not reach for one to save tokens on a single well-scoped question. That is where it costs you.

See also: Parallel Agents Pattern · Single Agent or Subagents? · Context Management