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.
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.
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."
| 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 |
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.
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.
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.
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.
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"
/>
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 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.
Each item finds candidates. The eval decides.
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 areproposed 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.
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, spaces, and capitalization (e.g. `Catégorie`, never
`Category`; `Revenu/dépense`, not a translation). A mapping value that isn't an
exact header is rejected and nothing imports.
And, already, in the inspect_csv
tool description itself:
IMPORTANT: when you build the mapping, copy each header string EXACTLY as returned
here — including accents, spaces, and capitalization (e.g. 'Catégorie', not
'Category'). Do NOT translate or normalize header names; a value that isn't an
exact header is rejected by the import.
Same rule, same example, two sources of truth. The tool description is the one that survives: it appears exactly when the agent is holding the CSV, and it lives next to the schema that enforces it.
The same duplication covers the truncation rule (in the prompt and in query_transactions
), the "use run_sql
for totals, do not page through rows" rule (both places), and the approval requirement on import_transactions_csv
(both places).
Candidate: roughly 25 lines of the "What you can do" section, which re-narrates tool behavior the tools already describe.
Eight lines instruct Cameron to use Markdown, bold important figures, use headers, use tables for structured data, and make responses scannable. Then a ninth line repeats the instruction to use Markdown.
Frontier models format like this by default in a chat surface. This is scaffolding for a capability gap that has closed.
Candidate: the entire Response Formatting block, replaced by one line of intent if anything: lead with the figures, keep it scannable.
- Only use tools when you genuinely need current, specific, or specialized information
- Do NOT use tools for information you already know with confidence
- Use tools efficiently — don't make unnecessary calls
- Follow the exact function signatures provided
None of this is Cameron-specific. It is a description of how tool-using models already behave. "Follow the exact function signatures" in particular instructs the model not to do something it structurally cannot do.
Candidate: all four lines.
This is the half of the audit that matters more, because the failure mode of this whole exercise is deleting something load-bearing.
The hard rules stay, verbatim. No moving money without explicit human approval. Every capability through the same gate. Data stays on infrastructure the owner controls. These are not model-capability workarounds, they are product invariants and Cameron's stated identity. No model improvement makes them redundant. Length is not the enemy; unnecessary length is.
The approval-mechanics paragraph stays. It explains that the gate is enforced by the system, so calling the tool is the proposal, and asking in prose first double-prompts the user. That is non-obvious information about the harness which the model cannot infer from the tools. It is the opposite of the deletions above: it encodes something true about the environment, not something the model already knows.
The domain conventions stay. Amounts in positive minor units, direction in the type
column, JOIN category
for names. Facts about the data, not instructions about behavior.
The pattern: delete what the model can infer, keep what only you know.
Roughly 45 of 100 lines are candidates for deletion, none of them among the invariants. That would be a 45% reduction, well short of Anthropic's 80%, which is what you would expect for a prompt where a real fraction of the content is genuine product policy rather than model scaffolding.
Whether those 45 lines can actually go is a question for the evals, not for me.
Put it on the model upgrade path. Every time you change the model underneath an agent, in either direction, the assumptions your prompt encodes have shifted.
The order matters:
The habit worth building is the one that runs counter to instinct: on a model upgrade, the first move is to look for what to remove.
One thing to watch for while you do it. If some behavior refuses to respond to prompt changes at all, you may be fighting the model's priors rather than its instructions, and no amount of editing fixes that. Running the same suite across two model versions makes the difference visible quickly; a single-model suite hides it, and you spend the afternoon rewording a prompt that was never the problem. The eval field report has a worked case: an older serving model volunteering two-year-old model names in its own voice, unprompted, which no prompt slice was going to correct.
The prompting principles this article builds on are packaged as agent-prompt-engineering
, an agent skill in agentailor/skills, with worked agent prompts and a reference list of anti-patterns:
npx skills add agentailor/skills --skill agent-prompt-engineering