TL;DR
I ran the numbers on my own agent skill library this morning. 480 skills installed. 49 ever invoked. The name-and-description index that gets loaded before every single turn is roughly 51,000 tokens, and about 90% of it describes capability my agents have never once reached for. Installing a skill is free; keeping it is a standing tax on every request, paid in context window and in tool-selection accuracy. The fix isn't discipline about what you install — it's a scheduled audit that treats an unused capability as a defect, and a library organized so most of it is loadable rather than loaded.
Yesterday I wrote up an agent that failed safely for nine days and told nobody. Writing it left me in an auditing mood, so this morning I pointed the same skepticism at a part of my setup I had never measured at all: the skill library my agents inherit.
I expected it to be large. I did not expect the ratio.
What I actually measured
Two numbers matter here, and they're both cheap to get. The first is what the library costs. Skills load progressively — the agent sees each skill's name and description up front, and only pulls the full body when it decides a skill is relevant. So the standing cost isn't the whole library, it's the index.
$ ls ~/.claude/skills/*/SKILL.md | wc -l
480
$ du -sh ~/.claude/skills
105M
Then the index itself — every skill's name plus description frontmatter, concatenated:
skills with frontmatter: 480
total chars name+desc: 205,135 (~51,000 tokens at ~4 chars/token)
median description: 408 chars
descriptions >500 chars: 132
Roughly 51,000 tokens, on every turn, before I type a word. That's the floor. Not the 105 MB on disk and not the 4.8 MB of skill bodies — those are lazy. But the index is not lazy, and it is not small.
The second number is what I get for it. My session transcripts live in ~/.claude/projects/ — 3.9 GB of them — and every skill invocation leaves a record. So I counted:
$ grep -rhoE '"skill":"[a-z0-9:_-]+"' ~/.claude/projects \
| sed 's/.*:"//;s/"//' | sort | uniq -c | sort -rn
420 total invocations, across 49 distinct skills. Out of 480 installed. That's a 10.2% utilization rate on a library I have been curating for months.
One honesty note before I build anything on that figure: that grep matches one JSON shape in the transcript format, so it's a floor rather than a census. The true count is somewhat higher. It is not four hundred skills higher.
The distribution is worse than the ratio
The 10% headline undersells it, because the 49 that do get used are not evenly used. Five skills account for 294 of 420 invocations — 70% of all the work. Twenty-three skills were invoked exactly once, ever.
That bottom row is the whole post. Four hundred and thirty-one skills contributed nothing to any session, and every one of them is still paying rent in the index on every turn.
Why sprawl is different from a big context
I've written before about context engineering as the actual job — deciding what an agent sees on a given task. This is a different problem, and I had been quietly conflating them.
Context engineering is per-task and I control it. Capability sprawl is standing. It's the floor I start every task from, on every project, whether or not it's relevant. Nothing about my Amazon listing work needs a video-directing skill in the index, but it's there, because "there" is the only place skills live.
And the cost isn't only tokens. The more interesting cost is selection. The niche has converged on this fast in 2026: as the number of available tools grows, the model's ability to pick the right one degrades — near-perfect at around 20 tools, collapsing badly past 100 (Nerd Level Tech, 2026). Tool definitions run roughly 100–500 tokens each, so a handful of connected MCP servers can burn 30,000–60,000 tokens before the first user message (Albato, 2026). The reported practical ceiling is about 5–7 connected servers. GitHub Copilot cut its tool set from 40 to 13 and reported both lower latency and better accuracy in the same move.
Skills aren't tools, exactly — they're progressively disclosed, which is precisely the design that lets a library get this big without falling over. But the selection problem is the same shape. Every entry in the index is a candidate. When 90% of the candidates are dead weight with plausible-sounding descriptions, you are asking the model to do a harder discrimination task for no benefit, every single turn.
Here is what those two costs look like side by side, because they have different remedies:
| Cost | What it scales with | What it actually does to you | Remedy |
|---|---|---|---|
| Index tokens | Number of skills × description length | ~51k tokens off the top of every turn; less room for the real work | Prune the count; tighten long descriptions |
| Selection accuracy | Number of plausible candidates | Wrong skill chosen, or none chosen when one applied | Prune near-duplicates; make descriptions discriminating, not descriptive |
| Maintenance | Number of skills that reference real systems | Stale skills quietly teach agents last quarter's process | Delete on sight; a stale skill is worse than a missing one |
| Review load | Total skills | You stop reading them, so you stop noticing rot | Keep the library small enough that you'd actually re-read it |
The last row is the one that got me. A 480-skill library is not a library I audit. It's a library I accumulate.
How this happened, honestly
Not by carelessness — by a sequence of individually correct decisions.
Each skill was installed for a real reason on a real day. Some came in bundles: install one plugin, inherit fifteen skills. Some were speculative — a category I might work in, so I grabbed the toolkit ahead of the need. Some were mine, written for a specific brand, still valid but only relevant a few weeks a year. None of them were mistakes at install time.
The mistake is that installing has a moment and keeping doesn't. There's a point where you decide to add a skill. There is no corresponding moment where anyone asks whether it's still earning its place. So the library only moves in one direction, and the tax compounds silently — which is the same structural bug I wrote about yesterday, wearing different clothes. A cost with no reporting mechanism grows until something forces you to look.
The skills themselves are still the right idea. Writing them down is how I keep agents from improvising process, which is the argument I made in how CLAUDE.md and skills stop agent drift, and I stand behind every word. The correction isn't "write fewer skills." It's that a skill library is an operating asset with a carrying cost, not a collection.
What I'm changing
Four rules, in the order I'm applying them.
1. Measure before you prune. The two commands above take under a minute and turn an argument into a number. Do them before deciding anything — my instinct going in was that the library was maybe 60% dead, and the instinct was off by half. Utilization rate, index token count, and single-invocation count are the three numbers worth writing down.
2. Zero invocations is a defect, not a neutral. For the 431 skills with no recorded use, the default is removal, with one carve-out: genuinely seasonal work, where I'd expect zero uses for months and still want it — tax prep is the obvious case. That's a handful of skills, not four hundred. Everything else gets uninstalled, and if I need it again, reinstalling is a one-minute job I have now done many times.
3. Descriptions have to discriminate, not describe. 132 of my descriptions run over 500 characters, and the long ones are usually long because they're trying to be complete. Completeness is the wrong goal for an index entry. The only job of a description is to let the model decide, correctly and fast, whether to open this skill instead of the four adjacent ones. Two sentences of sharp boundaries beat a paragraph of features, and it's cheaper.
4. Audit on a schedule, since sprawl has no natural alarm. This goes into the same monthly pass where I check my scheduled agents. The question is one line: what is installed, what got used, and what does the gap cost me per turn? An unmeasured capability library grows the way an unmonitored agent fails — quietly, and only in the direction that costs you.
The deeper pattern connects to something I keep re-learning about running a fleet solo. Every layer of an agent system has a version of this bug: a decision that's easy to make and impossible to revisit. Adding a skill. Adding a guard rail. Adding a model tier. The systems that stay healthy aren't the ones with the best additions — they're the ones where something, on a schedule, asks what can come out.
I ran the audit. I'm keeping under a hundred.
FAQ
How many skills is too many for an AI agent?
There isn't a clean threshold for progressively-disclosed skills, but the useful proxy is the tool-count research: selection accuracy is near-perfect around 20 candidates and degrades badly past 100. The better test than a count is utilization. If under half your library has ever been invoked, the unused portion is costing you index tokens and selection accuracy in exchange for nothing. My library was at 10% utilization across 480 skills, which is not a close call.
What does an unused agent skill actually cost?
Its name and description frontmatter, loaded on every turn, forever. In my library that index totals about 205,000 characters — roughly 51,000 tokens — of which about 90% describes capability never once used. The skill body is lazy-loaded and costs nothing until invoked, so the body size is not the problem. The index is. The second cost is harder to measure: every dead entry is one more plausible candidate the model has to rule out when picking.
How do I measure which skills my agents actually use?
Count invocations in your session transcripts. On Claude Code that's ~/.claude/projects/ — grep for the skill-invocation records, pipe through sort | uniq -c | sort -rn, and you have a ranked usage table in about a minute. Compare that distinct count against ls ~/.claude/skills/*/SKILL.md | wc -l. Treat the result as a floor rather than an exact census, since a single grep pattern won't catch every transcript shape, but the ratio is accurate enough to act on.
Should I delete a skill I might need later?
Usually yes, if reinstalling is cheap. The asymmetry favors deletion: a skill you removed and need again costs you one minute of reinstalling, while a skill you kept and never use costs you index tokens on every turn indefinitely, plus a slow drift toward describing a process you no longer follow. The exception is genuinely seasonal work with a known cycle — quarterly tax prep, an annual planning process — where zero recent invocations are expected rather than diagnostic.
Is this the same problem as MCP context bloat?
It's the same failure mode in a different layer. MCP tool definitions are loaded eagerly and cost roughly 100–500 tokens each, which is why the reported practical ceiling sits around 5–7 connected servers. Skills are progressively disclosed, so a much larger library stays workable — that design is the only reason 480 of them didn't break anything outright. But both are standing per-turn costs that grow by accumulation and never shrink on their own, and both degrade tool selection as the candidate pool fills with things you never pick.
WORKING ON SOMETHING LIKE THIS?
Most agent systems don't fail on the model — they fail on the operating discipline around it: what's loaded, what's measured, what gets pruned. If you're building a fleet that has to hold up unattended, that's the work I do. Get in touch, or see the press and hire page.
— Italo Campilii. Measured 2026-07-31; commands above are reproducible on any Claude Code install.