Anthropic Cut 80% of Claude Code's System Prompt. Your CLAUDE.md Is Probably Going the Other Way

Anthropic published a line last week that is easy to skim past:

“We removed over 80% of Claude Code’s system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations.”

That is their number, from their own evals. I did not run it and I have no way to verify it, so read this as a close reading of their post and their documentation, not as a benchmark I did. But if the team that builds the tool deleted four fifths of the instructions they give the model, and their scores held, it is worth asking why your CLAUDE.md only ever gets longer.

Mine did. That is what sent me into the docs.

Why deleting instructions did not break anything

The intuition most of us carry is that instructions are free insurance. If a rule might help, add it. Worst case it sits there unused.

That intuition came from weaker models. When a model could not reliably infer that a Go repo with a Makefile runs its tests through make test, you told it. The instruction was doing real work.

A more capable model reads the Makefile. The instruction is now describing something the model can already see, and it is not free: it takes up room, and it competes for attention with the instructions that actually matter. Anthropic’s own guidance says this plainly, in the section on writing effective instructions: longer files “consume more context and reduce adherence.”

Reduce adherence. Not just cost more. A longer file makes the model follow your rules less reliably.

What your file actually costs

Three facts from the Claude Code docs, all of which surprised me in the detail:

It loads on every session, in full. CLAUDE.md is read at the start of every conversation and concatenated into the context window before you type anything. There is no partial loading, no relevance filter. Anthropic’s stated target is under 200 lines per file.

It is not one file. Claude Code walks up the directory tree and loads every CLAUDE.md and CLAUDE.local.md it finds along the way, concatenating them from filesystem root down to your working directory. In a monorepo you can be carrying three other teams’ instructions without knowing it. There is a claudeMdExcludes setting precisely because this became a problem.

Splitting it up does not help. This is the one that got me. If your file grew and you tidied it into @path/to/file.md imports, you did not reclaim any context. The docs are explicit: imported files “still load and enter the context window at launch.” Imports are organization, not compression. Same for AGENTS.md: importing it into CLAUDE.md loads the whole thing.

What prompt caching does and does not do

This is where I see the most confident wrong takes, so it is worth being precise.

Claude Code caches by prefix. Each request re-sends everything: system prompt, project context, full history. The API matches the start of the request against what it recently processed and only computes what changed. Cache reads bill at roughly 10% of the standard input rate.

So caching genuinely helps with what you pay to reprocess those tokens on every turn. What it does not do is make them stop occupying the context window. Your instructions sit in the project context layer, in front of the actual work, on every single turn, cached or not. Cheap to re-read is not the same as absent.

There is a second-order effect worth knowing: CLAUDE.md sits in the cached prefix, so editing it mid-session does nothing. Claude keeps using the version loaded at session start until you /clear, /compact, or restart. If you have ever edited the file to fix a behavior and seen no change, that is why.

The three things filling your file

Reading my own file against the docs, everything I could cut fell into one of three piles.

Rules the repo already states. “Use 2-space indentation” when .editorconfig says indent_size = 2. “Run tests with make test” when the Makefile has one target. “Prefer table-driven tests” when every _test.go file in the repo is table-driven. The model reads these files. You are paying context to repeat them, in a weaker form, without the authority of the actual config.

Rules that contradict each other. Long files accumulate. Something you added in March quietly disagrees with something you added in June, or with a skill you installed last week. The docs describe the outcome without softening it: if two rules contradict, Claude “may pick one arbitrarily.” Then you debug the model instead of the file.

Procedures that only matter sometimes. A twelve-step release checklist you run twice a month is loaded into every session about anything, including the ones where you are reading a log file. Anthropic’s rule of thumb: if an entry is a multi-step procedure or only matters for one part of the codebase, it does not belong in CLAUDE.md.

What earns its place

The docs give a test I have started using, and it is sharper than “keep it short”: write down what you would otherwise re-explain. Add something when Claude makes the same mistake twice, when a review catches something it should have known about this codebase, when you type the same correction you typed last session, or when a new teammate would need the same context.

In practice that leaves three categories:

What the repo is for. One or two lines. What this service does, what it talks to.
The non-obvious gotchas. The legacy auth path nobody should touch. The forward-only migrations. The thing that looks like a bug and is load-bearing. This is the highest-value content in the file, and it is the part a model genuinely cannot derive.
The hard constraints. Never commit generated protobuf. Never push to main. The rules where being wrong is expensive.

Anthropic’s own tooling agrees with this split, which I found more convincing than the prose. The /doctor checkup now proposes trims for a checked-in CLAUDE.md, and the docs describe its criteria exactly: it cuts what Claude can derive from the codebase, naming directory layouts, dependency lists, and architecture overviews, and it keeps pitfalls, rationale, and conventions that differ from tool defaults.

Read that list again. Directory layouts and architecture overviews are what most /init-generated files are mostly made of.

Where the rest goes

Cutting is only half of it. The content usually still has value, just not in a file that loads unconditionally.

Skills, for task-specific workflows. They load when you invoke them or when Claude decides they are relevant to the prompt, not at startup. Your release checklist belongs here.

Path-scoped rules, for instructions that apply to part of the codebase. A file in .claude/rules/ with paths: ["src/api/**/*.ts"] in its frontmatter enters context only when Claude touches a matching file. This is the mechanism to reach for when your file is long because the repo is big, rather than because the file is bloated.

Code and tests, for everything they can state better than prose. A rule that duplicates .editorconfig should just be .editorconfig. A convention that every test file follows is already documented by every test file.

One small thing while you are in there: block-level HTML comments are stripped before the file enters context. Notes for human maintainers cost nothing if you write them as .

How to actually do this

The loop that worked for me, in about twenty minutes:

Run /context in a session and look at Memory files. This tells you what is actually loaded, including ancestor files you forgot about. Start from reality, not from the file you think you have.
Run /doctor and read its trim proposal. You do not have to accept it wholesale, but it is a fast first pass at the derivable content.
Go line by line with one question: could the model work this out from the repo? If yes, delete it. If it is a procedure, move it to a skill. If it applies to one directory, move it to a path-scoped rule.
Look for pairs that disagree. This is the pass people skip and it is the one that fixes weird behavior.
Check the line count against 200.

The part I am still unsure about

I want to be careful not to oversell a number I did not produce. Anthropic reduced their system prompt, measured against their coding evals, for their newest models. That is not the same claim as “your 400-line CLAUDE.md is hurting you,” and I have not run a controlled comparison on my own repos. What I can say is that the guidance, the 200-line target, the adherence warning, and the /doctor trim criteria all point the same direction, and they come from the people with the eval data.

The direction is what matters here. We spent two years learning to write more context for models that needed it. The models changed underneath that habit. A file that grows every time something goes wrong is optimizing for a model that no longer exists, and the cost is not just tokens, it is the rules you actually care about getting less attention.

So: what is the oldest rule in your CLAUDE.md? Mine was a formatting instruction from a project that had a .prettierrc the whole time.

Reporting and documentation reading, not firsthand benchmarking. Sources: Anthropic’s “The new rules of context engineering for Claude 5 generation models” (July 24, 2026), and the Claude Code documentation on memory and prompt caching.