Anthropic Deleted Over 80% of Claude Code's Prompt. I Cut My CLAUDE.md by 79%.

On July 24, Anthropic said it had removed more than 80% of Claude Code’s system prompt for its newest models. Its coding scores held. Most CLAUDE.md best practices you read last year became suspect overnight.

If you maintain a CLAUDE.md file, that should make you uncomfortable. Anthropic now calls much of the old advice “myths”: give rules, give examples, put everything upfront, repeat yourself.

I checked my own setup. In late September I cut my CLAUDE.md by 79%, from 40,405 characters to 8,641.

But I did not delete most of it. I moved it behind pointers. Anthropic’s story is mostly about deleting. Mine is mostly about moving, and the difference says a lot about what your instructions are.

I read Anthropic’s original post, the relevant sections of the prompting guides for Opus 5, Opus 5.5, Fable 5.1 and Sonnet 5.5, and the Claude Code docs, and I traced every quote to its source. I started from a summary on Claude Fast and went to the primary sources for the rest.

Key Takeaways

• Anthropic removed over 80% of Claude Code’s system prompt with no measurable loss on its coding evaluations. Anthropic has not published the same test for marketing, writing or operations work.
• Anthropic’s diagnosis was overconstraining. Stale worst-case rules and rules that clash made the model referee before it could work. Length matters too.
• One test decides every line: would a strong model behave worse without it? Add a second question: how bad is the worst case if it guesses wrong?
• Delete instructions that copy the model’s competence. Move occasional procedures behind pointers. Keep the facts about you that no model can guess. My file fell 79% mostly by moving.
• Put verification in checks a machine can fail. Tests, hooks and deny rules are deterministic. “Be careful” is a suggestion that costs tokens.
• Deleting is a practice, not an event. My file grew 17% in 13 days. Date every rule and write down why it exists, so you can test it again when the model changes.

What Is Context Engineering, and How Is It Different From Prompt Engineering?

Context engineering is the practice of designing everything a model reads besides your question: the system prompt, CLAUDE.md files, skills, memory, tool descriptions and reference files. A prompt serves one request. Context is reused across thousands of them, so one wrong line becomes a tax you pay every time.

A CLAUDE.md file is a plain text file at the root of your project that Claude Code reads at the start of every session. It holds the facts, rules and pointers the model cannot guess. Good CLAUDE.md best practices keep it short, specific and free of rules the model already follows.

The term took off in June 2025, when Simon Willison collected the reactions of Shopify’s Tobi Lütke and Andrej Karpathy, who both preferred it to “prompt engineering”. Anthropic’s essay from September 29, 2025 set the principle that still holds: find the smallest set of high-signal tokens that makes your outcome most likely.

Context also fails in ways a single prompt does not. Drew Breunig named four in June 2025: poisoning, distraction, confusion and clash. Clash, new information that contradicts what is already in the context, is the clearest example in Anthropic’s July post.

What Anthropic Deleted

The post is The new rules of context engineering for Claude 5 generation models, by Thariq Shihipar, a seven-minute read. The headline claim: Anthropic 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.”

Two details matter. The first is the scope: coding evaluations. The post does not break down which kinds of tasks held up.

The second is the diagnosis. Anthropic says it was overconstraining the model, through its system prompt, its CLAUDE.md files and its skills. Its own transcripts showed conflicting messages inside one request, such as “leave documentation as appropriate” in one place and “DO NOT add comments” in another. The model can work out what you want, but it has to think harder first.

Anthropic did not only delete. It also moved verification and code review into skills, and it has not published how the 80% splits between deleted and moved.

Take the comments rule. The old system prompt told Claude to default to no comments, no long docstrings and no planning documents unless asked. It was a trade-off: older models wrote bad comments, so Anthropic accepted a rule that was wrong whenever someone wanted documentation.

The new prompt replaces it with one sentence:

Write code that reads like the surrounding code: match its comment density, naming, and idiom.

Claude Fast puts the shift well: a rule that is right most of the time became a criterion that is right all of the time.

You know this pattern from marketing. The brand book says one thing, the agency brief another, the CEO’s late-night email a third. The model is the person who has to deliver one output that satisfies all three.

The Six Shifts, Translated for People Who Do Not Write Code

Anthropic lists six old habits that became myths. Here is the business version of each, because the logic applies to any brief you hand to a person or a machine.

Shift two has a relative from a year earlier. In July 2025 the team behind Manus wrote that language models are “excellent mimics”. Their agent, reviewing 20 resumes, often fell into a rhythm and repeated the pattern. Anthropic found that examples in tool descriptions narrow what a model explores, and in a figure in its post the TodoWrite description shrinks from about 9,100 characters to one line. Different setups, a related effect.

