You split your workflow into subagents to save context. Each worker gets a fresh window, does its job, returns a summary. Clean.
Here's the part that doesn't show up in the mental model: every one of those workers re-loads your entire CLAUDE.md hierarchy at startup. Ten subagents means your CLAUDE.md is paid for ten times — before any of them does a single unit of work.
I measured subagent fixed overhead at roughly ~436k tokens per agent in a previous experiment. A commenter (@skillselion) pointed out a variable I'd held constant without pricing it: CLAUDE.md rides along with every custom subagent, so its size gets multiplied by headcount. They're right, and the docs are explicit about it. This post is the follow-up: what exactly loads into a subagent, which agents are exempt, and how to shrink the multiplicand.
What actually loads into a subagent at startup
Per the official subagents doc, a non-fork subagent's initial context contains:
- System prompt — the agent's own prompt plus environment details. Notably not the full Claude Code system prompt.
- Task message — the delegation prompt the main conversation writes.
-
CLAUDE.md files — quoting the doc: "every level of the CLAUDE.md hierarchy the main conversation loads, including
~/.claude/CLAUDE.md, project rules,CLAUDE.local.md, and managed policy files." - Git status — a snapshot from the parent session's start.
-
Preloaded skills — full content of anything in the agent's
skillsfrontmatter field. - Sibling roster — a small system reminder, only when relevant.
The line that matters for budgeting: your user-level CLAUDE.md, your project CLAUDE.md, your .claude/rules/ files without paths frontmatter, and your CLAUDE.local.md all board every subagent you spawn.
The two exemptions — and why you can't add more
The built-in Explore and Plan agents skip CLAUDE.md and git status. The doc's phrasing: "Explore and Plan are the only subagents that omit CLAUDE.md and git status. There is no frontmatter field or per-agent setting to change which agents skip them."
Two consequences:
-
You can't opt a custom subagent out. If your review pipeline spawns 12 custom agents, all 12 carry your full instruction hierarchy. There's no
skipMemory: true. - Read-only research is cheap by design. When the task is "find where X is defined," delegating to Explore genuinely avoids the multiplier. Reaching for a custom agent for pure lookup work forfeits that discount.
The arithmetic
Say your CLAUDE.md hierarchy totals 6,000 tokens — a 400-line project file plus a user-level file plus a couple of unscoped rules. That's unremarkable; project instruction files grow monotonically because nobody ever deletes a rule.
- Single conversation: 6,000 tokens, paid once.
- A 10-agent fan-out (parallel review, migration sweep): 60,000 tokens of CLAUDE.md before any file is read.
- Run that pipeline 5 times a day: 300k tokens/day of pure instruction re-delivery.
In my earlier measurement, per-agent fixed overhead (~436k tokens) dwarfed the content I explicitly embedded (~46k). The CLAUDE.md hierarchy is part of that fixed slice — and unlike the harness portion, it's the part you control.
Measure yours in 30 seconds
Run /context in a session. The Memory files list shows every CLAUDE.md-family file that loaded and what it weighs. That number, times your typical concurrent agent count, is your real instruction overhead per fan-out.
If the number surprises you, the doc's own size guidance is the fix-list.
Shrinking the multiplicand
The memory doc targets under 200 lines per CLAUDE.md file, and warns that longer files both consume context and reduce adherence. Three moves actually reduce the multiplied cost, one popular move doesn't:
1. Path-scoped rules load on demand. Rules in .claude/rules/ with a paths frontmatter field only enter context when Claude works with matching files. A rule about your Terraform layout doesn't need to ride into a subagent that's reviewing TypeScript. This is the highest-leverage move: it subtracts from every agent's startup load.
2. Skills load when invoked. A multi-step procedure ("how we cut a release") doesn't belong in CLAUDE.md at all — the memory doc says to move procedures to skills or path-scoped rules. A skill's cost is its description line until something actually invokes it. One caveat in reverse: a subagent's skills frontmatter field injects the full skill content at startup — preloading is the opposite of lazy-loading, use it only when the agent always needs that knowledge.
3. Delete rules that no longer earn their tokens. I wrote a separate method for finding dead rules. With the multiplier in view, a dead rule isn't one wasted line — it's one wasted line × every agent × every run.
What doesn't help: @path imports. The doc is blunt: imports help organization "but doesn't reduce context, since imported files load at launch." Splitting a 600-line CLAUDE.md into six imported files ships the same 600 lines to every agent, just in prettier luggage.
The checklist
- Run
/context, note total Memory files weight. - Multiply by your typical fan-out size. That's the real number.
- Anything procedural → skill. Anything area-specific → path-scoped rule. Anything dead → deleted.
- Use Explore/Plan for pure research tasks; they're the only free riders.
- Don't confuse imports with savings.
The subagent isn't expensive because it's an agent. It's expensive because it's a full re-reader of everything you never trimmed, times however many of them you launch.
I maintain Rulestack — practical packs of Claude Code skills, hooks, and rules files, kept current against how these tools actually load things. Daily AI-coding-workflow notes on Bluesky: @ai-shop.bsky.social.
Correction (2026-08-24)
This article inherited the ~436k per-agent overhead figure from my earlier measurement, and that figure has since been corrected: it was a face-value sum across a multi-request run, which re-counts the cached prefix on every request. A first-request probe puts the true cold-start fixed cost at 54,154 tokens in the same repository.
The multiplier argument here still holds — your CLAUDE.md hierarchy really is re-delivered into every spawn, and it is still the biggest dial you control — but the fixed slice it sits inside is roughly 8× smaller than stated, so scale the arithmetic accordingly.
Primary sources for this correction:
Top comments (11)
The context multiplier is real. A file that looks small in the parent session can become expensive when every subagent inherits it, and worse, it can spread stale assumptions everywhere. I like splitting global rules from task-specific context for exactly this reason.
Stale assumptions spreading is the cost I underweighted — I framed it as tokens, but a wrong line in a global file gets re-asserted by every agent that inherits it, and each one sounds equally confident. The split you describe is where I landed too. What I still find hard is deciding what is genuinely global; my own file kept accumulating things that were really task-specific.
That is the harder bug than token cost. A stale global instruction does not fail loudly; it becomes inherited confidence. I like treating global agent files as infrastructure: small, reviewed, and suspicious of anything task-shaped.
Is yours review-by-eye, or do you have a heuristic that holds? I keep trying to write that suspicion down as a check and failing at the naming — task-shaped is obvious to a reader and invisible to a linter.
“Reached / not reached / stale” is a strong upgrade because it gives the system vocabulary for future failure. A binary cache check cannot express “green now, broken on Tuesday,” which is exactly the shape teams miss.
I do not have a perfect linter for it. The heuristic that holds best is ownership plus blast radius: global files should describe durable boundaries, while task-shaped assumptions need a local handoff or run note.
That test I can actually apply — 'is this durable' has an answer, where 'is this task-shaped' never did for me. What still leaks past it: lines that were durable when written and quietly stopped being true.
That is the part a linter will miss unless it has time in the model. I would treat durable instructions like dependencies: each one needs an owner, a reason, and some weak freshness signal. Even a “last confirmed on” field would make stale-but-still-valid-looking rules easier to challenge.
We backed into your dependency model by accident: every rule in our agent instructions carries the date and the incident that created it, and that metadata turned out to be the challenge mechanism — "this rule is from June and its premise died in July" is an argument you can only make when rules have birthdays. Owner and reason we have; the honest gap is your freshness field, since nothing in our loop re-confirms a rule that hasn't misfired lately. How were you picturing "last confirmed on" getting produced — I can't see a way to generate it that doesn't need a human, and I'm not sure if that's a bug or the point.
Appreciate the thorough follow-up, this is exactly the pricing I was hoping someone would do, and the imports warning is the trap most people walk into: "ships the same 600 lines to every agent, just in prettier luggage". One refinement for the next measurement: split cache-read tokens from fresh tokens. The 2.1.229 changelog describes staggering sibling agent startup in workflow fan-outs so later siblings read an already-cached prefix, which suggests the tenth agent's CLAUDE.md delivery can bill at cache-read rates rather than full price. The token count is real either way, but the dollar multiplier may come in below headcount, and that changes which of your three moves pays best. Also a limit on move one: path-scoped rules only subtract when the fan-out touches disjoint areas. A 12-agent review of the same diff matches the same paths 12 times, so for review pipelines deletion is the only lever that actually shrinks the multiplicand.
You're right, and I checked the changelog rather than trusting my memory of it: 2.1.229 contains "Improved workflow fan-outs to stagger same-prefix sibling agents so subsequent agents read the cached prompt prefix instead of re-paying it", with
CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS=0to disable. So the dollar figure in the post is an upper bound for staggered fan-outs: the token count holds, the price does not. Splitting cache-read from fresh is the right refinement and I'll do it in the next measurement. Worth adding that my own release note for 2.1.229 recorded it as fix-only, which this shows was wrong.