CLAUDE.md layer audit for token bloat: rank the layers, cut the worst one first.

You ran a CLAUDE.md audit, got a list of findings, fixed a few lines, and your bill did not move. Most likely the file you audited was the one you most recently edited, which is also the freshest. The file that needed auditing was somewhere else in the stack: probably the user file you set up six months ago, possibly an @import target you forgot is loaded inline on every turn. This page is how to stop guessing and pick the right layer first.

1. The one number you need from each layer

The analyzer returns a long object per file. For the layer-audit you only need two fields. Both are visible in the result panel on ccmd.dev: totalTokens and potentialSavingsTokens.

A finding without a tokenSavings field is still a real flag. It just is not counted in the savings total, because the analyzer will not pretend to know how many tokens you cut by rewriting an aspirational rule into a concrete one. That conservatism is what makes the savings number comparable across files of very different shapes. Two files with the same density have a similar tax-to-size ratio, regardless of whether one is mostly bloated lines and the other is mostly duplicates.

2. Bloat density, the per-layer rate

Define it as a fraction:

This is a rate, not a total. A 200-token layer with 60 tokens of flagged savings is 30% bloated. A 5,000-token layer with 600 tokens of flagged savings is 12% bloated. The big file saves more tokens in absolute terms when you cut it, but it is the smaller one that is rotting faster. The smaller one's author lost the thread of what the file was for. Cut the rate first; the totals follow on the next pass.

3. The five-step procedure

Run as a terminal session it looks like this:

The whole loop is paste, write down two numbers, divide, sort. There is no tooling beyond the textarea, no signup, no upload of your files; the analyzer runs in the browser. The friction is the manual paste of each layer, which is also what keeps the audit honest: you have to look at every file in the stack to score it.

4. Worked example: three layers on a real machine

Same machine that ships this site. The project file is the canonical one-line @AGENTS.md import recommended by Anthropic's memory docs, so all the project rules live in AGENTS.md (which is expanded inline at launch). The user file is the one I have not touched in months. Ranked by density:

The pasted project file scored 0% density. Cleaning it would return nothing. The user file scored 29% and is the layer to cut first; it also happens to be the largest layer by token count, but that is not why I picked it. I picked it because its rate of dead lines per live line is higher than the other two, and because it loads in every repo on this box, so the savings multiply across the week.

5. The order of operations after ranking

Once you have the layers sorted by density, the per-file audit takes over. The per-layer audit picked the file; the per-file audit picks the lines. The findings list on ccmd.dev for the top layer is the input to that next pass. Three checks contribute to the savings number (bloat, duplicate, cache_bust) so those are the cuts you can make today. The other four findings (vague, aspirational, missing_why, conflict) point at lines that need rewriting, not deletion, and the savings from those are not in the ratio.

Re-score the layer after the cut. If its density drops below the next layer in the ranking, switch to that one. Otherwise stay on it. The order of operations is dynamic, not fixed: a layer that scored 29% before a pass and 11% after is no longer the worst offender, even if it still has more raw bloat than the next layer down.

For the line-level work on the file you pick, the three cost states audit covers the dollar math and the cache-bust line specifically. For the arithmetic of summing every layer's cost (the bill total, not the bloat rate), the layered token cost page is the matching procedure. Density picks the layer to fix; those two cover what to fix inside it and how much it saves.