All payments made in the preview are in test mode. Read more
claudetokenoptimization.com

Optimize

Claude Skills and Plugins: Cost vs Convenience

Skills and plugins feel free until you meter them: listing burns context every turn, invocation loads the body and keeps it across turns, and plugin packs can stack MCP and agent tax on top. Measure both bills, then keep the convenience that actually saves tokens.

Figures last verified 2026-09-19

This page is part of the Optimize hub, which covers the whole topic end to end.

Last updated 19 September 2026. This page explains claude skills token usage as an operational problem: why skills and plugins feel free in the UI, how listing and invocation actually bill tokens, which waste patterns show up in Claude Code sessions, and which fixes keep the convenience without the permanent tax. Skill listing budgets, description caps, compaction re-attach limits, and plugin packaging evolve — confirm live behavior in Anthropic’s Claude Code skills and plugin docs on code.claude.com. [VERIFY: 2026-09-19]

Not affiliated with Anthropic. Claude Token Optimization is an independent site and audit service. Claude® and related product names are trademarks of Anthropic PBC. Plan prices, model rates, skill listing budgets, and usage metering change; always confirm on Anthropic’s own docs. [VERIFY: 2026-09-19]

Searches for claude skills token usage, plugin context cost, and “why did installing three plugins empty my bar” usually want the same answer: a skill is not free context. Names and descriptions sit in the listing so the model can choose; the full SKILL.md body loads when invoked and stays across turns; plugins can bundle skills with agents, hooks, MCP servers, and LSP — each with its own always-on or on-invoke footprint.

This spoke sits under the Optimize hub. Pair it with tool-use costs, document token costs, extended thinking, Claude Code tokens, prompt caching, Cowork, and cut token usage. Soft CTA to a written review at the end — no dollar price on this page.

Why skills and plugins feel free (and are not)

In Claude Code, installing a skill or enabling a plugin feels like adding a menu item. You type /skill-name, Claude picks a relevant skill, or a marketplace plugin ships a pack of helpers. Nothing looks like a line item. The meter still cares: every turn that carries a skill listing pays for those names and descriptions, and every invocation pays for the body that enters conversation context.

That is why claude skills token usage shows up in audits next to tool schemas and fat CLAUDE.md files. Teams attribute spend to “the model” or “the repo” and miss that twenty unused skills with verbose when_to_use text, plus a plugin that also starts an MCP server, are the real ballast. Finance sees capacity drain; developers see a Discover tab; nobody owns the skill budget until someone runs /skill-doctor or reads the Skills row in /context. [VERIFY: 2026-09-19]

Treat skills like any other optimize lever: measure listing vs invocation, attribute which packs and personal skills dominate, reduce what is always on, then monitor so the next “just install this plugin” habit does not undo the win. The rest of this page is that playbook — including when a good skill saves tokens by replacing file exploration.

Two bills: listing vs invocation

Anthropic’s Claude Code skills docs separate what is always in context from what loads on use. That split is the whole cost story.

Listing: names and descriptions every turn

So Claude can choose a skill automatically, the product loads a listing of skill names and descriptions into context. The listing is not the full procedure — it is the catalog. Default behavior (checked 2026-09-19 against code.claude.com/docs/en/skills): the listing budget scales at about 1% of the model’s context window (skillListingBudgetFraction), and each skill’s combined description + when_to_use text is truncated at roughly 1,536 characters (skillListingMaxDescChars) to reduce context usage. When the listing overflows the budget, descriptions for least-used skills get shortened first. [VERIFY: 2026-09-19]

Important nuance: with default invocation settings, the description stays in context even when you never call the skill. Set disable-model-invocation: true (or the matching skillOverrides state) and the description drops out of Claude’s listing — you can still invoke manually with /name. That is one of the cleanest cost switches on the page. [VERIFY: 2026-09-19]

Invocation: full SKILL.md body that persists

When you or Claude invoke a skill, the rendered SKILL.md content enters the conversation as a message and stays across later turns. Claude Code does not re-read the file every turn; the loaded body is recurring token cost for as long as it remains in history. Keep bodies concise for that reason — long narrative “how and why” sections tax every follow-up.[VERIFY: 2026-09-19]

After auto-compaction, Claude Code can re-attach invoked skills within a budget: roughly the first 5,000 tokens of each skill, sharing a combined pool of about 25,000 tokens, filled from the most recently invoked skill first. Older or oversized skills may be dropped entirely after compaction if many were used in one session — which then tempts people to re-invoke and re-pay the body. [VERIFY: 2026-09-19]

BillWhat enters contextWhy it bites
Listing (always-on catalog)Skill names + descriptions (and when_to_use)Paid every turn so the model can choose; ~1% window budget; ~1,536 chars/skill cap
Invocation (on use)Full rendered SKILL.md bodyStays across turns; re-attach after compaction up to ~5k/skill, ~25k combined
User-only / disabledHidden from model listing (manual /name still works when allowed)Cuts always-on tax for side-effect or rare workflows
Name-only overrideName listed without description textKeeps discoverability with less listing ballast
Orienting split: listing vs invocation (Claude Code skills)

