Case study
chaff run on a real operator’s Claude Code context (233 lines, resident on every session on that machine): before, the fix, and after. Receipts, not a mockup. Every number below is computed at build time by the real analyzer against the committed fixtures, the same result the CLI would print, reproducible from a clean clone.
Redacted derivative
This is not a copy of anyone’s real dotfile. Machine-specific paths, hostnames, employer/client names, and email addresses have been replaced with obvious placeholders (<USER>, CLIENT WORK, Acme Ops, and so on). The technical substance, the failure-mode archaeology, the structure, the token weight, is preserved so the findings below are real, not staged. Both files are committed under fixtures/case-study/ and scanned by a CI secret-scan on every push.
Before
5,904
resident ref tok (o200k_base)
After
2,170
resident ref tok (o200k_base)
Saved
3,734 (63.2%)
moved on-demand, not deleted
The fix
The single largest resident chunk was ~110 lines of Chrome/Agent-Browser failure-mode archaeology (mechanisms, root causes, verified-N-of-3 notes) paid for on every turn, including the vast majority of sessions that never touch a browser tool. The fix: keep one routing line resident (which MCP path to use, and when) and move the archaeology into .claude/rules/browser-control-troubleshooting.md scoped with a paths: frontmatter key, so it loads only when browser tooling is actually in play. This is the exact shape of the flagship candidate rule, resident.on-demand-knowledge, demonstrated here by the profiler’s real numbers, even though that specific rule is not yet measured (see below).
A second, unrelated problem in the same file: MEMORY.md had grown into inlined notes instead of an index of links, past the documented 200-line read limit. The tail was being cut and silently never reaching the model, which is exactly what memory.index-over-read-limit exists to catch. The fix there: trim it back to an index, moving the detail into the topic files it was supposed to point at.
Findings: before (5)
Pinned --today 2026-08-09. Reproduce with node packages/chaff/dist/cli/main.js analyze --today 2026-08-09 (npx chaff@latest analyze once the package publishes) from fixtures/case-study/before/.
section "Claude in Chrome (browser control - keep it always working)" carries 3 volatile markers (dates/version pins) ahead of the static bulk. Every edit here invalidates the prefix cache for the ~80% of the file below it (cache reads bill at ~0.1×)
pinned version "127.0.0.1" in prose: build/version pins go stale silently; state the behavior or move the pin into tool-owned config
pinned version "2.1.220" in prose: build/version pins go stale silently; state the behavior or move the pin into tool-owned config
pinned version "2.1.220" in prose: build/version pins go stale silently; state the behavior or move the pin into tool-owned config
content past the documented read limit (200-line limit hit first) is dropped on load: 109 ref tok (o200k_base) never reach the model
chaff% still reads 0.0% on this file, and the reason is not the one you would guess. Four of the five findings above are tier heuristic: believed, not measured, and excluded from the score by design; their 735 resident ref tokens show up in the UNVERIFIED line instead. But the fifth, memory.index-over-read-limit, is enforced, and still contributes nothing to chaff%, because its span anchors on the MEMORY.md content past the read limit, which by definition was never resident to begin with (it is counted in DROPPED, not RESIDENT). An enforced finding with zero effect on chaff% is Decision 6 working as designed, not a bug: the numerator only ever counts resident tokens under an enforced span. “0% chaff” is not the same claim as “clean file” either way. Read the concepts page for the full definition.
Findings: after (0)
Same analyzer, same rules, the fixed fixture at fixtures/case-study/after/.
Clean: 0 findings, 2,170 resident ref tok.
What’s not here yet
The SPEC’s original notes on this file also name a superseded-instruction scar (an entry corrected in place instead of removed) and a resident/on-demand knowledge split. Both map to planned measured rules (contradiction.superseded-instruction, resident.on-demand-knowledge) that have no detector yet. This build ships zero measured rules. See the rule catalog for what “planned” means and why it reports nothing until its eval passes.