Where Claude tokens go: MCP, plugins, skills and the cache

A Claude request is a stack that gets sent again on every turn: tool definitions first, then the system prompt and project context, then the conversation. Where your tokens go depends on which layer something lives in and whether that layer can be read back from the cache. This is a follow-up to Are tokens the new unit of effort?, and this time I checked each claim against Claude’s own documentation, read on 20 September 2026.

I use Claude on a Max plan, mostly through Cowork, with a lot of MCP servers, plugins and custom skills attached. Most of what I believed about what those cost turned out to be half right. Most of the pages below are written for Claude Code, so where they are silent about Cowork I am assuming it behaves the same way.

What is in a Claude request before you type anything?

More than your message. The Claude Code prompt caching page says the model does not remember anything between requests, so every turn re-sends the system prompt, your project context, every prior message and tool result, and then your new message.

The cache is what keeps that from being ruinous. The prompt caching docs build the cached prefix in a fixed order: tools, then system, then messages. A change at one level invalidates that level and everything after it. Claude Code arranges its own layers the same way, with the stuff that rarely changes at the top.

Every misconception below comes from not knowing which of those three boxes a thing sits in.

Do MCP servers cost tokens on every turn?

In Claude Code, by default, they mostly do not anymore. The tool search docs give a typical five-server setup (GitHub, Slack, Sentry, Grafana and Splunk) at about 55,000 tokens of tool definitions before Claude does any work, and say tool search usually cuts that by more than 85 percent by loading only the 3 to 5 tools a request needs. The same page says Claude gets worse at picking the right tool past 30 to 50 available tools, so a big tool list costs accuracy as well as tokens.

Deferral is the default on supported models. The Claude Code costs page says only tool names and server instructions enter context until Claude uses a specific tool. The Claude Code caching page adds that deferred tools stay out of the cached prefix, so a server that connects halfway through a session only appends new content instead of throwing the cache away.

Where MCP still costs you is what comes back. The Claude Code MCP docs cap a tool result at 25,000 tokens by default and show a warning above 10,000. Anthropic’s engineering post on code execution with MCP (November 2025) walks through one example that dropped from 150,000 tokens to 2,000 by having the agent read only the tool definitions it needs from files instead of loading every definition up front. The same post makes a separate case for letting code handle intermediate data instead of passing it through the model. That is one worked example, not an average. The costs page still says CLI tools like gh are more context-efficient than an MCP server doing the same job.

This one is personal, because Token Guard, the token-logging tool I am building, is itself an MCP server. Its tool list is cheap to carry around. What it returns is not free.

Do Claude Code plugins cost tokens?

A plugin is packaging. The plugins docs describe a folder that can hold skills, agents, hooks, MCP servers, LSP servers and background monitors. What it costs depends on what is in the folder.

The Claude Code prompt caching page is specific here. A plugin’s skills, commands, agents, hooks, monitors and themes never invalidate the cache; their content is appended after the conversation. A plugin that ships MCP servers follows the same rules as any MCP server: deferred tools keep the cache, tools loaded into the prefix force the next request to re-read everything. In the desktop app and other sessions without a terminal, plugin MCP changes wait for the next session instead of costing a re-read mid-task.

So when installing a plugin makes usage jump, the packaging is not the cause; what is inside it is. Look for an MCP server inside it whose tools are not deferred, or a skill that got invoked. On Pro, Max, Team and Enterprise plans, /usage in Claude Code breaks recent usage on that machine down by skill, subagent, plugin and individual MCP server, which is the place to look before guessing.

How much does a Claude skill cost?

The Agent Skills overview describes three levels. The name and description are always loaded, at about 100 tokens per skill. The body of SKILL.md loads only when the skill is triggered, and the overview puts that at under 5,000 tokens. Bundled reference files load only when read, and a bundled script never enters context at all; only its output does.

The design is cheap. The way I use it is not. Yesterday I merged 89 Claude skills into 38 and cut the descriptions from 70,918 characters to 33,962, because descriptions load on every turn. The bodies were the part I did not shrink. Writing this post loaded five of them, and their SKILL.md files alone total 399,206 bytes on disk, measured tonight. That averages about 80,000 bytes per skill, far past the 5,000-token guideline.