Shift four is my favorite. Older models could listen harder to the end of the context than to the start, so teams repeated their critical rules. Anthropic deleted the repeats and moved tool guidance into the tool descriptions.

Repetition is also how contradictions are born. Say a rule in three places and sooner or later you edit only two.

The One Test Behind Every Line, and the Question It Misses

Claude Fast boils the method down to one question for every line: would a strong model behave worse without this line? If not, delete it.

It is a good test, and it is not new. The Claude Code docs already carry a twin: “Would removing this cause Claude to make mistakes?” followed by “If not, cut it.” The docs add why: bloated CLAUDE.md files cause Claude to ignore your actual instructions. What changed in July is how many lines fail the test.

Here is what the test misses: how bad is the worst case? Anthropic says the early rules existed to avoid worst-case scenarios such as deleting files. A strong model may do the right thing 999 times out of 1,000. The thousandth time is the one that costs you a client.

Even when Anthropic’s Sonnet 5.5 guide hands you a prompt for more autonomy, it adds that the prompt “doesn’t replace your own rules about risky or irreversible actions. Keep those rules in your system prompt.”

So score each line twice. How likely is the model to get it right alone, and what does it cost if it does not? Cheap and likely: delete. Expensive: keep the rule, and back it with something that cannot be argued with. The docs draw the line themselves: CLAUDE.md instructions are advisory, while hooks are deterministic.

On October 9, Claude Code’s auto mode, where a separate classifier model reviews actions, stopped a script that was about to write to a live production system. It stayed stopped until I wrote one sentence naming the action, the resource and the script. “Go ahead” was not enough.

A rule in a file is a suggestion. A second model reviewing is better. Only a hook or a deny rule is a guarantee.

CLAUDE.md Best Practices After Claude 5: Delete, Keep or Move

My vault is a second brain that runs on Claude Code. I explained the setup in my second brain article. The CLAUDE.md at its root is the kernel: it loads in every session, whether I am working on a client, a campaign or this blog.

By September it had grown to 40,405 characters. On September 26 I had my agents rebuild it. The new file is 8,641 characters, a 79% cut. Five working-memory notes shrank by 41% to 79% in the same pass, one from 17,363 characters to 4,883.

Here is the twist. I did not delete most of it. I moved it.

The 79% is the always-loaded size. The 19 sections of the old file now live in seven wiki pages that open on a trigger. The core that remains has six short sections: identity and style, session start and logging, writing and search, hard constraints, a table of 13 triggers, and the rules for maintaining the file itself.

Each trigger says: when you work on this, open that page first. Nothing is imported. The new risk is a trigger that fails to fire, so every trigger names its page.

Before touching anything, my agents backed up 18 files with a checksum. Afterward they checked that the twin file AGENTS.md was identical byte for byte, and that 205 links across the core, the manual and the chronologies still resolved.

Why move instead of delete? Because of what my instructions are. Claude Fast says most of what it cut was instruction, not information: lines telling the model to be careful or think step by step. Anthropic does not itemize its 80%. Mine are mostly facts about one person’s business that no model can derive.

A model cannot guess that I want Italian by default. It cannot know that my CDN rejects the default user agent of Python scripts. It cannot know that no ad campaign changes without my explicit go. Claude Fast calls this “information the model cannot derive.” It survives any test. The only question is where it lives.

One warning from Claude Fast, and it is right. Some lines look boring and are gold. Project facts “are the highest-value lines in your CLAUDE.md and they look boring, which makes them exactly what an enthusiastic deletion pass destroys.”

Progressive Disclosure Is Good Filing

Anthropic’s fix for “put it all upfront” is a tree of files that can be loaded at the right time. The post calls the opposite a myth: the belief that you must keep every practice in one central file because Claude “would not find it otherwise.” Claude Fast says it shorter: Claude will find it.

My version is a filing system with size budgets:

1. The router. One index note of businesses and areas, a few thousand characters.
2. The area index. The clients and activities of one company.
3. The working note of one activity. A goal of 1,000 to 3,000 characters and a ceiling of 10,000.
4. Wiki pages and raw sources. Opened only when a task needs them.

At the start of a session the model reads the core and one working note. It does not read the rest. Most of my memory sits on disk and costs nothing until a trigger opens it.

A trap worth knowing: imports are not progressive disclosure. The Claude Code docs are flat about it: imports help you organize a long file but don’t reduce its context cost, because imported files also load at launch. Split a 600-line file into six imports and you have six files and the same 600 lines. What saves context is a rule that loads only for certain folders, a skill, or a plain pointer the model follows when needed.

