Claude Code Subagent Token Cost: The Preamble Never Stops

A number has been circulating for about ten months: every Claude Code subagent you spawn costs roughly 20,000 tokens before it does any useful work.

I measured it. Across 856 subagent spawns from a month of production work, the median context loaded before the first useful token is 24,858 tokens. The folklore is right, and if anything it undersells the number.

You do not pay it once. Every turn the subagent takes re-reads it at a tenth of the rate, so the number above is an entry fee on top of a running meter.

Why the Claude Code subagent preamble is a recurring cost

Everyone budgets the preamble as a one-time spawn cost. It is a recurring one, and the recurrence is the whole bill. Call that mistake Preamble Fixation: treating a cost that recurs on every turn as if it were paid once, at spawn.

The mechanism is in Anthropic's caching documentation and nobody seems to have priced it. A subagent's preamble sits at the head of its prefix - the subagent context overhead you pay before it does anything useful. Every turn after the first re-reads that prefix at the 0.1x cache rate. So a 24,858-token preamble costs about 2,486 billed-equivalents on every single turn, forever, in addition to the 1.25x write you paid to put it there.

Measured on the first call alone, the cost is flat, which is what made this easy to miss. Median preamble bill by turn bucket:

Nine percent of variation across a turn range that spans two orders of magnitude. If you stop there, as I did in my first draft, the preamble looks like a fixed fee that gets amortised into irrelevance by any agent that runs a while.

Add the re-reads and it stops looking like that. Every turn carries the preamble again at 0.1x, so the lower bound on what a preamble costs across a subagent's life is 1.25P + 0.1P(T-1):

About a quarter of the bill, at every scale. That apparent collapse from 19% to 1% was an artifact of measuring one turn out of thirty-two.

Two things follow, and they point in opposite directions from the usual advice. Deleting subagents is bounded, because you only recover the preambles of the agents you removed. But trimming the preamble is worth more on long-running agents, not less, because you avoid re-reading the trimmed tokens on every turn. Cutting 5,000 tokens of inherited CLAUDE.md from a 60-turn agent saves about 35,750 billed-equivalents, or 6% of that agent's bill.

This directly extends part 3 of this series, which argued the architecture: each subagent burns its own context so the parent does not have to. That argument still holds. What it never did was price the isolation, and the price tag it guessed at was wrong in both directions.

Where the 20,000-token number actually came from

Before trusting a number, find out who measured it.

Nobody did.

The figure traces to a single post by Amit Kothari on 11 October 2025, which states that tasks and subagents "start with roughly 20,000 tokens of context loading before your actual work begins." There is no citation and no methodology. It is presented as an observed pattern.

On 31 July 2026 the same author added an update: the number "is not a constant, and on a machine with a mature instruction file it reads low." He then measured 111,253 tokens for a general-purpose agent that made zero tool calls.

So the most-cited number in subagent cost discussion is an uncited assertion that its own originator has since withdrawn, replaced by a measurement 5x higher.

Anthropic has never published a fixed per-spawn figure.

It survived ten months because the claim was never decomposed into components anyone could check.

How I measured 856 Claude Code subagent spawns

I went looking because this blog's article pipeline dispatches nine subagents per post, and I had never checked what that costs. Claude Code writes every session to disk as JSON Lines. Subagent turns land in separate transcripts under subagents/agent-ID.jsonl, and every assistant record carries a usage block with the fresh, cache-write and cache-read counts already split out.

The corpus is 856 subagents across 193 sessions and 64 projects, recorded between 2026-07-10 and 2026-08-13, on Sonnet 5, Opus 5, Opus 4.8 and Haiku 4.5. Total input context is 2.62 billion tokens.

Every figure here is a snapshot, and the corpus does not hold still. Writing this article added three more subagents to it, because the research and review agents for this post wrote themselves into the ledger I was measuring. I froze the count at 856 rather than chase my own tail.

Three definitions, stated plainly so the numbers are checkable.

