Those Skills You Casually Install: How Many Tokens Do They Cost You?

TL;DR Loading 1 skill still bills you 4.2M tokens; skills shouldn't be managed by installing, but by deploying.

Conclusion first: what a skill costs you is not decided by how much you use it, but by how many you install. The moment it lands on your disk, the meter starts running.

I’m not making this up. A long task of mine finished the other day, and I happened to flip open the agent’s token statistics panel. A few numbers sitting next to each other left me quiet for a while.

One Measurement: 1 Skill Loaded, and Here’s the Bill

Start with the whole task. It burned 184.4M tokens in total: 184 million. Tool results took 87.1M (47.3%) and assistant messages 84.9M (46.0%). Those two are the bulk, which matches intuition. In a long task the tools get called back and forth and the model writes back and forth, and that’s where the money goes.

Then look at the one line about skills: skill injection, cumulative, ~4.2M, 2.3% of the total.

What is 4.2M? Against 184 million it’s 2.3%, genuinely “not nothing, not much either”. But hold the verdict and look at what the 4.2M is stacked out of.

At the end of the task the current context sat at 467.6k / 1.0M, 46.8% used. Skill injection inside it: ~7.5k, 2%. Note that 7.5k is a single-turn snapshot. It is there in every turn. The cumulative 4.2M is that thing multiplied by five or six hundred turns.

So what’s inside that 7.5k per turn? Expand it:

Of the 4 injection entries, 3 are skill-catalog updates (1.3k, 1.7k, 2.0k). Only 1 is an actual skill body being loaded: Skill: impeccable, 2.9k.

Let me lay the premise on the table: this environment had fewer than 20 skills installed, and the whole task loaded exactly 1. One. Everything else was spent on the catalog. The agent carries the list of “which skills I have available” in its context; the more you install, the longer the list, the bigger the fixed cost. Put plainly: use one skill, pay for one; install twenty and use one, pay the catalog rent for twenty, times the number of turns.

Extrapolate: What If Installation Has No Limit

The math only needs elementary-school multiplication.

Each skill occupies one line of name plus description in the catalog, roughly 50–100 tokens. A 20-skill catalog is about 1–2k tokens, which lines up with the size of one catalog update I measured (1.3k–2.0k). Now what if, like plenty of people, you install a few skills on every whim until you’re at a hundred or two? The catalog alone is 10k–20k tokens per turn, no negotiation; a task of a few dozen turns hands a few hundred thousand to over a million tokens purely to the catalog.

The token bill is still the small part. The expensive one is elsewhere: the longer the candidate list, the higher the chance the model picks the wrong skill or misses the right one entirely. Like digging for your own wrench in a crate full of other people’s tools, where the more tools in the crate, the more fatal the one wrong grab. Skills were supposed to save tokens and save breath; over-installed, they become a tax you pay every turn.

So stop debating “are skills useful or not”. The real problem is that the act of installing is too crude. One npx command pushes everything into every agent. Satisfying, sure; the bill is just as real. What I wanted was an extremely simple way to manage skills with fine grain: keep them in a vault by default, and deploy only the few a given agent or project needs.

flint: Manage Skills as Assets, Not as Plugins

I solved this need myself: flint (local-skills-hub). I wrote about its design philosophy (local-first, data sovereignty, skills as plain files on disk) in Flint: Turning Skills into Personal Assets. This post won’t repeat that; it only covers how flint solves “enable on demand”.

One sentence for the core idea: collect once, deploy on demand.

Collect. Every skill body lives in exactly one copy, in a repository directory of your own: an ordinary folder on disk, version it with git however you like. Strays scattered across agent directories, things installed from third-party npx installers, imports from other folders, flint takes them all in. Same names deduplicate automatically; divergent sources show up on the Health page with one-click fixes. After the sweep, agent directories no longer hold independent copies; they hold symlinks into the vault.

Deploy. This is the step that solves the token problem. Flint has Presets: a bundle of skills whose members are either an explicit list or “everything carrying tag X”. Open an agent’s detail page, pick a preset, press “Apply preset”, and only the skills in that preset get deployed into that agent’s skill directory. An agent with no linked preset sees zero skills, and its catalog injection is, naturally, zero.

Which means the length of that catalog list in your agent’s context is now your call. The blogging agent carries three or five writing-related skills and pays tax on three or five lines; the frontend agent carries the impeccable bunch; neither disturbs the other. Want a different mix? Edit the preset’s members or tags, press Apply again, done.

Agent management. Flint’s Agents page renders one card per actual skill directory: agents sharing a directory merge into one card and share one strategy, so you never get the “I changed A and B didn’t pick it up” theatre. Per card you can enable or disable it, override its directory, add skills from the vault one by one, apply a preset in one shot, and choose symlink or copy per skill. What physically sits in the directory is what the agent sees. No backstage auto-sync mysticism.

With that combination, “200 skills installed” and “this agent can use 5 skills” are fully decoupled. The vault can grow without limit; the tax is only on what you deploy.

While I’m at It: What Else flint Does

On-demand deployment is the main line, but once collecting and deploying are in place, the rest follows almost for free:

• Projects: register a path plus tags for a project, and the tags become the deployment policy. Matching skills land in the project’s .agents/skills (committable to git) and are shared by symlink into each agent’s project-level directory. Move machines, and the project carries its own skill pack.
• Health: a six-dimension checkup (sync state, duplicates, broken links, config, repositories, projects). Issues are listed; one-click fixes ask you to confirm first.
• Managed npx installs: paste a command like npx xxx skills install and flint runs it inside a managed directory (git snapshots with rollback built in), then feeds the result into the normal registration flow; updating is one button on the source card.
• Tags and metadata: tags prefer the SKILL.md frontmatter, the same fields Claude Code and 40+ other tools read natively; anything not yet written back stays staged locally, migratable in one click.

Install is one line: npx flint-skills-hub, then open http://localhost:8787. No cloud, no account, no telemetry. Skills are files on your disk, and uninstalling flint leaves them there. The UI switches between English and Chinese and logs are downloadable; small tail-end conveniences.

Back to Those Opening Numbers

A 184-million-token task, skill injection cumulative 4.2M, 2.3%. On the ratio alone it hardly counts as much. But don’t forget the premise: an environment with fewer than 20 skills installed and exactly 1 used throughout.

Skills: the value is in reuse, the cost is in residency. Manage them crudely and the cost moves in permanently.

So next time your fingers itch to npx a whole skill pack in, ask yourself one question first: of these twenty skills, how many will this agent actually use?

Think it through, then install. Or don’t install at all: collect into the vault, deploy on demand, and keep the catalog down to the few that actually work.