What changed about context engineering for Claude 5 generation models?

Anthropic reports removing over 80% of Claude Code's system prompt for Opus 5 and Fable 5 with no measurable loss on coding evaluations, and published six shifts that replaced it: grant judgment instead of writing rules, design expressive tool interfaces instead of supplying examples, disclose context progressively instead of front-loading it, state each instruction in exactly one place, let the model keep its own memory, and use rich references such as test suites and rubrics instead of prose specs. The through-line is that context is now an architecture problem rather than a volume problem — where an instruction lives and when it loads matter more than how carefully it is worded.

Should I turn on Claude Code's auto memory?

It depends on whether you already have a capture channel that records provenance. Auto memory writes plain markdown to ~/.claude/projects/ /memory/, and the first 200 lines of its MEMORY.md index load into every session in that repository. What it does not record is which model version a note was validated against, or what evidence exists that it helped — the two fields you need later to decide whether a note is still true. I keep it off and route capture through a single channel that stamps both, but that is a choice about which reverse gear you want, not a claim that the feature is bad.

Anthropic Cut 80% of a System Prompt — and the Rules That Replaced It

Anthropic published the new rules of context engineering for its Claude 5 generation models. The headline number is the kind that gets screenshotted: over 80% of Claude Code’s own system prompt, removed, with no measurable loss on coding evaluations.

The obvious reading is prompts got too long, cut them. That reading is available, it is not wrong, and it is the least useful thing in the piece.

Because look at what the 80% was replaced with. Not nothing. Skills that load when invoked. Tool definitions that carry their own usage rules. Deferred tool schemas the model has to go and fetch. Memory the model writes for itself. Specs that are test suites instead of paragraphs.

That is not a diet. That is the same information, moved.

Context stopped being a volume problem and became an architecture problem. The question is no longer how much you put in front of the model. It is where each instruction lives and when it loads.

Six shifts, one argument. Here’s the argument — and then the one shift where I looked at it, agreed with the reasoning, and deliberately went the other way.

The failure has a name now: overconstraining

The example Anthropic gives is almost funny in how ordinary it is. A system prompt that says leave documentation as appropriate — and also says DO NOT add comments. Both sentences were written by someone reasonable. Neither is wrong on its own. Together they force the model to stop and adjudicate before it can act.

Their own before-and-after is the whole shift in two lines. Before: “In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks — one short line max.” After: “Write code that reads like the surrounding code: match its comment density, naming, and idiom.”

The first prohibits. The second grants judgment and names the standard by which to exercise it. And notice which one is actually more specific about the outcome you want.

This is the same mechanism I wrote about when Opus 5 landed: an instruction earned against a weaker model becomes a tax on a stronger one. What’s new here is the diagnosis. It isn’t that the rules are too numerous. It’s that rules written as prohibitions collide, and the model pays to resolve the collision on every request.

Three shifts that are all the same move: put the instruction where it’s used

Group them, because separately they read as tips and together they read as a design principle.

Design interfaces, don’t provide examples. The old advice was to show the model how to use a tool. Anthropic’s position now is that examples constrain exploration — the model follows the demonstrated pattern instead of finding a better one. The replacement is to make the tool itself expressive. Their example: a Todo tool whose status field is an enum of pending, in_progress, completed, plus one line saying to keep a single item in_progress. No example needed. The schema taught the behaviour.

State it once, in the tool description. Instructions used to be duplicated — once in the system prompt, once in the tool description, sometimes again near the end of the context on the theory that recency helps. On these models it doesn’t. Tool-usage rules go in the tool description and nowhere else.

Disclose progressively. Specialised guidance moves out of the system prompt into Skills the model invokes when relevant. Some tools now use deferred loading: the model searches for the full schema before it can call the thing, so the definition costs nothing until the moment it’s needed. Structure CLAUDE.md and SKILL.md as trees loaded at moments, Anthropic says, not as repositories.

Three shifts, one move: an instruction should live at the point of use and load at the moment of use. Everything else is a tax paid on every request that didn’t need it.

I’ve made this argument before in a narrower form — that your CLAUDE.md is a monolith, not an architecture, and that context is the deliberately-tiered subset the agent needs now. This is the same claim with the vendor’s own product as the worked example, which is a considerably better piece of evidence than mine.

The homework I’d already done — three weeks early

I want to be careful here, because “I already did that” is the least interesting sentence in tech writing. The reason it’s worth a paragraph is that the convergence is checkable, and it went the same direction on some things and the opposite direction on one.

On 7 July 2026 — nineteen days before Anthropic published — I ran a pass over my own global agent configuration with exactly this frame. Three of the five changes map onto shifts in the post:

My operational-safety rules went from 8,857 words to 4,481. Every rule heading, checklist, and command table survived; what came out were the incident narratives behind each rule, which now live as one-line citations into a knowledge repo. The rule stayed loaded. The story behind it became fetchable.
A domain-specific rules file got path-scoped so it stops loading in sessions that don’t touch that domain. That is progressive disclosure by a different name, and it was worth doing purely on token cost before anyone told me it improved adherence too.
And I turned auto memory off.

Two out of three are the post’s advice arrived at independently. The third is a direct contradiction, and it’s the one worth the rest of the article.

The shift I went the other way on

The fifth shift is that manual memory becomes automatic memory. You used to save context to CLAUDE.md yourself with the # hotkey. Now Claude decides what’s worth remembering and writes it down without being asked.