Spawn preamble. Every input token present on the subagent's first assistant turn: system prompt, tool definitions, injected skill content, and the dispatch prompt. The same accounting applies to what a plugin injects into a main session, which I measured separately in the Superpowers setup and cost walkthrough. This is what "N tokens before it does any work" means as a claim about context occupancy.

Billed-equivalent input tokens. Context tokens are not billed uniformly. Anthropic prices a 5-minute cache write at 1.25x base input, a 1-hour write at 2x, and a cache read at 0.1x. So I convert everything to full-price-input-token equivalents:

billed_equivalent = fresh + 1.25*write_5m + 2.0*write_1h + 0.1*cache_read

Two limits on that unit. Output tokens are excluded, and output bills at roughly 5x input, so every "share of the bill" figure below understates how small the preamble really is. And the corpus mixes model tiers whose input prices differ by up to 15x between Haiku and Opus, so this is a unit of occupancy, not a currency. It travels well for the preamble specifically: median preamble bills are 15,948 on Sonnet 5, 15,887 on Opus 5, 14,776 on Opus 4.8 and 15,559 on Haiku 4.5. Lifetime bills do not travel at all, ranging from 175,114 to 463,905 across the same tiers.

Turn. One assistant response inside the subagent's own loop.

What this corpus cannot tell you: whether fanning out is cheaper than not fanning out. I ran that comparison and got a 93x difference between sessions that spawn and sessions that do not. That number is worthless. Sessions that spawn subagents are long orchestration sessions. The confound swamps the effect. Testing the widely cited multi-agent overhead multipliers needs a controlled experiment this data cannot provide, so I am reporting the discard rather than the number.

It is also one operator's corpus. Treat the distributions as a well-measured sample of one working style, not a population estimate.

The wrong way: budgeting subagent spawn count

This is the reasoning Preamble Fixation produces. It sounds disciplined.

Each spawn costs about 20,000 tokens of overhead. My pipeline dispatches nine subagents per article. That is 180,000 tokens of pure overhead before any work. I should consolidate to four agents and cut the overhead by more than half.

Every sentence is arithmetically correct. The conclusion is close to worthless.

The median preamble bill is 15,771, and that pooled figure hides two groups: 13,205 for the 456 spawns that hit a warm cache and 23,439 for the 400 that did not. Both matter later. For now the only number the consolidation argument needs is the pooled one.

MEDIAN_PREAMBLE_BILLED = 15_771   # measured, billed-equivalent input tokensMEDIAN_AGENT_BILLED = 372_369     # measured, one subagent's whole lifetime# Percent of pipeline cost saved by removing agents. Preamble only.def consolidation_saving(agents_before: int, agents_after: int) -> float:    removed = agents_before - agents_after    saved = removed * MEDIAN_PREAMBLE_BILLED    total = agents_before * MEDIAN_AGENT_BILLED    return 100 * saved / totalprint(f"9 -> 4 agents: {consolidation_saving(9, 4):.1f}% saved")print(f"9 -> 2 agents: {consolidation_saving(9, 2):.1f}% saved")print(f"9 -> 1 agent:  {consolidation_saving(9, 1):.1f}% saved")

9 -> 4 agents: 2.4% saved9 -> 2 agents: 3.3% saved9 -> 1 agent:  3.8% saved

Deleting eight of nine subagents saves under 4% of the bill and costs you the context isolation that was the reason to spawn them in the first place. That 4% is the ceiling on the whole strategy, and it does not move.

Worse, consolidation usually raises turn count per agent. You cut nine preambles down to four and handed each survivor roughly twice as much work to do.

The right way: forecast turns, and price the preamble per turn

Same 856 subagents, bucketed by turns, with what they actually cost.

Those rows sum to 854, not 856. Two subagents ran two turns each and fall below the smallest bucket. They are in every other figure in this article.

Share columns elsewhere in this article are the median of each subagent's own share, not the ratio of two medians. Medians do not divide, so the two differ, sometimes by several points.

A subagent that runs 81 turns or more costs 23x what a 3-to-5-turn one costs. Roughly a quarter of both bills is preamble, so the preamble scales with the work rather than sitting beside it.