The second half of this shift is replacing thresholds with criteria. Claude Fast’s example sent work to specialist agents by file count. A 40-file rename crosses the threshold and is one mechanical job. A three-file change touching a database migration, an API contract and a form needs three kinds of expertise. So the criterion became domain count, plus one worked example of where the bar sits.

You know this from budgets. “Any spend above 5,000 needs approval” is a threshold. “Anything you cannot undo needs approval” is a criterion. The threshold lets the 4,900 mistake through. I keep the criterion as the rule and a number only where a client has set a real cap.

Do not overshoot. Shihipar’s Fable field guide warns that if you are too specific, Claude follows you even when a pivot is better. Too vague, and it fills the gaps with generic best practice. Test to find the middle.

The Verification Trap, and the 17 Dollar Lesson

Every instruction file I have seen contains some version of “verify your work before reporting.” It feels like diligence. Anthropic’s Opus 5 guide says it backfires. Opus 5 verifies its own work without being told to, and explicit verification instructions “cause over-verification on Claude Opus 5, and removing them reduces wasted tokens with no loss in quality.”

The same guide warns that Opus 5 delegates to subagents more readily than earlier models, and it recommends deterministic caps on how many can run.

On October 9 I learned why. I asked my setup to research an article. It launched ten research agents in parallel, and they inherited the session’s maximum effort. Eight more were planned.

I stopped it after six minutes. It had made 233 calls and processed about 31 million tokens, almost all of them re-reads of web pages already sitting in context. The usage meter showed about 17 dollars. The research output was zero finished dossiers.

A second workflow that morning, with no effort set, processed about 287 million tokens in 40 minutes. Anthropic had warned that its own workflows “may end up using significantly more tokens”.

My first fix was a ceremony: estimate the cost and ask me before every workflow. I rejected it as slower and no safer. The second fix was an interface. Effort became a required parameter on every agent call: low for web research and mechanical work, medium for writing and translation, high only for a truly hard judgment.

Anthropic’s Opus 5.5 guide explains why that helps: lowering effort cuts thinking, and cost and latency with it, “more reliably than prompt instructions do.” That is shift two in practice. Do not describe the behavior in prose. Design the control.

Effort cuts thinking, not re-reads, though. The stronger brake is a cap. The Opus 5 guide names CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS, CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH and, for the SDK, max_budget_usd, all from Claude Code 2.1.217. Those are settings, not suggestions.

Two nuances. The Sonnet 5.5 guide says one stop instruction against reviewer subagents cut session cost by about a third at max effort on coding tasks, with no change in quality. It also says that at low effort Sonnet 5.5 can skip checks, and a short prompt asking for real checks makes that rare. It depends on the model and the effort.

So where should verification live? In checks the project already has: tests, a build, a hook. Add a separate reviewer with a rubric only where taste or stakes are high, as Anthropic’s workflows do, because a model tends to prefer its own results. A check a machine can fail beats a sentence asking for care. For what a real check needs beyond a sentence asking for care, see my piece on human in the loop AI.

Where Deleting Goes Wrong

It is a coding result. Anthropic wrote “no measurable loss on our coding evaluations.” As AI Weekly noted, the post does not break down which task categories held up. I found no published test on brand voice, legal copy or client reporting. Test your own tasks.

It is Claude 5 advice. Even inside the family the guides differ: Anthropic’s Opus 5.5 guide says effort level names don’t correspond to the same amount of thinking across models. If your stack mixes models, as mine does with GLM and Kimi next to Claude, tune the behavior rules per model. My mirrored files can share one core only because it is mostly model-neutral facts and pointers. I wrote about GLM 5.3 if you want the open-weight side. If you route work across Claude models, my comparison of Claude Haiku, Sonnet and Opus for marketing puts prices next to the jobs.

A big window is not the same as attention. Chroma’s Context Rot report, from July 2025, tested 18 models, including Claude 4, and found that reliability fell as input grew, even on simple tasks. Anthropic says Claude Opus 5’s instruction following, tool calling and reasoning stay consistent throughout its 1M token window, but the guide publishes no figures. Different models, a year apart: I would not bet either way.

Two points stay practical whichever claim holds. On Chroma’s memory test, focused inputs beat full ones. And Manus pointed out that on Claude Sonnet, cached input tokens cost a tenth of uncached ones, so a stable prefix saves money.

Claude Code Memory: Rent It or Own It

Shift five says the # hotkey is out and auto-memory is in: Claude now saves memories relevant to the work and to you. I use it. The Claude Code docs give the fine print. Auto memory is machine-local by default, only the first 200 lines or 25KB of its index load each session, and it skips anything Claude can derive from your code.

