Claude Code feels slow? Config bloat is a latency tax, not just a billing one.

Most write-ups about a fat CLAUDE.md talk about cost. The weekly cap, the Opus rate, the token bill. That is real. But the symptom most people feel first is not the bill at the end of the week, it is the two-second pause at the start of every turn. That is the latency tax. It comes from the same bytes that cost you money, on a different axis.

This page walks through where the latency lives in a CLAUDE.md, which ccmd.dev analyzer findings actually map to it, and the order to fix them in. I wrote it because every existing guide on the topic ends with "cut your CLAUDE.md", which is true but treats config bloat as a billing problem. If you are reading this on your phone after hitting a slow turn, you are here because of latency, not the bill.

1. Where the latency lives

A single turn of Claude Code has roughly five places time goes:

1. Network upload of the request. The full system prompt (CLAUDE.md + skills + tools + history) travels over the wire on every call. A 6,000-token CLAUDE.md is about 24KB of plaintext on its own.
2. Prompt prefix lookup. Anthropic checks whether the prefix of this request matches a cached prefix from a previous request. Byte-exact match required.
3. Input processing (time-to-first-token). On a cache hit the cached prefix is replayed cheaply. On a cache miss the full input has to be processed before the model can emit its first character.
4. Generation. Output tokens stream back. Roughly linear with the length of the answer, mostly independent of CLAUDE.md size.
5. Network download. Same shape as upload but smaller.

CLAUDE.md bloat hits the first three. It cannot make generation faster and it cannot make the download faster. What it can do is double or triple time-to-first-token by forcing a cache miss, and add a steady tax to network upload on every single turn for the rest of the session.

2. The two analyzer findings that are also latency findings

Our analyzer at src/lib/analyzer.ts has seven finding kinds. Five of them are quality findings (vague, aspirational, conflict, duplicate, missing_why). Two of them are structural and they double as the latency findings: cache_bust and bloat. Here are the actual checks, lifted verbatim from the analyzer.

The cache_bust check is the one that matters most for latency. The regex /\b20[2-9]\d-\d{2}-\d{2}|today|this session|right now\b/i runs against every one of the first 20 lines of the file. A single hit means every new session writes a different string at that position, which means the cached prefix never matches, which means every turn pays the uncached time-to-first-token path. One line.

The bloat check fires on any non-blank line over 28 words. The analyzer's suggested fix is to split into 2-3 shorter directives. The published token saving on the fix is 35% of the line. The latency saving rides with it: 35% fewer bytes uploaded for that line, on every single turn, for the life of the session.

3. What an analyzer pass on a real file looks like

A 6,042-token CLAUDE.md from a Next.js payments repo. Four bloated lines and one cache_bust. The latency view of the report:

The first block is the bytes you pay for every turn. The second is where the time-to-first-token gap is hiding. Fix L3 and every subsequent session hits the cached path; fix L15, L42, L73, L88 and the cached path itself gets shorter.

4. The numbers that move when you fix this

Two of these numbers move latency directly. The cache_bust count going from 1 to 0 moves every turn in every new session from the uncached TTFT path to the cached one. The bloat-line count going from 4 to 0 shrinks the bytes uploaded on every turn by a few hundred tokens, which compounds across a 30-turn session.

5. Before and after on the same file

6. Why the cache_bust line ranks high-severity

The seven analyzer finding kinds are sorted by blast radius, not by line number. cache_bust is the only kind that flips a regime; it changes which TTFT path your entire session runs on. Every other kind shaves bytes off a single line.

The message text is the analyzer's own. The regex is the one shown in section 2. The check is ten lines of TypeScript and it is the highest-leverage single fix in the entire rubric for anyone who cares more about Claude Code feeling fast than about the weekly dollar number.

7. The order to fix in, if you only have ten minutes

1. Delete every cache_bust hit. Anything matching YYYY-MM-DD, today, this session, or right now in the first 20 lines either goes to the bottom of the file or out of the file entirely. One delete, every future session hits the cached TTFT path.
2. Split every line over 28 words. One 34-word stack paragraph turns into three 8-word directives. The second half of long lines was being ignored anyway; you keep the meaning and stop paying to upload bytes the model is skipping.
3. Pin the first 20 lines as byte-stable. Treat the top of the file as the cache key. Project name, language, framework, package manager. Nothing that changes between sessions. Anything that does change (sprint, ticket, focus) lives lower or in a separate file the agent reads on demand.
4. Move volatile context to a tool, not a rule. Today's date belongs in a tool call, not in the system prompt. The agent can ask for it when it needs it. The cache stays warm.

The whole sequence runs in roughly ten minutes on a typical file. You will feel the difference on the next session before the bill confirms it.