You cannot know turn count at dispatch. You can know your own priors.

This is the obvious objection to any rule built on turn count, and it is correct. Turn count is emergent. You find out afterwards.

But you do not need a prediction. You need a prior, and a month of your own transcripts is a good one. These are my eleven most-used agent types, sorted by how long they run:

The preamble column sits between 13,690 and 24,238 regardless of what the agent does, while the lifetime column spans 12.6x.

Those eleven types cover 320 of the 856 spawns. The rest are one-off and cross-project agents that never repeat often enough to give a usable median. This method works for agents you run over and over. For the one you are about to write for the first time it tells you nothing at all. A verifier that historically runs 56 turns will not notice its preamble. A detector that runs four will spend an eighth of its budget arriving. Build the table for your own fleet.

Why subagent spawns hit a warm cache half the time

Anthropic's documentation says a subagent starts "with no cache hits on its first call." That is right about a subagent in isolation. Across 856 first calls it holds 46.7% of the time, because subagents are almost never in isolation.

456 of 856 subagents - 53.3% - hit a warm cache on their first call, reading a median of 16,217 tokens at a tenth of the price.

Splitting first calls by whether another subagent started within the 5-minute cache window shows why.

Read the right-hand column, not the totals. The two groups carry different-sized preambles, 23,246 median context tokens for the lone ones against 26,313 for the batched, so their totals are not comparable. Per context token a lone spawn pays 2.2x. That 1.250 is exactly the 5-minute cache-write multiplier, which is what a pure cold start should cost.

Note the 25.1% floor. Even with no sibling inside the window a quarter of spawns are warm, and I cannot explain it. Candidates are the parent's own prefix, a sibling just outside five minutes, and concurrent sessions in the same directory. Whatever it is, the baseline is 25.1%, not zero.

Two subagents share a cached prefix only if they match on model and tools

This is the part I have not found published, and my first attempt at it was wrong.

Here is the full partition of the 413 batched spawns. The counts reconcile to the 345 warm calls the corpus-level numbers imply, which the version I published first did not.

Row three is built-in agents like general-purpose and Explore, which have no definition file for me to read, so I cannot say what tools they declared. They carry most of the warmth in that group and I can say nothing about why.

Inside the 46 I can classify, the split is stark:

Prompt caches do not cross models, so a cross-model sibling cannot share a prefix; none of the 21 cross-model spawns in that group was warm. On 46 spawns, model and tool set look like the gate.

Take the number with the caution it deserves. One transcript moving in the top row takes it from 94% to 89%. And 1 of 28 sits below the 25.1% floor from the previous section, which should not happen if whatever warms a lone spawn is ambient - those spawns have more nearby activity, not less. I have no explanation for it. Treat the finding as provisional.

Anthropic's hierarchy caches tools, then system, then messages. Warm spawns read a median 16,217 tokens, and three to five tool schemas come to roughly 3,000 to 5,000 tokens at Systima's measured rate of about 1,000 tokens per tool. The shared prefix runs about 4x past anything the tools block can account for, so it must extend into system - the inherited CLAUDE.md and harness prompt every agent receives - and diverge only at the agent's own instructions. The tools: block is the gate. Differ there and you lose everything behind it.

In practice the effect is small. Across my own definitions there are five distinct tool signatures for twelve agents, and the preamble tracks them only weakly: 12,743 median context tokens for the three-tool agents against 13,712 for the five-tool ones. That is 969 context tokens, and on a long-running agent the re-reads make it worth roughly ten times that. general-purpose sits at 36,893, but it is a built-in with a different system prompt, so that gap is not a controlled comparison and not a field you edit.

So tools: matters as a gate rather than as a payload. Trimming it saves you almost nothing directly. Matching it across the agents in one fan-out is what buys the shared prefix, and that is worth more than the trimming. Trimming also carries the same risk consolidation does: an agent stripped of WebFetch will spend extra turns working around the gap, and turns are the axis that owns the bill.

