A plugin feels like software you install on your machine. To the model it is something else: text. Anything the model needs to know about a plugin, so that it can choose to use it, has to be written into the prompt. And an agent re-sends its prompt on every request.

So the question "do plugins count toward tokens?" has a two-part answer. Every plugin part has a standing cost, the tokens it adds to every request just by being installed, and a use cost, the tokens it adds when it actually runs. The design of a good extension system is mostly about keeping the first number small.

The examples here are from Claude Code, because its documentation states the mechanics precisely. The pattern is general: any agent that offers a model optional capabilities pays for the menu before it pays for the meal. (For the layer names, tools vs MCP vs connectors vs agents, see the AI connectivity reference.)

What a plugin is made of

A plugin is a bundle. It can contain any of five parts, and they cost tokens in different ways, so it is the parts, not the plugin, that you have to reason about.

Part What it is Standing cost (installed, unused) Use cost
Skill A packaged set of instructions for one kind of task Its name and short description, in every request The full instructions load when invoked, and stay in the conversation after that
Subagent A separate model instance for a delegated task Its description, in the list of agent types A whole separate conversation: its own requests and its own context window
MCP server A server that exposes tools and data over the Model Context Protocol Tool names plus any instructions the server provides (tool definitions are deferred by default) The tool's schema when loaded, then every call's arguments and result
Slash command A prompt you run by name Little or none Its text, when you run it
Hook A script the harness runs on an event None: it runs outside the model Only what its output feeds back to the model

The sources for each row follow.

Skills: the menu is in every request, the meal is not

Claude Code's documentation is explicit: "skill descriptions are loaded into context so Claude knows what's available, but full skill content only loads when invoked." A skill's body "loads only when it's used, so long reference material costs almost nothing until you need it."

Two limits keep the standing cost bounded. Each skill's listing (description plus when-to-use text) is "truncated at 1,536 characters." And a skill can opt out of the menu entirely with disable-model-invocation: true: then its description is not in context at all, and only you can invoke it.

The use cost is sticky. Once invoked, the skill's content "enters the conversation as a single message and stays there across later turns." A skill you used an hour ago is still in every request since.

Subagents: they spare your context window, not your bill

A subagent "runs in its own context window." It does its file reads and searches there and "returns only the summary." That is a real benefit: a task that would flood your conversation with logs leaves behind a few paragraphs.

But the work still happens. A subagent "sends its own requests, which count toward the same usage limits as your main conversation." Three subagents running in parallel are four conversations, not one. The documentation's own figure for agent teams, where teammates run as separate instances, is "approximately 7x more tokens than standard sessions" when teammates run in plan mode.

The standing cost is the description in the agent list. Claude Code warns at startup when the combined descriptions of custom subagents pass 15,000 tokens, which tells you that people do get there.

MCP servers: names are cheap, instructions are not always

Early agent harnesses put every MCP tool's full definition, name, description and input schema, into every request. With a few servers of a few dozen tools each, that was thousands of tokens of menu.

Claude Code now defers them: "MCP tool definitions are deferred by default, so only tool names and server instructions enter context until Claude uses a specific tool." The model sees a name, searches for the schema when it needs the tool, and only then pays for the definition.

Two costs remain. Server instructions are included in full, and a server author decides how long they are; some run to several hundred tokens. And tool results go into the conversation and stay there; Claude Code warns when one passes 10,000 tokens and caps them at 25,000 by default.

The documentation also notes that a command-line tool you already have, such as gh or aws, is "still more context-efficient than MCP servers because they don't add any per-tool listing."

Hooks and commands: almost free

A hook runs in the harness, not the model. Its standing cost is zero, and a hook can reduce tokens: the documentation's example filters a test run down to its failures before the model sees it, "reducing context from tens of thousands of tokens to hundreds." A slash command costs its own text when you run it, and nothing otherwise.

The arithmetic of a standing cost

Why care about a few thousand tokens when context windows hold hundreds of thousands? Because the standing cost is paid on every request, and an agent makes many requests: one per model turn, and another each time a batch of tool results comes back.

A worked example (estimate; your numbers will differ):

  • Suppose your installed plugins add 5,000 tokens of standing context: descriptions, tool names and server instructions.
  • A busy day of agent work is 300 requests.
  • That is 1.5 million tokens a day of overhead, before you type anything.

Prompt caching makes this much cheaper but not free. The overhead sits at the start of the prompt, so it is part of the cached prefix and is re-read at the cache-read rate, which on Anthropic's API is between 2.5% and 10% of the base input price, depending on the model. Two cases break that discount:

  • A cache miss (the first request after the cache expires, or after the tool list changes) re-processes the whole prefix at full price.
  • Context, not just price. Caching cuts the cost of the repeated tokens; it does not give back the space they take in the context window. Every standing token is one fewer for your code and conversation, and it brings the session closer to compaction.

This is the same lesson as decode in an inference engine: what you re-send on every step dominates, and the fix is to send less of it, not to make each byte slightly cheaper.

A checklist

  1. Look before you guess. /context shows what is using the context window by category; /usage attributes recent usage to skills, subagents, plugins and individual MCP servers.
  2. Uninstall what you don't use. A plugin you tried once still has its descriptions in every request. /plugin and /mcp let you disable or remove them.
  3. Remove servers that fail to connect. They do no work, and the harness may still tell the model about them.
  4. Prefer a CLI to an MCP server when the CLI already does the job.
  5. Move rarely used instructions from your always-loaded project file into skills. The project file is in every request; a skill body is only there after it is used.
  6. Delegate noisy work to a subagent, but count it. It protects your context window and still spends tokens. Give simple subagent work a smaller model.
  7. Write short descriptions. For skill and plugin authors, the description is the standing cost. Put the trigger first and stop.

The one-line version

Installing a plugin buys a line on the model's menu, and the menu is reprinted on every request. Using a plugin buys the meal. Keep the menu short.

Sources