Detailed Analysis
A user's self-audit of their Claude context window surfaced a persistent and instructive problem in how large language model tools manage "standing overhead" — the tokens consumed before a user even types a message. By prompting Claude to inspect its own repository and instructions, the author discovered roughly 71,000 tokens, nearly a third of the context window, were being burned on setup alone. The most striking finding was a plugin that had been formally disabled months earlier during a prior audit, yet its menu listing continued loading in full on every single message, silently costing 8,800 tokens indefinitely. This illustrates a subtle but consequential gap between configuration state and actual runtime behavior: disabling a tool in a config file does not guarantee it stops consuming context, and without direct inspection, that discrepancy can persist invisibly for months.
Beyond the zombie plugin, the audit uncovered a broader pattern of context bloat: 38 unused skills loading their descriptions on every call, a single rule duplicated across six files with five stale copies and one shipping a dead link for a week, and a "warning" in the instructions that the user believed was being enforced but was purely decorative — nothing in the system actually checked it. These findings point to a common failure mode in how users and teams build up instruction files like CLAUDE.md over time: additive, rarely pruned, and rarely tested against what is actually being read versus what is being invoked. The gap between assumed enforcement and actual behavior is particularly notable, since it suggests that context-engineering mistakes aren't just about token waste but about false confidence — believing a safeguard exists when it doesn't.
The article's central technical insight — that the relevant cost metric is load frequency multiplied by size, not raw file size — reframes how context efficiency should be measured. A small file loaded on every message is more expensive over time than a large file accessed occasionally, yet most users intuitively optimize for the wrong variable, trimming large documents while ignoring small, high-frequency ones. This matters increasingly as Anthropic and other providers expand context windows and publish formal guidance on context engineering, since larger windows can paradoxically encourage more bloat rather than less if usage isn't audited. The author's fix — cutting standing overhead from about 71,000 to 44,000 tokens, freeing roughly a fifth versus a third of the window — is a meaningful practical gain, though the author is careful to note that more available context is not equivalent to better output quality, just more room for it.
The piece also flags a reliability caveat relevant to any Claude-driven audit workflow: the model reportedly misreported its own token figures twice during the process, requiring the user to force re-derivation from the underlying files rather than trusting the first answer. This is a useful reminder that self-reported metrics from an LLM about its own state — even something seemingly objective like token counts — should be treated as provisional and verified against ground truth. As agentic workflows increasingly rely on Claude to introspect, configure, and manage its own tools and skills (a trend accelerating with Anthropic's skill and plugin ecosystems), this kind of user-driven auditing is likely to become a standard practice, both for cost control and for catching the quiet accumulation of stale, duplicated, or non-functional instructions that agentic systems are prone to generate over long operational lifetimes.
Read original article →