A separate Systima measurement put tool schemas at 99,778 characters across 27 tools, and a subagent receiving 24 of them would carry 20,000 to 25,000 tokens of schema alone. That is a real configuration and it is not mine. My agents declare three to five tools, so tool schemas do not dominate my 24,858 median. Inherited CLAUDE.md, injected skill content and the system prompt do, which is why Systima's configuration and mine land in the same range by completely different routes. Kothari's 20,000 cannot be compared to either, because it was never decomposed into components at all.

flowchart TD
    A["Spawn a subagent"] --> B{"Prior spawn inside<br/>the 5-minute window?"}
    B -->|"No"| C["Lone: 25.1% warm<br/>n=443<br/>1.250 billed per context token"]
    B -->|"Yes"| D{"Same model AND<br/>same tools block?"}
    D -->|"Yes"| E["17 of 18 warm<br/>identifiable cross-type only"]
    D -->|"No"| F["1 of 28 warm<br/>identifiable cross-type only"]
    C --> G["Preamble is ~25% of the bill<br/>at every turn count"]
    E --> G
    F --> G
    G --> H["Re-read at 0.1x every turn<br/>~2,486 billed-equiv per turn"]

    style A fill:#4A90E2,color:#FFFFFF
    style B fill:#7B68EE,color:#FFFFFF
    style C fill:#FFA07A,color:#2C2C2A
    style D fill:#7B68EE,color:#FFFFFF
    style E fill:#6BCF7F,color:#2C2C2A
    style F fill:#E74C3C,color:#FFFFFF
    style G fill:#FFD93D,color:#2C2C2A
    style H fill:#C2185B,color:#FFFFFF

Batching a fan-out inside the window saves less per agent than deleting the agent would. On my own pipeline the batched spawns paid 11,173 against 16,261 for the lone ones, so batching recovers about 5,100 billed-equivalents where deleting the agent recovers all 15,771 of its preamble. Batching is still the better move, because it is a scheduler change and deleting an agent costs you the isolation you spawned it for. Neither escapes the ceiling the consolidation calculation already set.

Prior work found the same effect from other directions. Claude Code issue #50213, filed in April 2026, is the narrowest version: one subagent respawned over and over inside the window, splitting about 5,400 read to 4,700 re-written every time. JetBrains hit it from the scheduling side on their own worker system three months later, reporting a cache-read share of tokens of 84.8% inside the window against 1.9% outside it, and a 73% cost gap. That is a different measurement from mine - their share is of tokens, mine is of first calls - and their system is not Claude Code. What I can add is the model-and-tools mechanism, and 856 spawns of eleven agent types.

What the original subagent cost estimate got wrong

Part 3 priced subagents in a section called "The Cost Profile: What You Are Trading". Three of its claims do not survive this measurement. Two I reasoned my way into. The third I repeated from other people's posts without checking, which is worse.

"Each subagent starts with roughly 10,000-20,000 tokens of base context." Part 3 said that was the figure "before any task content is added"; my 24,858 median includes the dispatch prompt, so the two are not measuring the same thing. Net of it the median is 23,897, still above the band. But part 3 was wrong about occupancy and accidentally right about money: in billed-equivalents the median preamble is 15,771, which sits inside the 10,000-20,000 band it guessed at.

"Subagents provide zero amortization benefit on repeated similar queries because each call resets to a fresh context." Half right, and I collapsed two different things. Part 3 was correct that there is no context amortization: the fifth researcher still knows nothing the first one learned. It was wrong that there is no cache amortization. A same-type respawn inside the window is 89.4% warm (n=293), so the orchestrator that spawns a researcher five times in five minutes pays one write and four reads, not five writes.

I then billed myself for it. This blog's pipeline spaces its subagents out, and part 3 said that spacing was free. 155 of its 245 spawns went out with no sibling inside the window, at a median preamble of 16,261 billed-equivalents against 11,173 for the 90 that went batched. That is about 789,000 tokens of avoidable premium - which is 0.65% of what those 245 subagents cost. I am reporting it because it is a free fix, not because it is a large one. Some of those 155 were dependency-ordered and could not have been batched: a reviewer cannot run before a draft exists. Whatever was merely serialised by habit is the recoverable share, and I have not separated the two.

