Your System Prompt Has a Shelf Life: Maintaining Prompts as Models Improve

Anthropic removed over 80% of Claude Code's system prompt for Claude Opus 5 and Claude Fable 5, and measured no loss on their coding evaluations. Those instructions were not wrong when they were written. They were load-bearing. Somewhere between the model they were written for and the model running today, they stopped carrying weight and started adding noise. That is the part worth generalizing. A system prompt is not a thing you write. It is a thing you maintain, and every line in it has a shelf life set by the model underneath it. Most of us have never run the maintenance pass. The prompt from last November is still in production, still growing, because adding a line when something breaks is easy and nobody ever schedules the deletion. What this article covers - The five reversals - what Anthropic's new rules of context engineering actually reverse, and which of the older advice they revise. - The scope nobody states. This is frontier-model guidance. On a Haiku-class model much of it inverts, and the source never says so. - The maintenance pass. A checklist you can run against your own prompt, with the prerequisite that makes it safe. - A worked audit on Cameron, a real finance agent with a real 100-line prompt. If you have not read The Art of Agent Prompting, start there. It covers the principles that still hold: heuristics over rigid rules, thinking like your agent, designing for the loop. This article is about what happens to those prompts eighteen months later. The clearest example: rules become judgment Anthropic's own before and after says it better than a summary can. The old instruction: In code: default to writing no comments. Never write multi-paragraph docstrings or multi-line comment blocks, one short line max. The new one: Write code that reads like the surrounding code: match its comment density, naming, and idiom. The first is a rule. It exists because a weaker model, left alone, wrote too many comments. The fix was a hard cap, and the hard cap worked. The second is judgment. It assumes the model can look at a file, infer the local convention, and match it. That assumption was false in 2024 and is true enough now to ship. The rule was scaffolding around a capability gap, and the gap closed. That is the shape of every reversal below. Not "we were wrong," but "the model got good enough that the workaround costs more than it returns." The five reversals | Then | Now | |---|---| | Repeat critical instructions | State it once | | Few-shot examples of tool use | Design expressive tool parameters instead | | Front-load all the context | Progressive disclosure, load on demand | | Instructions in the system prompt and the tool | Tool descriptions only | | Hardcoded rules | Heuristics that defer to judgment | Repetition stops paying Repeating the critical constraint near the end of a long prompt was real advice, and it worked because attention over long contexts was genuinely lossy. It is now closer to a tax: the same instruction twice invites the model to wonder whether the second one means something the first did not. Examples give way to interface design The advice used to be: show the agent a worked example of calling the tool. The replacement is to make the tool's own signature carry the information. As Anthropic puts it, think about "what parameters does Claude have and how can they be more expressive?" An enum of pending | in_progress | completed teaches the usage pattern without a single example. The parameter is the instruction, and unlike an example it cannot drift out of sync with the code. Front-loading gives way to progressive disclosure Everything the agent might need, loaded up front, was the safe default when models were bad at going to find things. Now the better structure is a small prompt that knows where to look. Anthropic ships tools whose full definitions the agent must search for before use. The same logic applies to your CLAUDE.md and your skills: a tree of files loaded at the right moment beats one document loaded always. One home per instruction This is the one with the clearest test. If a rule about how to use a tool lives in both the system prompt and the tool description, delete the system prompt copy. The tool description travels with the tool, appears only when the tool is in play, and cannot fall out of sync with the schema. The system prompt copy is a second source of truth that ages independently. Rules give way to heuristics The direction the playbook already pointed. It argued that showing agents exact processes "may limit their ability to leverage their full capabilities," and that heuristics beat rigid templates. The frontier finished that arc rather than reversing it. What changed is the dosage: how much scaffolding a capable model needs before heuristics are enough on their own. variant="inline" source="inline-system-prompt-shelf-life" slug="system-prompt-shelf-life" /> Not every agent runs a frontier model Here is what the source leaves implicit, and it matters more than any single reversal. That 80% deletion was measured on Claude Opus 5 and Claude Fable 5. Haiku and Sonnet are not mentioned. Absent, not exempted. Plenty of production agents run smaller models on purpose. Classification, routing, extraction, anything high-volume where latency and cost dominate and the task is narrow enough not to need a frontier model. On those, the instruction you are about to delete as an over-constraint may be the only thing keeping the task on rails. Terseness that reads as trust on Opus 5 reads as ambiguity to a model with less headroom to resolve it. So the pass is not "delete instructions." It is: Re-fit instruction density to the model you are actually running. Which has a consequence people miss: a model downgrade triggers the audit exactly as much as an upgrade. Route a step from Opus to Haiku to cut costs and you have changed the amount of judgment you can assume. The prompt that got leaner for the frontier model may need some of that scaffolding back. To be clear about sourcing: this is our reading, not Anthropic's published position. Their prompting best practices note that newer models may need behaviors requested more explicitly, but that is a point about generations, not tiers. We have found no Anthropic guidance stating that Haiku needs denser instruction than Opus. The mechanism above is the argument; treat it as reasoning to test against your own evals rather than a vendor claim. The maintenance pass Step 0: you need evals before you delete anything The 80% figure is only meaningful because of the four words attached to it: no measurable loss on our coding evaluations. Strip those and the claim is "we deleted most of our prompt and it seemed fine," which is worth nothing. Deleting on intuition is how prompts get bloated in the first place. Something breaks, you add a line, you never check whether it helped, and eighteen months later the prompt is 100 lines and nobody knows which ten are doing the work. You do not need a large suite. The 3-Test Rule applies here as much as anywhere: the larger the effect size, the smaller the sample you need. Five realistic tasks, run consistently, will tell you whether a deletion moved anything. There is a second reason to write them first, beyond measuring the deletions. Evals are also how you find out that the thing you were about to fix was not broken. Writing evals that prove you wrong is a field report on exactly that: a red run that killed a prompt slice written for a bug that did not exist, and a case that passed for entirely the wrong reason. Both are the same failure mode as deleting from a prompt on instinct, reached from the other direction. Its rule is the one to carry into this audit. Green is not the same as correct, and a passing case is evidence only if you know why it passed. For the rest: the eval frameworks roundup covers the tooling landscape, and testing tools covers the deterministic layer underneath, which catches what is mechanically checkable before evals are worth running. Baseline first. Then delete. Then re-run. The checklist Each item finds candidates. The eval decides. - Instructions stated twice. Search for any rule that appears in both the system prompt and a tool description. Keep the tool description. - Rules that are now judgment calls. Any hard cap or absolute prohibition written to stop a behavior the current model may no longer exhibit. Remove it and see if the eval moves. - Examples that could be parameters. Worked examples of tool calls, where a better schema, an enum, or a sharper parameter description would carry the same information. - Detail that is situational. Long procedures only relevant to one workflow. These belong in a skill or a reference file, loaded when that workflow starts. - Over-constrained heuristics. The classic is the unbounded pursuit: "keep searching until you find the best source" with no permission to stop. Give the agent an exit. - Density mismatched to the model tier. As above, in both directions. A worked audit: Cameron's system prompt Cameron is a personal finance agent, built in public across this series. Its system prompt is a single exported string, currently 100 lines, and it was written the way most production prompts are written: by adding a paragraph every time something went wrong. It is a good subject precisely because it was written carefully. Every line in it was added for a reason that was valid at the time. [!NOTE] This section is an audit, not a diff. The deletions below are proposed and not applied: applying them would mean asserting an improvement I cannot yet measure, which is the exact error the section above warns about. Cameron's eval harness has since shipped, so the measurement is now possible. Finding 1: the same rule in two places Cameron's CSV import rule about copying column headers exactly appears in the system prompt: Use the exact header string from inspect_csv for every mapping value - copy it verbatim, including accents, spac