Why Claude Code Sub-Agents Cost 7x More Tokens (And When to Use Them)
Anthropic's docs confirm Claude Code sub-agents can burn 7x more tokens than a normal session. Here's why, and when they're still worth it.
Why do Claude Code sub-agents use so much more tokens?
Anthropic’s own documentation states that agent teams can use roughly seven times more tokens than a standard Claude Code session when teammates run in plan mode. The reason comes down to how sub-agents are built. Each one spins up as a separate Claude instance with its own context window, and that window gets loaded with a standard set of injected context every time. None of that is shared or cached against your main session. You’re effectively paying to duplicate context across multiple parallel instances of the same model, and that cost compounds the more sub-agents you delegate to.
TL;DR
- Anthropic’s documentation confirms that agent teams running in plan mode can consume around seven times the tokens of a normal single-session conversation.
- The extra cost comes from separate context windows, since each sub-agent runs as its own Claude instance with its own injected context rather than sharing the main session’s cache.
- Sub-agents work well for broad, low-context tasks like parallel searches or exploration, but get expensive fast when you hand them work that requires deep, specific context.
- Built-in explore and plan agents actually receive less context than custom sub-agents. They skip your CLAUDE.md file entirely unless you restate the rules directly in the task prompt.
- Sub-agents never inherit conversation history, output style, or auto-memory from the main thread, so anything the task depends on has to be spelled out explicitly.
- If a side task genuinely needs the full context of your conversation, forking the conversation is usually cheaper and more reliable than delegating to a sub-agent.
- Connector and MCP token costs are a related but separate issue: tool search loads only tool names by default now, pulling full schemas in on demand, which has made adding more MCP servers far less costly than it used to be.
What actually gets passed to a sub-agent?
When you delegate a task to a sub-agent, it receives its own system prompt, whatever instructions you wrote for the task, and (in most cases) the full CLAUDE.md hierarchy. That’s roughly it. Sub-agents don’t get your conversation history. They don’t inherit output style settings. They don’t receive the auto-memory that gets injected into your main thread over time, and they don’t see files that have already been read into context earlier in the session.
This matters because it’s easy to assume a sub-agent “knows” what the main session knows. It doesn’t. If your CLAUDE.md contains a rule the sub-agent absolutely needs to follow, you often have to restate that rule directly in the task prompt, especially for the automatically-delegated explore and plan agents, which skip receiving CLAUDE.md altogether. There’s no configuration fix for this right now. The workaround is manual: repeat the critical constraints in the instructions you hand off.
When are sub-agents actually worth the extra tokens?
Sub-agents make sense when the task is broad and doesn’t need much context to complete. Parallel investigation, wide searches across a codebase, or scanning for information are good fits, because the sub-agent can do useful work with a fairly thin instruction set and minimal injected context.
Sub-agents get expensive when you ask them to do something rather than just look for something, particularly when the task depends on a lot of accumulated context from earlier in your session. In that case, you’re paying to reconstruct and pass along context into an uncached, separate window running on the same underlying model as your main session. That duplication is where the multiplier comes from.
A practical rule of thumb: keep specific, context-heavy tasks in your main session. Reserve sub-agents for exploration and parallelized searching where the payoff (speed, breadth) outweighs the cost of standing up a fresh context window.
Is forking the conversation a better alternative?
For side tasks that genuinely require the full context of what you’ve been working on, forking the conversation is often more efficient than delegating to a sub-agent. A forked conversation inherits the complete context of the original thread, so you’re not paying to reconstruct that context from scratch inside a new, uncached instance. Sub-agents are built for isolation and parallelism, not context inheritance, so if your task depends heavily on everything that’s already happened in the session, forking keeps that continuity without triggering the sub-agent token multiplier.
How do MCP servers and connectors add to the token bill?
Sub-agents aren’t the only place token costs hide. Connectors and MCP (Model Context Protocol) servers used to carry a real tax too, but the situation has shifted.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
Previously, common advice was to disconnect MCP servers you rarely used, because their full schemas were loaded into context on every session regardless of whether you needed them. That advice is now outdated. Tool search is on by default, which means only tool names load upfront (a small footprint, in the range of roughly 120 tokens per tool), and full schemas get pulled in only when a tool is actually invoked. You can verify this yourself by running /context to see what your MCP servers are costing in tokens, and /mcp to confirm which ones are loading on demand rather than upfront.
Connectors behave differently and can still be a real cost if left on default settings. When connector tool access is set to “auto,” tool definitions for every enabled connector can load into context on every single message, and some users have reported this costing thousands of tokens per session. The fix is to go into chat mode settings, open connectors, and switch tool access to load tools only when needed rather than loading them all upfront. It’s also worth reviewing routines specifically, since new routines get every connector enabled by default, which is both a cost problem and an unnecessary security exposure. Removing connectors you don’t need for a given routine trims both risk and token spend.
Does compaction or session length change how expensive agents get?
Yes, indirectly. Claude Code compacts a conversation once it reaches the model’s context limit, and that behavior is no longer governed by a fixed percentage threshold you can override, it depends on the model and current documented limits. This matters for sub-agent economics because the longer and more context-heavy your main session gets before compaction, the more expensive it becomes to hand off context-dependent work to a sub-agent instead of just continuing in the main thread. It also means editing your CLAUDE.md file mid-session won’t take effect until the session restarts, clears, or compacts, since that file is read once at session start and held in memory.
Frequently Asked Questions
Why do Claude Code sub-agents cost more tokens than the main session?
Each sub-agent runs as an independent Claude instance with its own context window and its own injected standard context. None of this is shared with or cached against the main session, so running multiple sub-agents means paying for multiple separate context loads rather than one shared one. Anthropic’s documentation puts the multiplier at around seven times for agent teams running in plan mode.
Do sub-agents see my CLAUDE.md file automatically?
Custom sub-agents typically receive the full CLAUDE.md hierarchy along with their own system prompt and task instructions. Built-in explore and plan agents, the ones Claude delegates to automatically, skip receiving CLAUDE.md entirely, so any rules they need to follow must be restated directly in the task prompt.
When should I avoid using sub-agents?
Avoid them for tasks that require deep, specific context from your existing conversation, since reconstructing that context in a separate, uncached window is where the token cost multiplies. They’re better suited to broad exploration or parallel searches that don’t need much prior context to be useful.
Are MCP servers still expensive to keep connected?
Not as much as they used to be. Tool search now loads only tool names by default, with full schemas pulled in on demand, so adding more MCP servers has a much smaller impact on your context window than in the past. Connectors set to automatic tool access are the bigger current risk, since they can load full tool definitions into every message unless switched to load-on-demand.
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
What’s a cheaper alternative to spinning up a sub-agent?
If a task depends on context already built up in your conversation, forking the conversation is usually more efficient. A fork inherits the full existing context, avoiding the need to reconstruct and re-inject that context into a fresh, separate window the way a sub-agent requires.