"Running three parallel subagents uses roughly 3-4x the tokens of a single sequential session." I cannot find a primary source for 3-4x. Anthropic's published numbers are 4x for agents against chat and 15x for multi-agent against chat, both from a 2025 web-research workload on retired models. The only independent measurement on Claude Code reports a range of 2.6x to 5.9x.

Part 3's citation for that claim was worse than unsupported. It attributed the figures to "Princeton NLP research" at arXiv:2501.12380. That identifier belongs to MMVU: Measuring Expert-Level Multi-Discipline Video Understanding, a video benchmark with no connection to multi-agent systems. The Cemri et al. paper it meant is Why Do Multi-Agent LLM Systems Fail? (arXiv:2503.13657), the authors are at UC Berkeley, and it contains none of the three figures part 3 attributed to it. What it does say is weaker and directional: multi-agent systems' "performance gains on popular benchmarks are often minimal." Part 3 now carries a correction. I wrote the opening section of this article about not trusting numbers whose provenance nobody checked, and the worst example in it was mine.

What part 3 got right is the architecture. The Subagent Contract - scoped input, isolated context, summary returned - is still the reason to delegate. The Context Curation Loop from part 1 is still how you decide what enters a context. What changed is the price tag stapled to them.

How to measure Claude Code subagent token cost on your own machine

This is the smallest useful version. It reproduces three of the headline numbers; the turn buckets and cache-window cuts are a few more lines against the same records.

"""Report subagent spawn cost from local Claude Code transcripts."""from __future__ import annotationsimport globimport jsonimport osimport statistics as stROOT = os.path.expanduser("~/.claude/projects")PATTERN = os.path.join(ROOT, "**", "*.jsonl")SUBAGENT_DIR = f"{os.sep}subagents{os.sep}"# Anthropic cache pricing, as multiples of base input price.WRITE_5M, WRITE_1H, READ = 1.25, 2.0, 0.1def first_usage(path: str) -> dict | None:    """Return the usage block of a subagent's first assistant turn."""    with open(path, encoding="utf-8", errors="replace") as fh:        for line in fh:            line = line.strip()            if not line:                continue            try:                record = json.loads(line)            except json.JSONDecodeError:                continue            if record.get("type") != "assistant":                continue            message = record.get("message")            if isinstance(message, dict) and isinstance(message.get("usage"), dict):                return message["usage"]    return Nonedef split(usage: dict) -> tuple[int, int, int, int]:    """Return (fresh, write_5m, write_1h, cache_read) for one usage block."""    created = usage.get("cache_creation") or {}    w5 = created.get("ephemeral_5m_input_tokens", 0) or 0    w1 = created.get("ephemeral_1h_input_tokens", 0) or 0    if not (w5 or w1):        w5 = usage.get("cache_creation_input_tokens", 0) or 0    return (        usage.get("input_tokens", 0) or 0,        w5,        w1,        usage.get("cache_read_input_tokens", 0) or 0,    )def main() -> int:    # Match the directory, not the substring: a repo path containing the word    # would otherwise pull in every main-session transcript you own.    files = [f for f in glob.glob(PATTERN, recursive=True) if SUBAGENT_DIR in f]    preambles, billed, warm, skipped = [], [], 0, 0    for path in files:        try:            usage = first_usage(path)        except OSError:            skipped += 1            continue        if not usage:            skipped += 1            continue        fresh, w5, w1, read = split(usage)        preambles.append(fresh + w5 + w1 + read)        billed.append(fresh + WRITE_5M * w5 + WRITE_1H * w1 + READ * read)        warm += read > 0    if not preambles:        print(f"No subagent transcripts found ({skipped} files skipped).")        return 1    n = len(preambles)    print(f"subagents            {n}  ({skipped} skipped)")    print(f"median preamble      {st.median(preambles):,.0f} context tokens")    print(f"median billed-equiv  {st.median(billed):,.0f}")    print(f"warm on first call   {100 * warm / n:.1f}%")    return 0if __name__ == "__main__":    raise SystemExit(main())

