Agent config token bloat audit: one scan, four file names.

Most published audits stop at one file name. They are written for the Claude Code reader, the Cursor reader, or the Codex reader, never the person whose repo has all three sitting next to each other. The irritating thing is that the four files are interchangeable as content: they all encode the same shape (a rule list for an LLM in the editor loop), and the four patterns that bloat them are the same.

So this guide is about one detector, one per-line scan, and four worked-example file names. The audit you run on a 2,000-token .cursorrules is the audit you run on a 2,000-token CLAUDE.md is the audit you run on a 2,000-token AGENTS.md. The findings come back in the same shape, and the recoverable bytes go to the same place (your bill).

1. One detector, one scan

The detector is seven lines. It reads the first 300 characters of whatever you pasted and returns one of four inputType values:

The per-line scan that runs next is 62 lines. It iterates the file, checks each line against the four patterns, pushes findings. It does not read the inputType the detector returned. The tag is for the result header. The findings are format-agnostic:

The whole file is 322 lines, no network calls (open DevTools, watch the Network tab, paste a file: no POST). The split between detection and scanning is the load-bearing fact in this guide: it is why a Cursor person and a Codex person and a Claude Code person can share one audit.

2. The four patterns

Seven finding kinds, grouped into four buckets by severity and remediation. The first three (cache_bust, duplicate, bloat) attribute token savings per line. The fourth (dead-rule) flags lines that ship every turn and produce no agent behavior, which is a different kind of waste.

3. The same matrix in every format

The right column below is identical regardless of whether the file you pasted got tagged as claude.md, agents.md, .cursorrules, or .grokrules. The middle column is the literal trigger inside one of your files; the right column is what the analyzer prints, byte for byte, across all four formats:

Read row by row, the table says one thing: there is no format-specific bloat. There is only bloat. The filename on the tab is a label.

4. Worked example: a .cursorrules and an AGENTS.md

Two files from the same repo, pasted into the analyzer one after the other. Same eight columns of output, four different findings on each file because the files are different, identical tokenSavings math because the cost model does not change:

The summary line at the bottom is the entire thesis. If you swap the .cursorrules for a .grokrules with the same shape, the bottom line stays. The format names are interchangeable as bloat surfaces.

5. What this means if your repo has more than one

A real consequence of one-detector-one-scan: if your repo has a CLAUDE.md and a .cursorrules side by side (common; people switch editors mid-task), they each pay their own per-turn cost on their own orchestrator. Bloat in the CLAUDE.md does not subsidize the .cursorrules. Bloat in the .cursorrules does not show up on the Claude Code bill. You have to audit both, separately, in the same short loop.

The good news is the loop is the same. Paste, read findings, fix the high-severity ones, re-paste. About 4 minutes per file. If the patterns you fixed in the CLAUDE.md (a dated line at the top, two duplicated rules) also appear in the .cursorrules (because you copy-pasted between them three months ago), the .cursorrules pass will finish in 90 seconds.

For the layered case (a user CLAUDE.md plus a project CLAUDE.md plus an @AGENTS.md import) the math is on /t/claudemd-layer-audit-token-bloat. For the per-format walkthrough on Codex's file, see /t/agents-md-token-cost-per-turn; for Grok, /t/grokrules-config-analyzer.

6. The four-minute loop

1. Open the file in your editor. Hit copy-all. Open ccmd.dev in another tab. Paste into the textarea.
2. Read the header. Two numbers matter: the inputType tag (confirms the detector saw what you meant) and totalTokens (the denominator for everything below).
3. Sort findings by severity. Fix every high first. That is almost always one cache_bust (one line moved or stripped) and maybe one conflict. The cost swing is at least 5x.
4. Fix the medium findings next. duplicate is a deletion, bloat is a split-into-three, missing_why is a one-line append.
5. Re-paste. The findings list should be shorter; the potentialSavings number should be lower. Save the file. Close the tab. Repeat per file in the repo.