Delete System-Prompt Rules One Regression at a Time

Anthropic says it removed more than 80% of Claude Code's system prompt for Claude Opus 5 and Fable 5 without a measurable loss on its coding evaluations. OpenAI reports the same direction for GPT-5.6: leaner configurations scored roughly 10–15% higher in a sample of internal coding-agent evals while using 41–66% fewer total tokens.

Neither result supports indiscriminate prompt surgery. Both vendors tell builders to validate changes on representative work. The useful technique is an instruction deletion test: remove one coherent rule group, rerun the failures that justified it, and keep the rule only when the model still needs it.

System prompts accumulate compatibility code

A persistent prompt often starts small. Then the agent adds a useless comment, chooses the wrong tool, asks for approval too often, or edits outside the requested scope. Each incident leaves another sentence behind.

Some sentences encode product requirements. Others compensate for a particular model's habits. After a model upgrade, those workarounds do not automatically become harmless. They still consume tokens and can conflict with tool descriptions, repository instructions, skills, and the user's request.

Anthropic's Claude 5 context-engineering write-up gives a concrete example: general guidance to document code when appropriate can collide with a blanket ban on comments elsewhere in the context. The newer models no longer needed many rules that once prevented bad behavior.

Conflicts are a measured failure class, not a stylistic complaint. IHEval contains 3,538 cases across nine tasks where instructions at different privilege levels align or disagree. Every model evaluated in that 2025 study lost substantial accuracy on conflicting cases, and the best open model reached 48% accuracy. Those numbers do not describe current Claude or GPT models, but they are a good reason to test instruction collisions instead of assuming the hierarchy will sort itself out.

Classify a rule before deleting it

Prompt length alone is a bad deletion criterion. First decide what job each rule performs.

Executable boundaries cannot depend on prompt compliance. A sentence such as "never run a production migration without approval" can help the model plan, but text is not the enforcement point. The database credential, tool gate, or approval service must reject the action.

This classification prevents two bad outcomes: keeping folklore forever because it sounds prudent, and deleting a product requirement because a small eval set happened not to exercise it.

Give every workaround a regression case

Create an instruction ledger beside the prompt. For each rule group, record its owner, context layer, the failure that introduced it, the test that detects that failure, and the model snapshot on which the rule was last necessary.

An entry for "do not narrate deleted code in comments" might point to a repository task where the agent once left diff-history comments behind. A rule about JSON output should point to schema validation. An approval rule should point to a trace assertion that no gated tool executed before consent, plus the runtime control that makes the assertion true.

A rule with no requirement and no reproducible failure is a deletion candidate. Do not delete it on that fact alone; write the missing case if the behavior still matters.

Anthropic's agent-evaluation guide recommends starting with 20–50 tasks drawn from real failures rather than waiting for a giant benchmark. It also separates capability evals, which find new strengths, from regression evals that should pass nearly every time. Instruction pruning belongs in the second set.

Remove one rule group and rerun the same work

Hold the model snapshot, reasoning configuration, tools, grader, and task set constant. Run the current prompt as the baseline. Then remove one related group of instructions and repeat enough trials to see through sampling noise.

Compare task success and the specific behavior that the rule was meant to control. Also record tool-selection errors, forbidden-action attempts, human interventions, input tokens, latency, and cost. A token reduction is not a win if review effort moves in the other direction.

OpenAI's GPT-5.6 migration guidance recommends this exact shape: remove one group of instructions, examples, or tools at a time, then rerun the same evaluations. It also says to keep examples and style guidance when they encode a product requirement or correct a measured gap.

The result has three possible actions. Keep the rule when removal causes a repeatable regression. Delete it when behavior stays within the agreed budget. Move it when the instruction is really reference material or an executable policy wearing prompt syntax.

One-at-a-time tests can miss redundancy. Two rules may each appear removable because the other still covers the same case. After the individual pass, test the complete candidate prompt against the original and add explicit conflict cases across system, tool, repository, and user instructions.

Let measured behavior decide what remains

Anthropic's 80% cut is evidence about its prompt, models, and coding evaluations. OpenAI labels its own figures directional. Copying either percentage turns somebody else's ablation result into your production policy.

On the next model upgrade, open the instruction ledger and remove one old workaround. Run its regression, inspect the conflicts, and check the control outside the prompt. The prompt gets shorter only when the model and the surrounding system no longer need the rule.