Treat the table as planning orientation from the skills docs dated for this page — not as a substitute for /context on your session. Product versions and settings can change the exact knobs. [VERIFY: 2026-09-19]

Plugins as install units (and stacked cost)

A plugin is a packaging and distribution unit. Marketplace and project plugins may bundle skills, agents, hooks, MCP servers, and LSP servers in one install. That is convenient — and it is how a single “helpful” plugin becomes several cost surfaces at once: skill listings, agent prompts, hook chatter, and MCP tool schemas that look a lot like the tax described on tool-use costs. [VERIFY: 2026-09-19]

Before you install, the Discover / details UI (and CLI-style claude plugin details inventory) is meant to show what will land: commands, agents, skills, hooks, MCP and LSP — often with a context cost estimate for what the plugin adds every turn. Use that estimate the way you would read a dependency’s size before npm install. Not every marketplace entry exposes perfect numbers; when the UI says components will be discovered at install, measure after with /context and the plugin Stats tab. [VERIFY: 2026-09-19]

Always-on listing cost vs on-invoke cost still applies inside a plugin: plugin skills are typically namespaced (/plugin-name:skill-name), but their descriptions still compete for listing budget unless you disable the plugin or restrict invocation. MCP servers and LSP add a different tax — tool/schema and diagnostics traffic — that continues even when you never type a slash command. Disable unused plugins (/plugin disable) rather than leaving them “for someday.” [VERIFY: 2026-09-19]

Waste patterns that inflate skill and plugin spend

These patterns show up repeatedly when teams paste Claude Code sessions for review. None require exotic models — they are defaults that feel helpful.

  • Bloated descriptions. Long description / when_to_use essays that burn the per-skill character cap and still crowd the listing budget. Put the key use case first; everything after the cap is wasted authoring effort and may never reach the model. [VERIFY: 2026-09-19]
  • Dozens of unused skills. Personal + project + synced + bundled catalogs pile up. Every listed skill competes for the ~1% budget; unused ones still cost until you turn them off or name-only. Run /skill-doctor to see cost vs invocation frequency. [VERIFY: 2026-09-19]
  • Fat SKILL.md bodies that stay in context. A 800-line procedure loaded once becomes permanent ballast for the rest of the thread. Supporting files exist so the body can stay short and load detail on demand — use them.
  • Plugin packs that add MCP tax. Installing for one slash command also starts MCP servers whose tool schemas ride along like agent tools — see tool-use costs.
  • Always-on CLAUDE.md vs on-demand skills. Parking a full procedure in CLAUDE.md means you pay every turn. The skills docs explicitly recommend moving long procedures into skills so the body loads only when needed — that is a cost win when done well. [VERIFY: 2026-09-19]
  • Re-invocation after every compaction. Compaction may keep only a prefix of each skill within the combined budget. Habitually re-running five fat skills after every compact re-pays invocation cost.
  • Duplicate catalogs. The same workflow as a personal skill, a project skill, and a plugin skill — three listing entries, one job.
  • Side-effect skills left model-invocable. Deploy / send / production skills that Claude can auto-trigger also keep descriptions in context. Mark them user-only unless you truly want auto-invoke.

Fixing catalog hygiene is usually worth more than shaving a few words off a system prompt. Start with the fattest unused listings and the plugins you have not touched in weeks — Claude Code even surfaces “not used recently” plugins in the Installed tab for that reason. [VERIFY: 2026-09-19]

Fixes that actually reduce skills token usage

The goal is not “never use skills.” The goal is a small, sharp catalog: short listings, concise bodies, plugins you can justify on the meter.

  1. Write short descriptions with the key use case first. Respect the ~1,536-character combined cap; lead with trigger phrases the model needs. Trim storytelling. [VERIFY: 2026-09-19]
  2. Use name-only / skillOverrides for low-priority skills. skillOverrides can set "name-only", "user-invocable-only", or "off" without editing shared SKILL.md files — ideal for repo skills you rarely need. [VERIFY: 2026-09-19]
  3. Migrate always-on guidance into on-demand skills. If CLAUDE.md has grown into a procedure, move it to a skill so listing stays thin and the body loads only when invoked.
  4. Disable unused plugins. /plugin disable … (or uninstall) removes their skills and usually their MCP/LSP footprint from the session after reload. Prefer disable over “leave it installed just in case.”
  5. Measure with /context, /doctor, and /skill-doctor. /doctor estimates listing context cost and big contributors; /skill-doctor reports cost vs how often skills get used; /context shows the Skills row after budget application. [VERIFY: 2026-09-19]
  6. Keep SKILL.md bodies concise; split fat plugins. Prefer under ~500 lines in the main file with reference docs beside it. If one plugin bundles five MCP servers you only needed one skill from, install a thinner pack or build a project skill instead.
  7. Set disable-model-invocation on side-effect workflows. Manual /deploy should not also occupy listing space and risk auto-trigger.
  8. After compaction, re-invoke only what the task still needs. Do not reload the entire historical skill set “to be safe.”