Claude decides what to save, which is great for habits and corrections, the small things you would never write down. It is a poor home for decisions you must defend in a meeting. It is plain markdown you can review, but it still sits in one tool’s folder.

My rule: canon in files I own, auto-memory kept short, mostly pointers and small corrections. The vault moves between my machines, and the same rules reach other agents through the AGENTS.md twin. The docs now describe Claude Code reading AGENTS.md in place of CLAUDE.md, so the twin may be a habit I can retire.

When I audited the twelve PhotoCraft repositories for my open source Photoshop alternative article, every one of them shipped an AGENTS.md. Context files are the new README.

Deletion Is a Practice, Not an Event

Here is the part nobody puts in a headline. On October 9, thirteen days after my cut, my CLAUDE.md is 10,127 characters. That is 17% bigger than the day I trimmed it, and above the 10,000 ceiling I set myself. Instruction files grow back like weeds, one reasonable addition at a time.

So I treat every rule as a hypothesis with a date. A rule in my notes carries what, why, how to apply it and the day I decided it. I set my compaction threshold, the token count at which a long session gets summarized, three times within three days in July: 500,000 tokens, then 400,000, then about 100,000. That history sits next to the rule.

Add one more field to yours: how you would know it is safe to remove. When a new model arrives, ask whether the reason still holds.

Claude Fast has a line for this: “Your old guidance does not become wrong retroactively.” The trade-off changed, not the logic. I want my future self to read my rules as decisions made under older conditions, not as mistakes.

A 30-Minute CLAUDE.md Audit You Can Run Today

Set a timer. Plan on 30 minutes for a short file, longer for a big one. You need a copy and an honest eye.

1. Copy the file or commit it to git. Keep the original. Nothing you delete is lost if you can get it back.
2. Run /doctor prompt-audit. It needs Claude Code v2.1.283 or later. Read the report for dead references, contradictions and rules written for older models. Apply nothing yet.
3. Pick 3 to 5 real tasks and save the outputs. That is your baseline.
4. Sort every line: delete, keep or move. Delete what you have tested a strong model does anyway, such as “be careful”. Keep what it cannot derive and what is expensive to guess wrong. Move the rest behind a pointer. Keep a role or a think-first line if a test shows it helps, especially outside coding.
5. Hunt duplicates and contradictions. Search for each core rule. If it appears in three places, you have three versions of it.
6. Turn “be careful” into a check a machine can fail. A test, a hook, a deny rule. Add a rubric reviewer only where taste is the product.
7. Swap thresholds for criteria. Add one worked example of where the line sits.
8. Cut in batches and rerun the tasks. Restore any batch that makes results worse. Then date what survives and say why, and put a reminder in your calendar for the next model release.

Be suspicious of the lines you cannot bear to cut. Some are gold. Most are scar tissue.

Frequently Asked Questions

Is a CLAUDE.md file needed?

No, but it is the cheapest place to keep what Claude cannot guess. Anthropic’s advice is to keep it light, say what the repo is for and spend most of the tokens on gotchas. Auto-memory can cover habits and corrections.

How long should a CLAUDE.md be?

The Claude Code docs target under 200 lines per file, because longer files cost context and reduce adherence. Lines are a rough measure: mine runs 71 lines but about 10,000 characters, so I watch contradictions and characters.

Does deleting instructions make Claude worse?

On its coding evaluations Anthropic found no measurable loss. For other work there is no public test, so remove lines in small batches and compare on your own tasks. One symptom from the Claude Code docs: if Claude keeps ignoring a rule, the file is probably too long.

What does /doctor do?

Two things, according to the docs. A trim check proposes cuts for a checked-in CLAUDE.md: it drops what Claude can derive from the code, such as directory layouts and dependency lists, and keeps pitfalls, rationale and non-default conventions (Claude Code v2.1.206 or later). /doctor prompt-audit finds instructions written for older models, dead references and contradictions, and proposes edits without applying them.

Is prompt engineering dead?

No. You still write the brief for each job. What died is stuffing the standing context with rules a strong model already follows.

My Verdict

Anthropic’s lesson is not “write less.” It is this: stop writing instructions a strong model already follows, and start curating what it cannot know.

CLAUDE.md best practices after Claude 5 fit on a card:

1. Cut what duplicates competence.
2. Keep what only you know.
3. Move what is occasional.
4. Lock anything dangerous behind a mechanism, not a sentence.
5. Date it and come back.

This page reflects the guides as of October 9, 2026. Anthropic revises them often, so check the dates before you rely on any detail.

New to building with agents? Start with my guide to vibe coding. Already running them and want a second pair of eyes on your instruction files or your setup? Get in touch.