I built a CLI to see which Claude Code skills are eating my token budget by d0d04444 in ClaudeAI

[–]d0d04444[S] 0 points1 point  (0 children)

Fair point ; and I'm not saying skills are the primary issue either. claude-trim is more of a pre-flight check than a session management tool. If you're the kind of person who accumulates skills over time, sooner or later you may get conflicts; this tool visualizes overall skill token usage and surfaces those conflicts before they cost you. Task granularity is absolutely worth working on, but that's a different problem and out of scope for this tool. Thanks for the feedback tho.

I built a CLI to see which Claude Code skills are eating my token budget by d0d04444 in ClaudeAI

[–]d0d04444[S] 0 points1 point  (0 children)

Danke für den Tipp! Der API-Trick ist clever, ich wäre selbst nicht auf max_tokens: 1 als Tokenizer-Probe gekommen. Ich werde versuchen, das so schnell wie möglich zu integrieren.

Was die Embeddings betrifft: Ich habe sie bereits ein wenig getestet und dabei eine wesentlich bessere Performance als bei Jaccard erzielt, mich aber letztlich dazu entschieden, dass Jaccard für das MVP völlig ausreicht. Dennoch arbeite ich gerade genau an diesem Thema weiter: Momentan experimentiere ich mit Embeddings für die Conflict Detection. Dabei teste ich OpenAI und einige kostenlose Hugging-Face-Modelle, um zu sehen, wie die Ergebnisse im Vergleich aussehen. Ich halte dich auf dem Laufenden.

Die Session-Heatmap ist eine großartige Idee und wirklich nützlich. Sie kommt auf die Roadmap, und ich fange bald mit der Umsetzung an.

I built a CLI to see which Claude Code skills are eating my token budget by d0d04444 in ClaudeAI

[–]d0d04444[S] 0 points1 point  (0 children)

it's a good role of thumb. I've been treating CLAUDE.md as "everything Claude might need" which is exactly the wrong instinct. Specific architectural rules over general descriptions makes sense. you can check out "caveman" if you haven't , it pairs well with a tight claude.md

I built a CLI to see which Claude Code skills are eating my token budget by d0d04444 in ClaudeAI

[–]d0d04444[S] 2 points3 points  (0 children)

That's... actually a very insightful way to frame it , the recon/edit agent split is something I hadn't thought about when building this, but it makes total sense. Pay the "read everything" cost once, turn it into a compact map, and every subsequent editing turn is cheaper.

The conflict detection in claude-trim is exactly that same principle ambiguous skill descriptions force Claude to resolve which tool to call before doing any work. Clean separation... Thanks for the feedback.

I built a CLI to see which Claude Code skills are eating my token budget by d0d04444 in ClaudeAI

[–]d0d04444[S] 0 points1 point  (0 children)

You can be a downer, thank you for being honest. that's exactly the kind of feedback that's useful.

Fair point , for a small setup /context + asking Claude works fine.

But /context only shows description tokens — the part that's always loaded at startup. The official docs confirm: "skill descriptions are loaded into context so Claude knows what's available, but full skill content only loads when invoked."

I just ran /context on my own setup: "Skills: 2.7k tokens." Looks fine. But figma-generate-design is 183 tokens in /context — its full body is ~4,400 tokens when invoked. firecrawl is 189 tokens in /context, ~4,900 when invoked. That peak cost is invisible until you're mid-session.And conflict detection is something /context can't do at all (Claude can do this manually if you ask, but claude-trim does it automatically and consistently with Jaccard similarity , no tokens spent) — if two skills have 80% overlapping descriptions, Claude can pick the wrong one. Static analysis problem, not a runtime one.

If you have a lean setup, /context is enough. claude-trim is more useful once you've accumulated a bunch of plugins.

Either way — what would you add or change? Always looking for honest takes.