token-burn-auditor
Skill0 starsChanged 7 months agoMITView on GitHub
Audit the live Claude Code environment for token waste -- measures per-session overhead, flags system prompt bloat, checks plugin/skill loading totals, and gives before/after deltas when changes are made. Real-time linter for AI workflows.
In this repository24 other files it gives its agents.
- aarSkill
- agent-cost-modelSkill
- banana-makerSkill
- bitter-lesson-scorecardSkill
- boot-tax-monitorSkill
- compensating-complexity-auditorSkill
- context-fork-guideSkill
- context-hygieneSkill
- counterargument-stress-testSkill
- dark-code-auditSkill
- executive-briefingSkill
- failure-asymmetrySkill
- failure-postmortemSkill
- file-intelSkill
- geopolitical-signal-enricherSkill
- get-api-docsSkill
- gh-reviewSkill
- model-routerSkill
- optimize-descriptionSkill
- prompt-rewriterSkill
- skill-auditSkill
- skill-maintenanceSkill
- spec-gap-detectorSkill
- what-am-i-forgettingSkill
The file
We split this skill into the rules it gives an agent
4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
0
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 12
Use when the user says "audit my tokens", "where are my tokens going", "token burn", "session overhead", "why is my context so full", …
- Distinctive: line 16
Run the following diagnostics:
- Distinctive: line 88
If the user makes changes based on recommendations, re-run Phase 1-2 and show the delta:
- Distinctive: line 97
Keep output concise and scannable.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Token Burn Auditor
Audits your current Claude Code environment to identify where tokens are being wasted. Measures actual overhead, flags bloat, and produces actionable reduction targets.
Trigger
Use when the user says "audit my tokens", "where are my tokens going", "token burn", "session overhead", "why is my context so full", "token waste", or asks about optimizing their Claude Code environment for token efficiency.
Phase 1: Measure Current Overhead
Run the following diagnostics:
- Skill frontmatter scan -- count total skills in
~/.claude/skills/and estimate token load from all SKILL.md files:find ~/.claude/skills -name "SKILL.md" | wc -l find ~/.claude/skills -name "SKILL.md" -exec wc -w {} + | tail -1 - CLAUDE.md chain -- measure the full instruction chain that loads on every session:
~/.claude/CLAUDE.md(global)- Project-level
CLAUDE.md - Any
.claude/CLAUDE.mdin project - Memory files referenced by these
- MCP server count -- check how many MCP servers are configured
- Hook overhead -- count configured hooks
- Session history weight -- if JSONL session logs exist, sample recent ones for size
Phase 2: Calculate Token Budget
Estimate token consumption using these approximations:
- 1 word ~ 1.3 tokens (English text)
- 1 line of code ~ 10 tokens
- YAML/JSON frontmatter ~ 1.5x word count in tokens
Produce a breakdown table:
| Source | Est. Words | Est. Tokens | % of 200K |
| Global CLAUDE.md | X | X | X% |
| Project CLAUDE.md | X | X | X% |
| Skill descriptions (N skills) | X | X | X% |
| MCP server schemas (N servers) | X | X | X% |
| Hooks config | X | X | X% |
| Memory files | X | X | X% |
| Total static overhead | X | X | X% |
Note: 200K is the effective context for Sonnet/Opus. Adjust if the user specifies a different limit.
Phase 3: Identify Waste
Flag issues in priority order:
- Critical (>10% of context): Any single source consuming >20K tokens
- Warning (5-10%): Sources between 10K-20K tokens
- Info (<5%): Normal overhead, no action needed
Specific patterns to flag:
- Skills that haven't been invoked in 30+ days (check
skill_invocations.dbif available) - Duplicate or overlapping skill coverage
- CLAUDE.md sections that repeat information already in skills
- MCP servers that are configured but unused
- Memory files that have grown beyond 500 words
Phase 4: Recommend Reductions
For each flagged issue, provide:
- What to do -- specific action (archive skill, trim CLAUDE.md section, etc.)
- Token savings -- estimated tokens recovered
- Risk -- what capability is lost if this is removed
Produce a summary:
Current static overhead: ~XXK tokens (XX% of 200K context)
Achievable reduction: ~XXK tokens
Post-optimization: ~XXK tokens (XX% of 200K context)Phase 5: Before/After Delta (Optional)
If the user makes changes based on recommendations, re-run Phase 1-2 and show the delta:
Before: XXK tokens (XX%)
After: XXK tokens (XX%)
Saved: XXK tokensOutput Format
Keep output concise and scannable. Use tables over paragraphs. Lead with the number, not the explanation.
Source Attribution
Technique derived from Nate's Newsletter (2026-04-02): "You're Loading 66,000 Tokens of Plugins Before You Even Type" -- token waste taxonomy and environment-level auditing approach.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

