jchilcher

The single repeating heading as an index anchor is a smart middle ground — keeps structure without the full markdown overhead. The "single line rationale, no tutorial explanations" constraint is interesting, that's essentially forcing the same signal-over-noise discipline at the instruction level rather than just the formatting level. I might steal that.

Good callout on the tokenizer — I was measuring character reduction, not actual token savings, so the real gains are smaller than the headline numbers suggest. You're right that this matters most at the edges: Haiku, large codebases, or heavy memory systems where the context budget is genuinely tight. On Opus with a simple project CLAUDE.md it's probably not worth the readability hit.

This is the cleaner solution honestly. Keep the human-readable version as source of truth, generate the compressed version as a build step. I've been doing it manually but automating that transform is the obvious next evolution. Might be worth a follow-up post.

Fair point — headers do carry semantic meaning for section navigation, especially in longer files. My experience was that removing them didn't change behavior noticeably, but I was working with fairly flat files. If your CLAUDE.md has deep nesting where heading hierarchy actually matters for context, keeping them makes sense. The table compression is probably the higher-ROI change for most people regardless.

Curious if others have experimented with this — I found the memory system files compressed more aggressively than the project CLAUDE.md because they had more prose decoration. Anyone tried a middle ground where you keep human-readable formatting in the project file but compress the memory files only?