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.
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.
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.
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.
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 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.
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.