47,065 words before my first prompt

In the one session where I counted, Claude Code read 47,065 words of my own instructions before I typed a request. About 39,000 of them were rule files that only matter when a particular kind of task comes up, and they loaded anyway. I had built a system that reread my accumulated rules and their histories before every task, needed or not.

Why the file exists

I work alone, so a file called CLAUDE.md does a team's job. Claude Code, the AI assistant I build with, rereads it at the start of every conversation. It sets hard limits: merging code, deploying, and spending money all mean stopping to ask me first. It also points to rule files for the kinds of work I do, such as testing before something ships, pricing, and anything touching security or law.

Each time I learned something in one of those areas, I wrote it down next to the rule it justified. I wrote in the story behind each lesson: a legal citation that turned out not to apply, and a test that would have passed for the wrong reason. Over time the file became a running log of everything I'd figured out, far more than the rules I needed on hand. Every conversation paid for all of it, plus rule files that loaded whether or not the task needed them.

What loaded

The 47,065 words broke down like this, as measured that day.

What 18% means

After one ordinary request, my status line showed 18%. My files were only part of that.

The status line is a live readout of how full the model's context window is. A context window is how much material a model can hold at once: instructions, history, files and my request, all sharing the same space. A token is the unit it counts in, a chunk of text a bit shorter than a word on average. I run Claude Sonnet, whose window is a million tokens by default, so 18% is about 180,000 tokens. I never measured the old files in tokens, and words understate them: my current three memory files are 5,514 words, and Claude Code's /context counts them at about 15,000 tokens. At that rate my 47,065 words would be well over 100,000 tokens. Claude Code's own instructions and tool descriptions fill part of the rest, and I haven't verified what the status line includes.

Matt Pocock, a developer who posts about working with these tools, put the threshold this way (SOTA means state of the art):

Trying to push coding sessions deep into what I would consider the "dumb zone" of SOTA models: >100K tokens. The drop-off in quality is really noticeable. Dumber decisions, worse code, worse instruction-following.

By his number, 180,000 tokens is nearly double that line, though it's only one practitioner's observation and says nothing certain about my setup.

The research

The research below didn't test a rule file like mine, and I can't point to a case where the bloat made Claude Code get something wrong. But 39,000 words of task-specific rules loaded for every task is the opposite of minimal, and the research points the same way. Chroma's research team tested 18 leading models in July 2025 and found performance varied significantly as the input grew longer, even on simple tasks like pulling one fact out of a pile of text. A 2023 paper, "Lost in the Middle", found models did best with relevant information at the start or end of a long input and worse when it sat in the middle. Anthropic's engineering team recommends the minimal set of information that fully describes the behavior you expect.

The fix

One guide I found says to leave war stories out of the file entirely. I'd rather keep mine where I can find them, so I moved the reasoning behind each rule into separate dated history files and left a one-line pointer beside the rule.

The bigger lever was a Claude Code setting called claudeMdExcludes, which lists files to leave out of the automatic load:

"claudeMdExcludes": ["/path/to/.claude/rules/**"]

The excluded files stay readable, and each one has a skill (a saved workflow I can invoke) meant to read it when its task comes up. The pricing file needed one extra step. No skill read it, yet it loaded every session, so I gave it a skill of its own, which I run when I'm reviewing a pricing model.

When I trimmed the main file, two AI reviewers (one Claude model, one OpenAI's Codex) disagreed on how far to go. One wanted about 180 lines, and the other said under 200 wasn't possible without cutting something that mattered. I took the smaller cut.

Three misses

• I already had a process built to catch the history part of this. I've run it against this file at least six times, twice after I added a check meant to flag a file once its history passes about a fifth of it. Every pass added an entry and none removed one. Step 2 of the audit prompt below is the check it should have run. That flag was only advice, so I've made moving the history out a required stop in that process once a file passes the line.
• I called the change basically just a file move, fully reversible. The folder had no version history, so a bad cleanup had no undo. In a review of the cleanup plan, Claude and Codex both caught it and recommended a backup before I touched anything. I made a full copy of the folder on September 2.
• The settings file that now controls what loads wasn't on my list of files that need extra care before editing, and I've added it.

Steal this pattern

Audit your own

If you keep a CLAUDE.md or something like it, paste this into your AI assistant. It audits the file, proposes the cleanup, and reports the before and after:

You are auditing my CLAUDE.md setup for context bloat. Do not change anything until I approve it. Label every number in your report "measured" (from a command you ran) or "estimated" (your inference).

1. BASELINE. List every file that loads automatically at session start: CLAUDE.md files at every level, rules files without path scoping, anything they import, and any memory index. Run a word count on each. Report the total, plus the tokens and share of my context window as your tool counts them (in Claude Code, run /context), not a words-to-tokens guess; ask me for the window size if you don't know it. Label this "share occupied by these files", not total context usage, and say which numbers your tool reported and which you calculated or estimated. Record any status-line or /context reading separately and say what it measures, if you know.

2. EXPLANATION VS RULE. For each rule, check whether its explanation (why it exists, what happened, who caught it) is longer than the rule. Flag any section where history is more than about a fifth of the text.

3. LOADING. For each loaded file, say which kinds of recurring tasks need it. If my tool can leave files out of the automatic load (Claude Code's setting is claudeMdExcludes), name the setting and show the exact line to add.

4. CONSUMERS. For each file you would exclude, name the skill, command, or step that will read it, then check that its instructions actually tell it to read that file, and that the file gets read when a matching task runs. If you can't verify that, mark the exclusion "pending" instead of recommending it.

5. SPOT CHECK, BEFORE. Ask me to pick three typical tasks. Run each in a fresh session now, before any change, and record for each: tokens used, time taken, and whether it followed the rules it needed.

6. PLAN. Give me a ranked list of changes with the estimated words saved for each. Wait for my approval of each one.

7. APPLY. After approval: back up the folder first (it may have no version history). Never delete history. Move explanations to a dated history file and leave a one-line pointer behind.

8. REPORT. Re-run the step 1 word counts, then re-run the same three tasks, each in a fresh session, with the same prompts and model and starting from identical project files. Check which files loaded in each session. To test loading alone, keep all instruction-file contents fixed and run the three tasks with rule-file exclusion disabled, then enabled, each in a fresh session under the same conditions; report that separately from the overall cleanup comparison. Show a before/after table: words, tokens and share of the window as your tool counts them, and for each task the tokens, time and whether it still followed its rules. Say plainly that three tasks are a spot check, not proof of general speed or quality gains.

Still rough

The status line can't tell me whether the fix worked. It read about 9% after the fix, down from 18%. That is roughly 90,000 tokens against 180,000, and just under Pocock's line. I noticed the two readings in different sessions, so they are not a controlled comparison, and I didn't measure the removed text in tokens, so I can't say how much of the drop the cleanup explains.

Three things are still unverified:

• Whether Claude Code runs faster or answers better.
• Whether every task path that should read an excluded file does.
• What the eleven rule files actually say, which I haven't audited.

The next step is the audit prompt's three-task check, run on the current files with the automatic rule-file load switched on, then off, which tests the loading change rather than the whole cleanup.

Marie Kondo says to keep only what sparks joy. I kept the war stories too, in a drawer I open when I need them.

This is a live, unfinished project. If you're working through something similar, I'm taking on new work now.