A loaded body also stays. The caching page says a skill injects its instructions as a message at the point you invoke it, which keeps the cache intact but makes the body part of the conversation. Every later turn sends it again, at the cached rate if the cache is still warm, and at the higher cache-write rate if it has expired.

Is cached input free?

Cheaper, not free. The prompt caching docs price a 5-minute cache write at 1.25 times base input, a 1-hour write at 2 times, and a cache read at 0.1 times. For Claude Opus 5 that is $6.25, $10 and $0.50 per million tokens against a $5 base. Each model has a minimum cacheable length, from 512 to 4,096 tokens depending on the model, and anything shorter is processed without caching and with no error.

The match is exact, so small actions can cost a full re-read. The Claude Code caching page lists the usual ones:

• Switching models. Each model has its own cache, so the next turn reads the whole history uncached.
• Changing effort. On most models each effort level has its own cache too.
• Tools in the prefix changing. An MCP server whose tools are not deferred connecting or dropping out, including one that reconnects on its own.
• Compacting. By design, since the history is replaced with a summary.
• Walking away. On a subscription, within plan usage, the main conversation gets a 1-hour cache lifetime (5 minutes once you draw on usage credits), and subagents get 5 minutes. After a longer break the next turn reprocesses the full context.

Here the two Claude sources I compare against do not line up neatly. The usage limit best practices article says content in projects is cached and does not count against your limits when reused. The Claude Code costs page says a long session re-reads its history at the cached rate, so a one-line question in a session open all day still draws usage for the whole conversation. They describe different products, claude.ai Projects and Claude Code, and I have not found a page that says how a cache read is weighed against a subscription limit. Treat any exact figure you see for that as a guess.

Which Claude usage number should you trust?

• input_tokens is not your input. The prompt caching docs say it counts only the tokens after the last cache breakpoint. Total input is cache reads plus cache writes plus input_tokens.
• The dollar figure in /usage is not a bill on a subscription. The Claude Code costs page says the session cost is meant for API users and is not relevant for billing on Pro or Max. The plan usage bars are what count.
• The cache line is worth reading. /usage shows a prompt cache line with the hit ratio, the misses, whether the cache is warm, and on recent versions the likely cause of the last miss.

So what are we measuring when we measure effort?

In the first post I called a token count a receipt. After reading all of this, I would narrow that: a token count mostly records how the work was arranged, and only partly how much effort went into it.

• A break costs tokens and no effort. Step away past the cache lifetime and the next turn reprocesses everything. Same person, same thought, more usage.
• A model switch does the same. Identical content, a fresh cache.
• A good skill moves effort earlier. The costs page recommends a skill that describes your project so Claude does not have to spend tokens exploring. The hours I spent writing rules show up later as reads that never happen.
• An overgrown skill undoes it. The same rules, once loaded, ride along on every turn after. My 399,206 bytes are a lot of accumulated effort, and they cost tokens every time they load.

So tokens per task can go down while my effort goes up, and go up while my effort stays flat. A number that can move against the thing it is supposed to measure, and that never sees the effort spent before the session starts, is at best a noisy proxy for it. That is fine for a receipt, which only has to help me plan the next session. It is not fine for a scorecard, which people would start optimizing.

I do not have a better unit yet. If you do, I would like to hear it at dhseadev@gmail.com. Earlier notes on the same thread are in the token count was never the metric, and every post is on the devlog and in the full history.

Where do these numbers come from?

Claude’s own documentation is the source for every product figure in this post. The skill counts and byte sizes are my own measurements. All pages were read on 20 September 2026, and prices and limits on them change.

• Prompt caching, Claude API docs: prefix order, multipliers, minimum lengths, usage fields.
• Tool search tool, Claude API docs: the 55,000-token example, the 85 percent reduction, the 30 to 50 tool threshold.
• Agent Skills overview, Claude API docs: the three loading levels.
• How Claude Code uses prompt caching: layers, what invalidates the cache, plugins, cache lifetime.
• Manage costs effectively, Claude Code docs: deferred MCP tools, /usage, skills over exploration.
• MCP in Claude Code: tool search default and output limits.
• Create plugins, Claude Code docs: what a plugin can contain.
• Code execution with MCP, Anthropic Engineering, November 2025: the 150,000 to 2,000 token example and the intermediate-data case.
• Usage limit best practices, Claude Help Center: project caching and usage limits.