Claude Code config measured at 9,857 tokens consumed before the first prompt

What was measured

A developer writing on dev.to has quantified the hidden cost of an accumulated Claude Code setup: 107 skills, 38 agents and 15 commands — 160 components in total — consume 9,857 tokens of the context window in every session before the user types anything. According to the post, that is roughly 5% of a 200,000-token window, spent purely on configuration metadata and stacked on top of the system prompt, tool definitions, MCP tool schemas, CLAUDE.md files and whatever code actually needs to be read.

The author describes the collection as unremarkable accretion: skills get recommended, look useful, get installed, and nothing ever prompts removal.

Two costs, one mostly ignored

The post separates each component into two charges. The body of a skill loads only when the skill triggers, a cost the author considers fair because it is incurred on demand. The description is different. Every description of every installed skill, agent and command stays in the context window for the entire session, whether or not anything fires, because that is how the model learns what exists. The result is overhead paid continuously for components the author estimates triggering in perhaps 2% of sessions.

The measured split: skill descriptions account for 7,470 tokens, agent descriptions 1,999 and command descriptions 388.

The script

The measurement tool, published as cc-tax on GitHub under an MIT licence, is a single Python file using only the standard library. It walks the skills, agents and commands directories, extracts each frontmatter description, and estimates tokens as characters divided by four. The author notes a real tokenizer would shift the absolute figures a few percent but would not change the ranking, which is why no dependency was added.

What the numbers exposed

The heaviest descriptions in the install included loop-design-check at 244 tokens and token-budget-advisor at 209 — a skill whose purpose is reducing token use, charging permanent overhead to do it. Body weight was more lopsided still: across 107 skills the total comes to roughly 322,990 tokens with a median of 1,932, and the heaviest single skill, continuous-learning-v2, costs 56,453 tokens per trigger — more than a quarter of the context window in one shot.

Running the components rather than just reading about them surfaced a second problem. According to the post, continuous-learning-v2's automatic session observation depends on hooks that only exist in a full plugin install and are silently absent otherwise. Three enforcement skills — delivery-gate, gateguard and safety-guard — ship scripts but nothing registers them in settings., so what gets installed is documentation rather than enforcement. The ck memory tool's session-start hook is never wired up, and deep-research requires the firecrawl or exa MCP servers; without them it quietly degrades to ordinary web search while still charging for its description.

The author's conclusion is that a component depending on an MCP server or a hook is only partially installed: the file lands, the description starts costing tokens immediately, and the functionality arrives only after a second setup step that nothing reminds you to perform. There is no error message — the skill fires, underperforms, and the model gets the blame.

One further figure reframes what a skill even is here: of the 107 installed, only 11 ship any file besides SKILL.md. The remaining 96 are pure prose.

What the author did

The remedy was unglamorous: measure, then delete anything not triggered in the past month. The author reports this took about ten minutes and delivered most of the value of the whole exercise.

Why it matters

Context windows are finite, and every token spent on dormant descriptions is unavailable for code, conversation and reasoning. This applies to users of any AI coding assistant, not just Claude Code: installs accumulate invisibly, the cost is billed per session rather than per use, and half-installed components degrade output without any visible failure, which makes a capable model look unreliable. The practical takeaways are to audit your configuration periodically, keep descriptions short if you write skills yourself, and measure the setup before concluding that the model is having a bad day.