Measure plugin cost and usage

Read a plugin's always-on token cost, cut it down, find out whether anyone still uses it, and pick the telemetry for organisation-wide answers.

Every enabled plugin charges rent. The names and descriptions of its skills, agents and commands sit in Claude's context on every turn of every session, whether or not they are used. This page shows how to read that number, how to shrink it if you maintain the plugin, and how to tell whether a plugin is earning its place.

It is aimed at plugin authors and maintainers. Admins wanting fleet-wide numbers should skip to Measuring across an organisation. Whether a plugin actually changes Claude's behaviour is a separate question, answered by /docs/plugin-evals.

Read a plugin's cost

Run claude plugin details <name> in your shell (not at the Claude Code prompt). The plugin has to be loadable: installed, sitting in a skills directory, or passed with --plugin-dir in the same command:

claude --plugin-dir ./pr-notes plugin details pr-notes

For a hypothetical installed plugin api-guard the output looks something like this:

api-guard 0.4.0
  Description: Reviews API changes for breaking contract changes
  Source: api-guard@acme-plugins

Component inventory
  Skills (2)  contract-diff, openapi-lint
  Agents (1)  compat-reviewer
  Hooks (1)  PreToolUse  (harness-only, no model context cost)
  MCP servers (1)  schema-registry  (tool schemas resolved at runtime; not counted)
  LSP servers (0)

Projected token cost
  Always-on:   ~118 tok   added to every session

Per-component (rounded)
  component        always-on  on-invoke
  contract-diff          ~45        ~210
  compat-reviewer        ~43        ~380
  openapi-lint           ~30         ~95

How to read it:

Section	What it tells you
Component inventory	What Claude Code found. Commands are counted under Skills. Hooks and MCP servers have no estimate or row (the real output annotates them as harness-only and not counted)
Always-on	Tokens every user carries in every session from names and descriptions. This is the number to shrink
Per-component	Each skill, agent or command split into its always-on share and its on-invoke cost (the body that loads when it runs). The always-on column shows the worst offender

The figures are estimates. MCP tool cost is not counted here: run /context in a session with the plugin enabled and look at the MCP tools category.

Shrinking the always-on figure

If you only use the plugin, your options are disable or uninstall (see /docs/plugins/install). If you maintain it, the always-on figure counts each component's name plus its description and when_to_use frontmatter, so:

Tighten descriptions. Cut the marketing; keep the trigger conditions.
Split a sprawling plugin into smaller ones so people install only what they need.

There is a catch. The description is also what Claude matches requests against, so trimming too hard can stop a skill triggering. After trimming, run an eval with a tool_used: Skill grader (see /docs/plugin-evals) to confirm it still fires.

Here is the kind of edit I make:

---
# before (~60 tokens)
description: This skill is a comprehensive helper for anything to do with our OpenAPI specifications, including linting, validating, formatting and generally making sure the spec is in good shape before merging.
---

---
# after (~25 tokens)
description: Lint and validate openapi.yaml. Use before merging any change to API specs.
---

What users see before installing

Official marketplace plugins show a Context cost section in the /plugin details pane, with an Every turn: line and a When invoked: line. When the always-on figure reaches 2,000 tokens or more, Every turn: is highlighted. Plugins in your own marketplace do not get this section, so mention the footprint in your README if it is large.

Is anyone still using it?

Claude Code does not send usage back to plugin authors. Usage lives on each user's machine, so what you can find out depends on who those users are:

You administer their Claude Code: use telemetry or the Analytics API, below.
They are teammates you can ask: point them at the four signals below, all run in their own sessions.
Neither: Claude Code gives you no signal.

For plugins in Anthropic's directory, usage tracking for publishers is documented on claude.com.

The four per-user signals

Not used recently in /plugin. On the Installed tab, a marketplace plugin moves under Not used recently once unused for at least 14 days and 10 sessions. Its details show Last used:. The header never appears for:

plugins loaded via --plugin-dir or from a skills directory;
plugins enabled through managed settings or mounted from a seed directory;
plugins that include a theme, output style, monitor or workflow, since those are in use without a tracked invocation.

A language server counts as used whenever it delivers diagnostics or answers a navigation request. If the organisation sets strictKnownMarketplaces, neither the header nor Last used: appears.

/skill-doctor. Reports what each skill costs and how often it is used, flagging skills that are listed to Claude but have never been invoked, plugin skills included. In an interactive session it opens on the Stats tab of /plugin. See /docs/skills.

/doctor. The general health check lists user-installed skills, MCP servers and plugins and recommends disabling unused ones. See /docs/commands.

/usage. On Pro, Max, Team or Enterprise plans, this breaks recent usage down by skill, subagent, plugin and MCP server as a share of the total. See /docs/costs.

Measuring across an organisation

Two sources cover every machine:

OpenTelemetry events, exported to your own backend once you configure an exporter (/docs/monitoring-usage).
The Analytics API, served from Anthropic's records with nothing to configure.

Which OpenTelemetry signal answers which question

Question	Event or attribute
What gets installed, and from where?	`claude_code.plugin_installed`, one per install
How many sessions is each plugin active in?	`claude_code.plugin_loaded`, one per enabled plugin at session start
Which skills fire, and which plugin owns them?	`claude_code.skill_activated`, with `plugin.name` and `marketplace.name` for plugin skills
What do a plugin's hooks report?	`claude_code.hook_plugin_metrics`, only for hooks in official-marketplace plugins
What does a plugin cost in API spend?	`plugin.name` and `marketplace.name` on the cost counter, set when the active skill or subagent is from a plugin

Redacted names

Official-marketplace plugins report their names verbatim. Everything else, including your organisation's own marketplace, is redacted or omitted by default according to its trust tier (/docs/plugins/security). Set OTEL_LOG_TOOL_DETAILS=1 on exporting machines, typically in the env block of the managed settings that configure the exporter, to get real names:

Event	Default	With `OTEL_LOG_TOOL_DETAILS=1`
`plugin_loaded`	`plugin.name` and `marketplace.name` are literally `third-party`	Real names
`plugin_installed`, `skill_activated`	Name fields omitted; `skill_activated` reports `skill.name` as `custom_skill`	Real names
Cost counter	`plugin.name` is `third-party`; no `marketplace.name`	Real `plugin.name`; `marketplace.name` still absent

Even redacted, plugin_loaded carries a plugin_id_hash, so you can still count distinct third-party plugins.

The Analytics API

On Enterprise, GET /v1/organizations/analytics/plugins returns per-plugin, per-day install and invocation counts across Claude Code and Cowork, groupable by user, RBAC group or product. Activity arriving without a plugin name rolls up into a single third-party row. Authenticate with an API key that has the read:analytics scope, created by a Primary Owner; see /docs/analytics.