Should you delete your CLAUDE.md for Opus 5?

Delete most of it. Keep the part your team depends on. Delete CLAUDE.md as a token-hoarding prompt file; keep it as governed, version-controlled team context — because agent-written auto-memory is per-user, unversioned, and invisible to everyone else on the team. Anthropic's argument is mostly right, and the parts that are right are worth acting on this week.

What Anthropic actually published

On 24 July 2026, Anthropic published The new rules of context engineering for Claude 5 generation models. The number that carried the post: more than 80% of Claude Code's system prompt was removed for Opus 5, with no measurable loss. Not trimmed. Removed. The instructions that used to be necessary scaffolding for a weaker model are now noise for a stronger one.

The post lists six flips — old practice on the left, new practice on the right. Broadly, four of them are about token economy and progressive disclosure: stop writing verbose instructions where terse ones work, stop stuffing in examples the model no longer needs, stop pre-loading everything at session start when the model can retrieve it just in time, stop writing defensive guardrails against failure modes the model has stopped having. The fifth is about letting the model orchestrate rather than hand-scripting the steps. The sixth is the one that started the argument: memory in CLAUDE.md → auto-memory.

Separately, and this is secondary sourcing so treat it as such, Boris Cherny reportedly told an audience at YC Startup School to delete your CLAUDE.md, your skills and your hooks every six months. Reported, not published. But it landed as a headline, and it is the version most engineers heard.

Concede the four flips — they are correct

Here is the part most responses to that post skipped: the token-economy flips are correct, and they are correct in a way that is inconvenient for anyone selling a bigger context file.

If your CLAUDE.md is 400 lines of "always use TypeScript strict mode", "prefer async/await", "write tests", you are paying tokens on every single turn to tell a frontier model things it already does by default. That was defensible in 2024. It is dead weight in 2026. The same goes for the example blocks, the defensive "if the user asks X, do not do Y" clauses, and the elaborate step-by-step orchestration scripts. Opus 5 does not need to be told how to be careful.

Progressive disclosure is also correct. Loading everything a model might need at session start, on the off chance, is the expensive way to be prepared. Pointing the model at where to look, and letting it fetch when the task actually calls for it, is cheaper and produces a cleaner working set.

Notice what both of those arguments are actually arguments for. Terse, deduplicated, retrievable-on-demand context is not a description of a hand-maintained markdown file sitting in twelve repos. It is a description of a managed context layer with a retrieval interface. Anthropic made the case for ContextOps and then pointed the conclusion somewhere else.

The one flip that is hostile: auto-memory

Auto-memory means the agent decides what is worth remembering, writes it down itself, and reloads it next session. No human in the loop, no review step, no diff.

That is a real capability and for a solo developer on a side project it is straightforwardly good. The friction of maintaining a file about your own preferences, for yourself, is friction worth deleting.

For a team of forty engineers it is a different object entirely. Three named failure modes, all of which show up quickly at team scale:

It over-generalises single-instance feedback into universal rules. You tell the agent once, in one PR, not to use a barrel export in this particular package because of a circular-import problem. Auto-memory does not know that was local. It writes down "avoid barrel exports". Now it is a policy, invented from one data point, that nobody voted for and nobody can see.

It misses genuine architectural concerns. The things that matter most in a mature codebase are the things nobody says out loud in a session — why the payments service owns its own migrations, why this queue is at-least-once and the consumer must be idempotent, which of the two auth paths is the deprecated one. That knowledge does not surface as in-session correction, so auto-memory never captures it. What gets remembered is what got argued about, which is not the same as what matters.

It grows past the file it replaced. Nothing prunes it. The mechanism that produced a 400-line CLAUDE.md was accumulation without review, and auto-memory automates the accumulation while removing the review. Six months in, you have a larger unversioned artefact than the one you deleted, with no author and no history.

None of those three is a bug in the implementation. They are consequences of removing the review step, and they would show up in any system that writes context automatically and reloads it unread. That is the distinction worth holding onto: the objection is not to a model writing things down. It is to a model writing things down where nobody has to agree to them. A team standard is a claim about how forty people will work, and claims like that get reviewed. We review schema changes that touch one table. Reviewing the document that steers every agent on the team is not a higher bar than the one we already apply everywhere else.

What the 405 comments were actually arguing about

