Claude Code silently strips skill descriptions once the 1% context budget overflows

How the silent demotion works

According to a post on dev.to, every skill installed in Claude Code — user-level, project-level, or pulled in via a marketplace plugin — injects its name and description into the model's context on every turn, whether or not it is ever used. Claude Code caps that always-on listing with a setting called skillListingBudgetFraction, which defaults to 0.01, or 1% of the context window.

When the listing outgrows the budget, Claude Code begins dropping skill descriptions, starting with the least-used skills. The post reports that no warning appears anywhere in the UI; the only trace is a line in the --debug log. The author notes the budget and the drop order are documented, but nothing in the product surfaces when the rule actually fires. Once a skill loses its description, the model has nothing left to match a request against, so the skill effectively stops being chosen. It remains installed, listed and seemingly healthy — just invisible to the model.

How bad it can get

The author cites one measured setup in which a full plugin install pushed the listing to roughly 10.8 times the default budget. On a 200,000-token window that budget is 2,000 tokens, so an overflow of that magnitude implies most of the catalog had already lost its descriptions — with no signal to the user that anything had changed.

The tool: skill-tax-cli

Published alongside the analysis, skill-tax-cli is a zero-dependency Python CLI (standard library only, available on PyPI) that audits this cost. It offers three commands:

• list enumerates every skill Claude Code can see and reports each one's listing cost — the tokens added every turn — alongside its full-load cost.
• audit ranks skills by full-load cost and shows each skill's share of a given context window via --window, folding in the other always-on sources: CLAUDE.md rules, MEMORY.md memory, and MCP configs.
• gate replays the documented overflow rule — least-used skills lose descriptions first — and exits non-zero when any skill would be silently stripped.

Exit codes are stable (0 clean, 1 silent drops, 2 config error) and every command supports --json, so gate can slot into pre-commit hooks or CI. A --usage flag accepts a JSON file of real invocation counts, letting the simulation reflect actual usage rather than a deterministic fallback. The author distinguishes it from /skill-doctor and community equivalents, which produce interactive in-session reports rather than something a pipeline can act on.

Caveats

The figures come from a single post written by the tool's own author, so the 10.8x number is one person's measurement rather than an independent benchmark. Token estimates use a rough characters-divided-by-four heuristic, which the author frames as order-of-magnitude guidance for spotting which skill is eating the window, not a billing-grade meter.

Why it matters

The failure mode is nasty precisely because it is silent. Installs keep succeeding, the skill list keeps growing, and the model quietly stops picking certain skills — a bug that looks like "the model got worse" rather than a resource issue. It also shows how context windows have become a shared resource that third-party packages spend on your behalf: every installed skill is a permanent per-turn tax, used or not. As agent ecosystems accumulate skills, plugins and MCP servers, budgets like this will increasingly decide what the model can actually see, and any platform that degrades capability under resource pressure without surfacing it invites exactly this kind of mystery. Turning the rule into a CI gate converts an invisible failure into a testable one — and if your Claude Code setup has more skills than you can recall installing, an audit is cheap insurance.