15% off - September See services
Gabe Giro

Your AI Skill Catalog Has a Token Tax

Every skill you add to an AI coding agent gets enumerated into the system prompt on every turn, whether you use it or not. Here is how that hidden tax scales with adoption, and the route-cap-govern pattern that stops it.

AI ToolingEngineering LeadershipCost OptimizationClaude Code
Get a catalog audit

Most teams roll out AI coding agents one capability at a time. Someone wires up a code-review command. Someone else adds a security-review command. A third person ships a UX-review and a PR-review command. Each one is useful, each one ships in an afternoon, and nobody notices the line item that just appeared on every single agent invocation across the org.

I noticed it on my own setup before any client paid me to notice it on theirs. I had built 78 custom skills into my agent. They worked, and they were also quietly taxing every prompt I sent before I typed a single character of the actual request. I cut the catalog to 47 using five dispatcher commands and trimmed roughly 1,220 tokens off every turn. Same outputs, same flavors, lighter bill. This is not a tooling-cleanup story. It is a governance story, and it is the one most AI-adoption programs are not ready to answer when finance asks where the spend is going.

The tax nobody put on the invoice

Here is the mechanism, because it matters more than the number. An agent framework that supports custom skills has to tell the model what those skills are, so it enumerates every skill's name and short description into the system prompt on every turn, whether you invoke that skill or not. The model needs the menu to know what it can order.

Per turn

~2,340 tokens

78 skills at ~30 tokens of metadata each

One engineer, a few hundred turns a day

recurring, every request

then multiply by the whole team

Catalog overhead loaded before the user asks for anything.

The trap is that each new skill looks free. It ships in an afternoon and solves a real problem. The cost is invisible at the point of decision and only shows up aggregated, downstream, on a bill that does not break out "system-prompt enumeration" as a line item. This is the classic shape of unmanaged platform spend: locally rational additions, globally unaccounted cost. And it scales with adoption, which is exactly the moment a CIO is being asked whether the rollout is paying for itself.

Route the near-siblings

The fix is structural, not a matter of deleting useful capabilities. Most catalogs are full of near-siblings: four or five commands that do the same kind of work with a different flavor. Mine had /code-review, /security-review, /ux-review, and /review-pr. Four separate metadata blocks, four separate slots in the always-loaded menu, all variations on "review this."

I collapsed them into one dispatcher, /r, that takes the flavor as its first argument. The flavor-specific instructions live in their own files that load only when that flavor is actually invoked. The catalog now carries one metadata block where it used to carry four. I did this five times, across five families of near-siblings.

DispatcherReplacedSlots freed
/r <code|biz|security|ux|pr>4 review commands3
/eo <period>end-of-period routinesseveral
/so <period>start-of-period routinesseveral
/p <project>per-project briefingsseveral
/machine <op>machine setup commandsseveral
Five dispatchers. 78 skills to 47. No behavior lost.

Every flavor still exists and still does exactly what it did before. The detailed instructions are loaded on demand instead of broadcast on every turn.

The governance win is the real one

The token savings are the headline, not the point. The point is what the pattern forces you to ask. Once the router exists, every proposed new skill has to answer one question before it earns a permanent slot in the always-loaded catalog: why is this not a sub-flavor of an existing dispatcher? Most of the time, it is.

That question is the governance control. I capped my catalog at 40 skills and treat it as a budget, not a backlog. New capability either fits under an existing dispatcher or earns a scarce top-level slot by displacing something. The cap is what keeps the tax from creeping back, because sprawl is the default state of any system where additions look free.

The skills, commands, and tool definitions you expose to your agents are an interface with a per-token price, billed on every interaction. Treating that interface as something to design, route, and cap is ordinary platform discipline. The only new thing is that the cost lives in a system prompt instead of a Kubernetes cluster.

What this looks like as a practice

1. Audit

Count what loads every turn

skills, commands, tools, and their token cost

2. Route

Collapse the near-siblings

families of 3+ into one dispatcher, on-demand loading

3. Cap

Govern against a ceiling

new additions justify a slot or become a flavor

Vendor-neutral by construction: the tax is a property of how frameworks load context, not of which agent you bought.

For an engineering organization adopting AI coding agents at scale, this is the difference between a program that gets cheaper and more legible as it matures and one that quietly accretes cost no one can trace.


This is the why. The Claude Code Router Pattern is the how, with the file structure and the worked example. Read that next if you want to build it.

If your engineers are already using AI coding agents and nobody can tell you the per-turn cost of the catalog you load on every request, that gap is worth a look before the bill scales with your adoption. Get a catalog audit and I will measure it and route it, vendor-neutral, usually paying for itself in the first month.

Gabe Giro

Stay in the loop

Practical thoughts on engineering leadership, Android, and AI. No spam, unsubscribe anytime.