ChangeEffect on the taxWatch-out
Shorten description + when_to_useLess listing pressure; better match keywords in the capToo vague and the skill never auto-triggers
name-only or user-invocable-onlyCuts always-on description tokensYou must remember to /name when you need it
Disable unused pluginsRemoves skills + often MCP/LSP schemasReload / next session for full effect
Move CLAUDE.md procedures into skillsAlways-on facts stay; procedures load on demandPoor descriptions → skills never chosen
Concise SKILL.md + supporting filesLower persistent cost after invokeDo not hide critical steps in unread files
High-leverage changes for skill and plugin cost

Cost vs convenience: when a skill saves tokens

Optimization is not “delete everything.” A good skill can save tokens: an architecture overview skill beats exploring twenty files; a deploy checklist skill beats a wandering agent; a conventions skill beats pasting the same style guide into every chat. Measure both sides — listing + invocation cost versus the file reads, retries, and wrong turns you avoided.

Practical test: for one recurring task, compare a clean session with the skill available vs disabled (or compare before/after installing a plugin). Look at total input tokens, tool rounds, and wall time — the same spirit as skill-creator / plugin eval loops in Anthropic’s docs. If the skill costs 2k listing tokens a day but saves 40k of exploratory reads per task, keep it. If it has never been invoked and costs listing space every turn, turn it off. Pair this with session hygiene on Claude Code tokens and the wider list on cut token usage.

Stack skills with other expensive surfaces carefully. A fat skill body plus extended thinking plus a document upload is three optimize problems in one turn — see extended thinking costs and document token costs. Convenience compounds; so does the bill.

How this shows up in an audit

A typical finding: the team insists prompts are lean; /context shows a large Skills row; half the catalog has never been invoked; two marketplace plugins each add MCP schemas nobody uses this month. Another finding: CLAUDE.md still contains a 200-line release procedure that should have been a user-only skill. A third: after every compact, the same three oversized skills are re-invoked out of habit, re-paying the body tax inside the ~25k re-attach budget. [VERIFY: 2026-09-19]

Fixes are catalog and packaging decisions, not “buy a bigger plan.” Attribute skill listing and plugin MCP as their own buckets alongside tools and documents. Soft CTA: start a Claude token audit when skill and plugin spend is opaque. This page never quotes an audit dollar price; pricing lives only on the audit page itself.

FAQ

Do unused skills still cost tokens?

If they appear in the model-facing listing (default for model-invocable skills), their names and descriptions consume listing budget every turn even when never invoked. Hide them with overrides, disable-model-invocation, or by disabling the plugin. [VERIFY: 2026-09-19]

Is the full SKILL.md always in context?

No. The full body loads on invocation (or into certain subagent preload paths). Until then, only listing metadata should be present — which is why moving procedures out of always-on CLAUDE.md into skills is a cost strategy. [VERIFY: 2026-09-19]

What happens to skills after compaction?

Auto-compaction can re-attach recent skill invocations within roughly 5,000 tokens per skill and about 25,000 tokens combined, preferring the most recent. Large or older skills may drop; re-invoke only what you still need. [VERIFY: 2026-09-19]

Do plugins cost more than a single project skill?

Often yes, when they bundle MCP, agents, hooks, or LSP you did not need for the one command you wanted. Check context-cost estimates and claude plugin details-style inventories before installing. [VERIFY: 2026-09-19]

Where should I look first in a live session?

/skill-doctor for unused vs costly skills, /doctor for listing pressure, /context for the Skills row, and the plugin Installed / Stats views for packs you have not used recently. [VERIFY: 2026-09-19]

Is this only a Claude Code problem?

Skills also appear in Cowork and claude.ai-synced flows with different load paths. The physics — catalog metadata vs on-demand body — still applies; confirm the surface you use. See Cowork costs.

Next steps

  1. Run /skill-doctor and /context; note the largest unused listings.
  2. Shorten descriptions (key use case first); set name-only or off for low-priority skills via skillOverrides.
  3. Move long CLAUDE.md procedures into on-demand skills; keep CLAUDE.md for durable facts.
  4. Disable plugins you have not used recently; prefer thin project skills over fat packs when you only need one workflow.
  5. Keep SKILL.md concise; after compaction, re-invoke only active skills.
  6. Pair with tool-use, Claude Code tokens, and cut token usage.
  7. If skill and plugin spend stays opaque, paste for a written audit.

Skills and plugins are leverage — or silent ballast. Manage claude skills token usage with the same Measure → Attribute → Reduce → Monitor loop as every other optimize spoke: pay for the catalog that earns its place, load bodies on demand, and keep convenience that saves more tokens than it spends. For the wider lever list, return to the Optimize hub.

Keep reading