Claude Code subagents vs Skills: which costs more tokens?

A Skill's description sits in context by default and costs a few dozen tokens whether you ever invoke it or not - the body only loads once you actually use it. A subagent has no idle tier: it pays for its full system prompt and frontmatter fresh, every single time it starts, whether the task inside takes ten tokens or ten thousand. Neither mechanism is cheaper in general. Which one costs more for a given job depends entirely on how often it loads and how much of what it loads you actually needed.

What a Skill loads into context, and when

A Skill is two things wearing one file: a description in its YAML frontmatter, and a markdown body underneath it. Claude Code's own skills documentation is specific about which of those two loads when. By default, the description stays in context for the whole session so Claude knows the skill exists and can decide when it's relevant. The body - the actual instructions - loads only once the skill is invoked, whether Claude triggers it automatically or you type /skill-name yourself.

That's tier one and tier two. There's a third: a skill directory can hold supporting files (reference.md, examples.md, whole API specs) that never load at all unless the skill's body explicitly points Claude at them. A skill's main file can stay short and cheap while a thousand lines of reference material sit on disk, invisible to the token count, until something actually needs it.

Once a skill's body does load, it doesn't unload. The docs are explicit that its content "stays in context across turns" for the rest of the session, which is exactly why they tell you to keep the body itself concise - every line becomes a recurring cost the moment it's paid, not a one-time toll.

What a subagent loads into context, and when

