Do Claude Code Subagents Burn Tokens? How to Measure It and When They Pay Off

Why are people asking whether subagents burn tokens?

Because a lot of developers have watched their limits disappear and pointed at subagents. A Hacker News discussion of an article titled "Claude Code sends 33k tokens before reading the prompt; OpenCode sends 7k" reached 706 points and almost 400 comments when we checked it. Many commenters blamed subagents for the burn. Some said they now disable subagents entirely, and others noted that subagents start without the parent's context, so they reread files.

A Reddit thread on r/ClaudeAI (archived copy) tells a similar story. The poster had let Claude Code split work across five or six subagents by default, found that each one re-read context and the main agent then spent more time merging results, and switched to a single agent with a narrow task, keeping parallel work for subtasks that don't touch each other. One commenter said a usage app showed subagents taking a very large share of their usage and that they turned them off. Other replies pushed back: subagents work well for unrelated tasks run in parallel with a solid prompt, and the real question is which model they run on. That disagreement is the honest picture, and it's why measuring beats guessing.

How do Claude Code subagents actually use tokens?

According to Anthropic's subagent documentation, each subagent runs in its own context window with its own system prompt, tool access and permissions. It does not see your conversation history or the files Claude already read. Claude writes a delegation message, the subagent works from that, and only its final summary comes back to the main conversation.

A few details matter for cost:

• Same usage limits. The docs say subagents count toward the same usage limits as your main session, and each one spends tokens of its own while it runs.
• What loads at startup. Custom subagents load your CLAUDE.md files and a git status snapshot by default (you can opt out with omitClaudeMd). The built-in Explore and Plan agents start without them.
• Model per subagent. The model field in a subagent's frontmatter accepts haiku, sonnet, opus, a full model ID or inherit. If you set nothing, the subagent ends up on your main conversation's model.
• Tool lists. The tools field is an allowlist. If you omit it, the subagent inherits every tool available to subagents.
• Parallel runs. Background subagents run concurrently while you keep working, up to 20 at once by default.
• Forks are different. A fork inherits the whole conversation instead of starting fresh, so it doesn't pay the cost of rebuilding context, but it carries your full history with it.

Why can subagents cost more?

Every subagent is another model session that you pay for. The main ways that adds up:

1. Fresh context, repeated reads. A subagent that isn't a fork starts with no memory of your session. If it needs the same five files the main agent already read, it reads them again. Anthropic's docs note it "may need time to gather context".
2. Fixed overhead per agent. Each subagent carries its own system prompt, tool definitions and, for custom agents, your CLAUDE.md. A long CLAUDE.md is paid once per agent, not once per session.
3. Fan-out. Five parallel subagents means five context windows. If their scopes overlap, you pay for the same exploration several times, and the main agent then spends more tokens reconciling their answers.
4. Expensive defaults. If you run Opus in the main session and never set a model on your subagents, they follow you onto Opus. The costs page says a switch to Opus also applies to subagents that inherit your session's model.
5. Big summaries. The docs warn that many subagents each returning detailed results "can consume significant context" in the main conversation.

Agent teams, a separate experimental feature where each teammate is a full Claude Code instance, push this further. Anthropic's costs page states that agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode. That figure is about agent teams, not ordinary subagents, so don't apply it to a single Explore call.

Why can subagents cost less?

The other half of the story is the main conversation itself. Anthropic's costs page explains that Claude Code sends your full conversation with every request, so a session that has been open all day makes even a one-line question draw usage for the whole history. Anything that keeps that history small saves tokens on every later turn.

• Verbose work stays out of your main context. Running a test suite, reading logs or fetching documentation produces pages of output. The docs recommend delegating these so the noise stays in the subagent and only a summary returns. You pay for that output once, instead of re-sending it on every message for the rest of the session.
• Cheaper models for cheap jobs. Search, file discovery and log triage rarely need your strongest model. The docs suggest model: haiku for simple subagent tasks, and you can define your own agent named Explore with model: haiku to make exploration cheaper.
• Focused tool lists. A read-only agent with tools: Read, Grep, Glob can't wander off into edits, shell commands or MCP calls, which keeps both its context and its behaviour narrow.
• Scoped jobs finish sooner. A subagent with one clear question and a defined output tends to stop when it has the answer. A generic agent with a vague brief tends to keep exploring.