My 53% warm rate just describes how I fan out. Yours will differ. If you mostly dispatch one agent at a time, expect something near the 25.1% floor. What is worth watching is your own rate over time: if it falls while your spawn pattern is unchanged, something started spacing your spawns out. If your median preamble is far above 25,000, look at your CLAUDE.md hierarchy, which subagents inherit in full, and at how many tools your agents declare.

This is the same argument as part 7 on observability: nobody was hiding this data. It has been sitting in your session directory the whole time, in a format json.loads will read.

Is fanning out worth the tokens? The strongest counter-argument

Anthropic's own multi-agent research is the strongest objection.

Anthropic reported that token usage alone explains 80% of performance variance on their BrowseComp evaluation, and that a multi-agent system outperformed a single-agent baseline by 90.2% on their internal research eval. If tokens buy performance, then "overhead" is a category error. You are not wasting tokens by fanning out. You are purchasing capability, and parallelism is simply a way to spend more tokens at once.

Variance explained is not efficiency. "More tokens produce better results" says nothing about whether these particular tokens do. A preamble re-read on turn 40 is the same tool schemas arriving again.

Nor does the workload transfer. That result is open-ended web research from June 2025, on an Opus 4 lead with Sonnet 4 subagents, both retired. Applying a research-agent multiplier to a coding harness is extrapolation. The 90.2% is a relative improvement on an unpublished internal eval scored by a model, with no stated sample size.

And the controlled version of the experiment goes the other way. Tran and Kiela (arXiv:2604.02460, April 2026) held thinking-token budgets constant and found single-agent systems "consistently match or outperform" multi-agent ones on multi-hop reasoning, concluding that many reported multi-agent advantages "are better explained by unaccounted computation and context effects rather than inherent architectural benefits." Hold the budget constant and most of the advantage goes with it. That finding sits alongside the single-agent failure taxonomy and the contracts between agents that decide whether a topology earns its tokens at all.

The objection I cannot answer is on a different axis. A bounded share of the bill is not a bounded share of the context window. Around 24,858 tokens is roughly an eighth of a 200k window, it sits at the top of the prompt, and it is part of what pulls a long-running agent toward compaction sooner. "That is not your problem" is a claim about money, and I have not tested it on quality. If your subagents are hitting compaction mid-task, the preamble is worth attacking for a reason this article does not measure - which is what the Context Curation Loop from part 1 is for.

Rahul Garg's Orchestrator's Tax makes the complementary point from the other end: the cost that hurts is not tokens at all, but what the orchestrator has to carry forward in its own working memory. Walden Yan's reversal at Cognition lands in the same place - fan out reads, keep writes single threaded. None of this says do not fan out. It says the reason to fan out is context isolation, the argument part 3 made, and that the cost model belongs on turn count.

When this cost model breaks

Here is what would break it. I have not been able to test the first two.

• A workload where the preamble scales with turn count. My preamble-by-bucket table is flat, which is the whole argument. If some agent design makes the entry fee grow with the work, the ceiling disappears. I did not observe it in eleven agent types.
• The 25.1% floor turning out to be the real mechanism. If whatever warms a quarter of lone spawns also drives the 94.4% figure, then model-and-tools matching is a correlate rather than a cause. Testing that needs a controlled pair of spawns with nothing else running.
• Tool loading becoming lazy. Deferred or on-demand tool schemas would shrink the preamble enough that the constant stops being worth arguing about, which would make this article obsolete in the best way.

Two things that will date. Token counts are not portable across model generations, because tokenizers change; the per-model medians above (15,948, 15,887, 14,776, 15,559) span 8%, which is the size of that effect in this corpus. And subagent nesting depth is a tunable whose default has moved more than once, so treat any depth arithmetic as version-specific. Both multipliers, the 1.25x write and the 0.1x read, have been stable since prompt caching launched in 2024. The 1-hour tier at 2x came later and has zero occurrences here.