A subagent skips the idle tier entirely. Claude Code's subagent documentation describes each one starting with a fresh, isolated context window that doesn't inherit your conversation history, the skills you've already invoked, or the files Claude has already read. What it gets instead, paid in full each time it's delegated to: its own system prompt (the agent's defined role plus environment details Claude Code appends, not the full Claude Code system prompt), the task message describing what to do, the CLAUDE.md hierarchy your session already loaded (Explore and Plan skip this), and a git status snapshot unless you've turned that off.

There's no cheaper way to invoke a plain subagent. The model field routes it to a cheaper model like Haiku, which helps the bill but not the fixed context cost of getting it started. And its context window is sized by whatever model it's running, not by your main session's - delegate to a smaller-window model and the subagent works inside that smaller window, not yours.

Two exceptions change this math, and they matter more than the base case:

• context: fork runs a skill inside a forked subagent that inherits the entire parent conversation instead of starting fresh. Because its system prompt and tool definitions are identical to the parent's, its first request reuses the parent's prompt cache - the docs call this out directly as making a fork cheaper than spawning a fresh subagent for a task that needs the same context.
• The skills field on a subagent definition preloads named skills' full content at startup. This is the one place a Skill's normal tiering doesn't apply at all: instead of a cheap description sitting idle until invoked, the whole body loads immediately, whether the subagent ends up using it or not.

The measured difference: three real numbers

These three numbers come from running this project's own token-estimation function - the same chars / 4 heuristic the scan and optimizer use everywhere, so a before/after ratio stays consistent even though the absolute count is an estimate - against real example text pulled verbatim from Anthropic's current skills and subagents documentation, not invented figures. A skill's description field alone: 37 tokens. That same skill's full body, frontmatter included: 113 tokens. A real example subagent definition (the docs' own code-reviewer sample), the piece a subagent pays fresh on every call: 216 tokens.

Your own numbers will differ - a longer description or a subagent with a denser system prompt moves all three - but the shape holds regardless of size: a Skill has an idle tier that costs almost nothing, and a subagent doesn't.

| | Skill | Subagent | | --- | --- | --- | | What's isolated | Reference material or a procedure, kept out of context until named | A whole side-task - exploration, tool calls, reasoning - in its own context window | | Idle cost | Description only, tens of tokens, for as long as the skill exists | None - nothing loads until the subagent is actually delegated to | | Cost when invoked | Full body loads once, then stays resident for the session | Full system prompt and frontmatter load fresh, no exceptions | | Recurring cost | None extra on repeat use - the body is already loaded | Paid again in full on every subsequent invocation | | Cheapest variant | Supporting files load only when the body references them | context: fork reuses the parent's prompt cache instead of paying fresh |

The decision rule this actually reduces to

The two mechanisms aren't competing for the same job. A Skill is cheap precisely because it sits there doing nothing until named - that only pays off for knowledge or a procedure you'll want repeatedly, where the alternative is re-explaining it in every prompt or bloating CLAUDE.md with something that only matters some of the time. A subagent is expensive on every call by design - that's the price of a genuinely separate context window, and it only pays off when the work it's isolating would otherwise sit in your main thread and get recharged as a cache read on every later turn.

Neither one is the general-purpose cheap option. Picking based on habit rather than which cost profile the task actually matches is how a well-intentioned setup ends up paying for both kinds of overhead on tasks that needed neither.

The case nobody mentions: a subagent running a Skill

Most explanations of Skills and subagents treat them as a fork in the road: pick one. The docs describe them as composable instead, and the two directions cost differently. Point a subagent's skills field at a Skill and its full body loads at startup, no tiering, because the subagent controls its own context from the moment it starts. Set a Skill's context: fork and the opposite happens: the skill's instructions run inside a subagent that inherits everything the parent conversation already has cached, which is why the docs call forking the cheaper of the two subagent-spawning paths, not the pricier one "extra isolation" might suggest.

That distinction matters most on a Skill with a heavyweight procedure attached to it - something you'd want kept out of the main thread once it runs, but that doesn't need a from-scratch context to do it. context: fork gets that isolation without eating a fresh subagent's full fixed cost.

When this token math doesn't matter

A few hundred tokens of difference between a Skill's idle description and a subagent's fresh system prompt is real, but it's small next to what actually drives most Claude Code bills. If a session runs twenty more turns after a subagent call, an 8,000-token exploration cluster left inline (rather than isolated by that same subagent) can rebill well over one hundred thousand cumulative tokens by the end of the session - the fixed per-call overhead this article measures is noise against that. Optimizing which of these two mechanisms to reach for is worth doing once you already know the answer is close; it is not the first place to look if you haven't checked what's actually compounding in your context window yet.

None of the numbers above are a substitute for your own transcripts - the real mix of skills and subagents any project uses varies by what it's actually doing. The free scan reads your real Claude Code session history and shows what your own skills and subagent calls are costing you, not a modeled example built from documentation samples.

FAQ

• Which one costs more tokens, a Claude Code Skill or a subagent? It depends on how often each one loads. A Skill you invoke rarely stays nearly free - its description is the only recurring cost. A subagent you delegate to often pays its full system-prompt cost on every single call, with no idle discount at all.
• Does a Skill's description really stay in context for the whole session? Yes, by default. Setting disable-model-invocation: true removes the description from context (only you can invoke it directly); setting user-invocable: false keeps the description in context but stops you from invoking it yourself. Either way, the full body only loads on invocation.
• Can a subagent avoid paying its system-prompt cost every time it's called? Only by forking instead of spawning fresh. context: fork inherits the parent conversation and reuses its prompt cache, which the docs describe as cheaper than a fresh subagent for a task that needs the same background.
• Can a subagent use a Skill, or do you have to pick one or the other? They compose. A subagent's skills field preloads a Skill's full content at startup; a Skill's context: fork field runs its instructions inside a subagent instead. Both directions exist and cost differently.
• What's the cheapest way to give Claude a large reference document? A Skill with the material split into supporting files (reference.md, examples.md), referenced from a short SKILL.md body. Those files load only when the body actually points Claude at them, so a large reference doc costs nothing until it's needed.
• Do these measured numbers match what my own setup pays? Not exactly - they come from Anthropic's own documentation examples, not your project's actual skills and subagents. The shape (Skill has an idle tier, subagent doesn't) holds generally; the exact token counts depend on how long your own descriptions and system prompts are.

Made by Neo

UsageCut by ClockedCode - not affiliated with Anthropic. The figures on this page are measured on real Claude Code sessions and labeled measured or estimated where it matters.