The Hacker News thread on the announcement hit 462 points and 405 comments, and it did not split along "Anthropic good / Anthropic bad". Almost nobody defended fat prompt files. The argument was about custody.

sothatsit put the objection most directly — this is opinion, but it is the load-bearing one in the thread: "Managing the context that agents have available to them is far too important to leave to the agents themselves."

jwr named the operational problem: auto-memories land "in a secret location", not version controlled. You cannot review what you cannot see, and you cannot roll back what has no history. Every other governed artefact in your stack — schema, IaC, CI config — lives in a repo with a diff and an owner. Agent context is the one place where the industry briefly decided that was optional.

pavlov named the commercial shape of it: "A CLAUDE.md file has no moat... Automemory can be weaved into the product in ways that make it harder to switch." Portable plain text is portable. Vendor-managed memory in an undisclosed location is not. That is not an accusation of bad faith, it is an observation about incentives — and it is worth holding in mind by anyone running three or more coding tools who would like their standards to apply to all of them. We have written up the multi-tool version of this in AGENTS.md vs CLAUDE.md for teams.

The claim we will not make

Shared context does not make your agents more accurate. We are not going to say it does.

A study published in this window (arXiv:2607.27250) ran 288 trials and found that context-file strategy does not measurably move correctness. That result is inconvenient for a lot of marketing, including ours if we were sloppy about it. So we will state the defensible claim precisely:

Governed shared context makes agents cheaper to run, consistent across a team, and auditable. Cheaper, because deduplicated context retrieved on demand beats the same 400 lines re-sent by nine engineers on every turn. Consistent, because the same conventions reach Claude, Cursor and Copilot instead of each developer's agent inventing its own house style. Auditable, because a change to a standard is a diff with an author and a date.

Cost, consistency and auditability are the whole case. They are also, notably, exactly the three properties auto-memory removes.

How we run this ourselves

We dogfood this in the most direct way available: the standards our own agents follow live in a Contextium workspace, and every agent — Claude Code, Cursor, whatever an engineer opened this morning — reads them as shared AI context over MCP. There is no CLAUDE.md in our application repo. There is a pointer.

The measurable thing that changed for us was not output quality. It was the review path. When we changed our rule on error handling in the API layer, that was one edit, in one place, with a diff and an author, and the next session every agent on the team picked it up. Under the old arrangement it was a PR against four CLAUDE.md files, of which two got merged and two drifted, and nobody noticed for a month because there is no test that fails when a convention file goes stale. Convention drift is not loud. That is what makes it expensive.

We also let auto-memory run, per developer, for per-developer things. It is genuinely good at that. It just does not get a vote on what the team's standards are.

What to delete this week, and what to keep

Open your CLAUDE.md and split it into two piles.

Delete: anything a frontier model already does. Style preferences the linter enforces. Restatements of your framework's documentation. Example blocks. Defensive clauses written against a 2024 model's failure modes. Step-by-step orchestration for tasks the model can now sequence itself. Cherny's reported six-month reset is a blunt instrument, but the instinct behind it is sound — this pile grows back, and something has to cut it.

Keep: anything that is true about your system and could not be inferred from reading the code in one sitting. Why a decision was made. Which of two plausible paths is the sanctioned one. The invariants that will silently break production. Ownership boundaries. Deprecations in flight. That material is not a prompt. It is institutional knowledge that happens to be consumed by an agent, and it needs the same custody as any other shared engineering artefact — version control, ownership, review, a rollback path.

If a line is hard to sort, one test resolves most of them: would a competent new hire, given a week and full repo access, arrive at this on their own? If yes, delete it — the model will get there too. If no, because the reason lives in a decision, an incident, or a conversation that never made it into the code, keep it. That question sorts most of a 400-line file in about twenty minutes, and it has a useful side effect: everything left in the keep pile is also the answer to a question a human asks during onboarding. The agent and the new hire want the same document, which is a good sign you are writing down the right things.

Then move the second pile somewhere it can be governed and retrieved rather than pasted. That is the whole argument, and it is a smaller argument than the headline suggested. Anthropic said your prompt file is obsolete. It is. The thing your prompt file was carrying is not.

For the underlying failure modes of the file itself, see The CLAUDE.md problem. For the difference between what belongs to a team and what belongs to one developer, see team AI memory vs personal memory. If you want the direct comparison, Contextium vs CLAUDE.md lays out what moves and what stays.