Here is a minimal example of a cheap, read-only search agent. Generate your own with the Subagent Generator if you'd rather not write the frontmatter by hand.

---
name: code-finder
description: Finds where something is implemented and returns file paths with one-line notes. Use for "where is X handled?" questions.
tools: Read, Grep, Glob
model: haiku
---
Search the repository for the requested symbol, route or behaviour.
Return at most 10 file paths, each with a one-line reason.
Do not paste file contents. Do not suggest changes.

How do you measure what subagents cost you?

You don't need to trust anyone's anecdote, including ours. Claude Code gives you the numbers.

1. Use /usage inside Claude Code

Run /usage. The Session block shows token usage by model for the current session, plus an estimated dollar figure computed at list price (on Pro and Max plans the dollar figure isn't what you're billed). On a Pro, Max, Team or Enterprise plan, the same screen shows an attribution breakdown: recent usage attributed to skills, subagents, plugins and individual MCP servers, each as a percentage of the total, with a toggle between the last 24 hours and the last 7 days. The docs say those figures are approximate and come from local session history on that machine. This is the fastest way to see whether subagents are really your biggest cost.

Run /context too: it shows what is taking up space in your context window, including a long CLAUDE.md that every custom subagent will also load.

2. Use ccusage for your local logs

ccusage is an open-source CLI, not made by Anthropic, that reads the usage data Claude Code stores locally and turns it into daily, monthly, session and 5-hour block reports.

npx ccusage@latest daily
npx ccusage@latest session
npx ccusage@latest blocks

Its documentation doesn't say whether it separates subagent usage from the main session, so use it for totals per day or per session and rely on /usage for the subagent share. To estimate the size of a prompt or a CLAUDE.md before you hand it to five agents, paste it into the Claude Token Counter. For a longer look back at how you use Claude Code, Claude Code Wrapped summarizes your history.

3. Run a simple A/B test

The only number that settles the question for your codebase is a side-by-side run. Pick one real, repeatable task (for example "find every place we validate email addresses and add a missing check to the signup form, with a test"), then run it three ways from a clean start:

1. No subagents. Deny the Agent tool for the session so Claude does everything in the main conversation.
2. One generic subagent. Allow delegation but give the subagent no tool list and no model override.
3. Specialist subagents. A read-only search agent on a cheaper model plus an implementer with only the tools it needs.

For each run, start a fresh session with /clear, use the same prompt and the same main model, and record: total tokens and estimated cost from /usage, the subagent share from the attribution breakdown, wall-clock time, and result quality (do the tests pass, did it touch only the files it should, how many corrections did you have to make). Run each variant at least twice. To stop delegation for variant 1, Anthropic's docs describe a permission deny rule:

{
  "permissions": {
    "deny": ["Agent"]
  }
}

If you want ready-made prompts for the task itself, the Claude Code prompt library has refactor, review and debugging prompts you can reuse as a fixed test input.

When do subagents pay off, and when should you turn them off?

Anthropic's docs suggest staying in the main conversation for iterative back-and-forth, for phases that share a lot of context and for quick, targeted changes, and using subagents for verbose output, enforced tool restrictions and self-contained work that can return a summary.

If your /usage attribution shows subagents taking most of your usage on tasks from the "No" rows, turning them off is a reasonable fix. If it shows them mainly on the "Yes" rows, the better fix is usually a cheaper model and a shorter tool list, not removing them.

Are specialist subagents cheaper than a generic one?

Often, but not always. A specialist with a scoped job, a short tool list and a model matched to the work has less reason to explore, fewer tool definitions in its context and a clearer point at which it's done. A generic agent with every tool and a vague brief can spend tokens finding out what it's supposed to do. That reasoning is why the Agentsforce specialists each ship with a focused tool list and a narrow role, such as a read-only codebase explorer that can only read, grep and glob. Be honest with yourself about the trade-off, though: on a small, single-file task, any subagent, specialist or not, may cost more than just asking the main session. Measure it on your own work before you assume.

Bottom line

Subagents don't burn tokens by accident, they burn them by design: each one is a separate session with its own context. That cost is worth paying when it keeps verbose, self-contained work out of your main conversation, and it's wasted when you split tightly connected work across agents that all reread the same files. Check /usage to see the subagent share, put cheap jobs on a cheap model with a short tool list, and run the three-way test on a real task before you decide to switch them off for good.