One morning, Claude Code refused to start. Credits exhausted. I had a €200 plan, an automated monitoring system running continuously, and Claude Code as my pair-programming tool for everything else. Nothing unusual on the surface — but the credits were running out twice as fast as expected, and I couldn't figure out why.
The monitoring system, sure. The CLI called in a loop every 12 hours is easy to calculate. But the interactive sessions seemed reasonable. When I dug deeper, I found the real culprit: ten Claude Code plugins active simultaneously, half of which I never actually used.
What I Had Installed
Over the weeks, I had enabled plugins as needs arose: superpowers
for structured skills, context7 for library docs,
playwright for scraping, code-review,
frontend-design. Plus a few others. The logic: have the tool ready
in case the need arises.
That's the reasoning mistake. I treated plugins like browser extensions — sitting in the background, inert until clicked. Claude Code plugins don't work that way.
What Plugins Actually Do
Every active plugin injects content into the system prompt on every exchange. Not on demand. Not only when you invoke them. On every message, in every session.
The superpowers plugin, for instance, lists all available skills in
every system reminder. context7 injects its usage instructions.
playwright does the same. Multiply that by ten plugins, and every
conversation turn starts with a context bloated by several thousand tokens —
before you've typed anything.
The formula is straightforward: injected token = billed token, even if it belongs to a plugin you haven't used in two weeks.
The Concrete Math
With Sonnet 4.6, input tokens cost $3 per million. An average-sized plugin injects roughly 2,000 tokens of context per message. Ten plugins: 20,000 extra input tokens per exchange.
Over an active session with 50 exchanges, that's 1 million extra input tokens — $3 — solely from passive plugins. Across a day with several sessions, it adds up fast.
On its own, that's not catastrophic. But combined with an automated monitoring system already making dozens of API calls per day, both effects compound and drain the budget far faster than actual usage would suggest.
How to Diagnose Your Situation
Token consumption isn't directly visible in Claude Code, but you can infer what
your plugins are injecting. In ~/.claude/settings.json, the
enabledPlugins key lists what's active:
{
"enabledPlugins": {
"superpowers@claude-plugins-official": true,
"context7@claude-plugins-official": true,
"playwright@claude-plugins-official": true,
"code-review@claude-plugins-official": true,
"frontend-design@claude-plugins-official": true
}
}
For each plugin set to true, ask yourself: "Do I actually use
this plugin in at least half of my sessions?" If not, disable it. You can
re-enable it in 30 seconds via /plugin when the need arises.
The Right Usage Strategy
The rule I follow now: no plugins active by default, enable on demand. Plugins aren't permanent features — they're subscriptions to context. Every active plugin is a fixed cost on every single message.
For recurring workflows like article creation or debugging, skills embedded in
CLAUDE.md files or local skills (~/.claude/skills/) are a better
alternative: they only inject when you explicitly invoke them.
The same logic applies to CLAUDE.md files themselves: every line loaded on every session is a billed token. An 8KB CLAUDE.md documenting the entire project architecture costs more than a minimal one that points to reference files. Better to have several specialized CLAUDE.md files and let Claude read the code than to pre-digest everything into context.
Conclusion
The surprise isn't that plugins cost tokens — it's that nothing in the interface makes it visible. You enable a plugin, forget about it, and it keeps weighing on every exchange in silence.
If your credits are disappearing faster than expected, before optimizing prompts
or switching models, start by listing what's active in settings.json.
The answer is usually right there.