Production checklist: cutting Claude Code subagent token cost

• Build the per-agent-type turn table for your own fleet. It is the dispatch-time prior that replaces guessing.
• Trim the preamble hardest for the agents you run longest. You avoid the re-read on every turn, so the saving scales with turn count.
• Below 10 turns, ask whether the agent should be a tool call instead.
• Match tools: blocks across the agents in one fan-out so siblings share a prefix. Do not trim tools for size - the saving is about 1,000 tokens and a missing tool costs turns.
• Never pick a model to preserve a cache hit. A cold start costs one preamble; the wrong tier costs a multiple of the whole lifetime. Where the model already matches, the shared prefix is a free side effect.
• Dispatch related subagents together, inside the 5-minute window - it is free.
• Audit your CLAUDE.md hierarchy. Subagents inherit all of it, on every spawn.
• Stop quoting 20,000 tokens as a per-spawn constant. It never was one.

Most of those are preamble work, and it is worth more than I thought when I started: about a quarter of the bill, and the share barely moves with scale. Only the first two items are turn-side work, and that is still where the other three quarters live.

Preamble Fixation is comfortable because the preamble is the part you can read off a single record and edit in an afternoon. That work is worth doing and it is worth about a quarter of the bill, which is more than I thought when I started. How many turns an agent takes sets the other three quarters. I know of no reliable way to make a capable agent take fewer of them without making it worse, and turn count is a thing you only find out afterwards, which is probably why nobody has been putting it in a budget.

References

• Anthropic (2025, June 13). How we built our multi-agent research system. https://www.anthropic.com/engineering/multi-agent-research-system
• Anthropic. How Claude Code uses prompt caching. Claude Code Docs. https://code.claude.com/docs/en/prompt-caching
• Anthropic. Create custom subagents. Claude Code Docs. https://code.claude.com/docs/en/sub-agents
• Anthropic. Prompt caching. Claude Platform Docs. https://platform.claude.com/docs/en/build-with-claude/prompt-caching
• Anthropic. Pricing. Claude Platform Docs. https://platform.claude.com/docs/en/about-claude/pricing
• Kothari, A. (2025, October 11; updated 2026, July 31). Claude Code - When to use task tool vs subagents. https://amitkoth.com/claude-code-task-tool-vs-subagents/
• Systima (2026, July 22). The Subagent Tax: Claude Code Fan-Outs Cost Up to 5.9x the Tokens, and Were Never Faster. https://systima.ai/blog/subagent-tax
• Systima (2026, July 12). Claude Code vs OpenCode: Token Overhead Compared. https://systima.ai/blog/claude-code-vs-opencode-token-overhead
• anthropics/claude-code issue #50213 (2026, April 17). Subagent requests don't place cache_control on trailing system-context block. https://github.com/anthropics/claude-code/issues/50213
• JetBrains/ytdb-slate issue #42 (2026, July 31). Cache-TTL-aware dispatch scheduling: stop re-warming cold worker prefixes. https://github.com/JetBrains/ytdb-slate/issues/42
• Tran, D., & Kiela, D. (2026, April 2). Single-Agent LLMs Outperform Multi-Agent Systems on Multi-Hop Reasoning Under Equal Thinking Token Budgets. arXiv:2604.02460. https://arxiv.org/abs/2604.02460
• Garg, R. (2026, July 16). The Orchestrator's Tax. martinfowler.com. https://martinfowler.com/articles/orchestrator-tax.html
• Yan, W. (2026, April 22). Multi-Agents: What's Actually Working. Cognition. https://cognition.com/blog/multi-agents-working

Related Articles

Agentic AI

• Subagents: How to Run Parallelism Inside a Single Agent Session Without Poisoning the Parent
• Claude Code Guide: Build Agentic Workflows with Commands, MCP, and Subagents
• Which Claude Code Layer Solves Your Problem? A Diagnostic Guide for AI Engineers
• The Ralph Loop and /goal: What Claude Code Actually Automated