The mechanics are more concrete than the announcement suggests, and they’re documented. Each repository gets a directory at ~/.claude/projects/<project>/memory/, shared across worktrees, local to the machine. Inside it, a MEMORY.md index plus topic files. The first 200 lines of that index — or the first 25KB, whichever comes first — load into every session in that repo. Topic files load on demand. It’s plain markdown; you can read, edit, or delete any of it, and /memory opens the folder.

None of that is objectionable. It is, in fact, a well-built version of the thing. My objection is narrower and it is about a single missing field.

Here is what an auto-memory file on my machine actually carries in its frontmatter: a name, a description, a node type, and the session ID it came from. Recent versions of the CLI add a modified timestamp when the file is rewritten. That is real provenance — more than I expected before I went and looked.

Here is what it does not carry, ever: which model version the note was validated against, and what evidence exists that it helped.

Those two fields are not bookkeeping. They are the only thing that lets you later decide whether a note is still true. A note that says this build needs the flag was written against some model, on some date, because something went wrong. When the model improves and the note becomes wrong, nothing about the note changes. It stays clean, correctly formatted, and quietly false — and it is loading into every session in that repository.

Then I counted. Across my machine there are 93 auto-memory files, written between February and June of this year, across seventeen project directories. One of them carries a date. The rest are undated because they were written before the CLI version that adds the timestamp, which is nobody’s fault and is exactly the problem: the provenance you didn’t record at write time is not recoverable afterward.

I looked at two of them for this blog’s own repository. Both are good. One records that this repo’s CLAUDE.md used to misstate its own deploy triggers and that the workflow file is authoritative. The other records a Hugo relURL gotcha that puts 404s in the nav, with the fixing commit named. Genuinely useful, correctly written, and I’d have been happy to have either one.

And both are undated notes about a codebase that has changed since, loading into every session, with no field that would tell a future reader whether they still hold.

So my reason for keeping it off is not that the notes are bad. It’s that I already run a capture channel that stamps the weakness, the date, the model version, and the strength of the evidence — the thing I’ve written about as a correction ledger — and running two capture channels where only one records why an entry exists means the unstamped one silently becomes the larger of the two. Single channel, stamped, reversible. That was the call.

I’d make the same call again, and I’ll say plainly what would change it: a validated-against field. If the model version rides along with the note, auto memory becomes strictly better than what I’m doing by hand, and I’ll turn it on that week.

One more thing the count taught me, which is the actually actionable part for anyone reading: turning the feature off does not unload what it already wrote. Ninety-one of those files predate my toggle. They are still on disk, and in every repository that has a MEMORY.md, its first 200 lines are still entering every session. Nothing about that fails, nothing warns you, and it is invisible on any dashboard — which is the signature of the most expensive kind of leftover.

(Two of the 93 were written a month after I disabled it. I don’t yet know why. That’s this week’s other problem.)

The correction I owe from last time

When I wrote about the Opus 5 launch, I framed the prompting guide as a deletion list — remove the verification steps, remove double-check your answer, stop telling review prompts to be conservative, cap subagent delegation, re-run your effort sweep. Every one of those is in the document and every one of them is right.

But that was a one-directional reading of a two-directional document, and the same guide I quoted also adds six instructions: for response verbosity, agentic narration cadence, written-deliverable length, task-scope constraint, subagent delegation caps, and how much to narrate its own corrections. Each is a compensation for a behaviour the upgrade introduced or amplified.

So the honest shape of a model upgrade is not delete your scaffolding. It is: the same release expires some of your scaffolding and creates the need for more, on the same day, in the same document. Run only the subtraction pass and you ship a leaner system that is newly miscalibrated in six places.

The addition list is easy to miss for a structural reason worth naming. Teams notice new problems on their own — someone complains the output got long, someone fixes it. Nobody notices the absence of an old problem. That asymmetry is why the removal half needs a written trigger and the addition half mostly doesn’t.

The audit, which is a morning

Three questions, in order of how much they’ll cost you to have got wrong.

1. Where does each instruction live, and when does it load? Take any five instructions in your setup. For each: is it loaded on every request, and does every request need it? Anything specialised and always-loaded is a candidate for a skill or a path-scoped rule. Anything that governs one tool belongs in that tool’s description and nowhere else. /doctor will propose trims for a checked-in CLAUDE.md if you want a starting point rather than a blank page.

2. Do any two of your instructions disagree? Grep your prompts and rules for pairs that pull opposite ways — a “be thorough” next to a “be concise”, a “document as appropriate” next to a “never add comments”. You are paying for that adjudication on every single request, and the model resolves it silently and inconsistently.

3. What does your setup remember, and does it know when it was true? If you have auto memory on, run /memory, open the folder, and read what’s in there. Ask of each note: which model version was this validated against? If the answer isn’t in the file, the note can only ever be kept — because re-deriving whether it’s still true costs more than leaving it alone, so nothing is ever removed and the pile only grows.

That third one is the whole argument in miniature, and it applies to every mechanism in this post: guidance that doesn’t record why it exists can be added but never removed. Which is fine for a week and expensive for a year.

If you build with AI, that audit lives in your tooling — the software-engineer track. If you run a business on AI, it’s the same three questions pointed at your assistant setups and the preamble you paste at the top of every long task — the solopreneur track.

The models got better at judgment. What that bought you is not permission to write less. It’s permission to stop writing rules and start designing where things live — and, as the agent audit keeps demonstrating, the part nobody schedules is going back to check whether what’s already there is still true.