A subagent runs in its own separate context window and returns only a summary to the main agent. The heavy intermediate tokens - large file reads, MCP documentation, search output - never enter the parent conversation.
Why use it
Exploration is expensive - Anthropic notes a single debugging session or codebase exploration can consume tens of thousands of tokens, and reading an MCP server’s API reference is the same kind of load. Done in the main window, that clutter persists for the rest of the session and crowds out the task (see lost in the middle). Done in a subagent, the parent receives only the distilled result.
When to reach for it
- A task needs a large doc or many files read, but the main loop only needs the conclusion.
- You are surveying or researching an area before editing - fan the lookup out, keep the answer.
- Output would otherwise be verbose and stay irrelevant after the immediate question is answered.
- A skill picks
context: forkto hand a stage off this way - see Claude Code skill composition for how a skill’s ownSKILL.mdcontent becomes that subagent’s prompt.
The parent conversation never pays for tokens it didn’t need - the payoff context engineering is chasing. Observation masking and LLM summarization are the other two levers for the same goal; see prune the log, not the window for how they compare on cost.