Context Engineering by SubtractionAugust 2026

The deletion

Reading Thariq Shihipar, The new rules of context engineering for Claude 5 generation models (Anthropic, July 24, 2026), the opening through "Unhobbling Claude"; Anthropic, Effective context engineering for AI agents (September 2025), the definition; Qishuo Hua et al., Context Engineering 2.0: The Context of Context Engineering (2025), for the twenty-year lineage in §1.4.

1.1What was published

The announcement is short and its central claim is a single sentence: Anthropic removed over 80% of Claude Code's system prompt for models including Claude Opus 5 and Claude Fable 5, with no measurable loss on its coding evaluations. The piece then names six reversals in prompting practice that made the deletion possible, describes how to assemble context across four layers, and points at a command that automates a first pass of the same audit.

It is worth pausing on how unusual the shape of that is. Vendors publish guidance on how to use their products well. They rarely publish a detailed account of deciding that most of their own prior guidance had expired.

1.2What the claim is, and is not

Read the sentence precisely, because the precision is the whole of its evidentiary weight.

The evaluations are Anthropic's own, internal, and coding-focused. "No measurable loss" is a statement about what those evaluations detect, not a statement about everything a system prompt does. A system prompt encodes safety behaviours, tone, refusal boundaries, and product framing, and a coding benchmark is not built to notice when those move. The figure itself — over 80% — is a proportion of text removed, which tells you nothing about which text, or how load-bearing it was.

None of this makes the claim weak. A team with production telemetry, internal evals, and access to the actual prompt is the best-positioned party in the world to make it, and they published the reasoning rather than only the number. But it is a vendor self-report against private instruments, and the honest handling is to name it as one every time it is repeated. In the weeks after publication, the number was widely restated and often rounded down to "80%," sometimes with the internal-eval qualifier dropped entirely. That drift is the ordinary fate of a striking figure, and it is worth resisting.

1.3The stated diagnosis: over-constraining

The reason given for the deletion is specific, and it is not the reason most summaries reached for. Anthropic reports reading transcripts of its own internal usage and finding several conflicting messages arriving inside a single request — the system prompt insisting on one thing while a skill advised another and the user asked for a third. Their example pairs an instruction to leave documentation as appropriate against an instruction not to add comments.

The model resolves that. The point is that resolving it consumes something. Anthropic's framing is that Claude can generally interpret the user's intent correctly, but must think more carefully about overlapping and conflicting messages before deciding what to do. An unnecessary instruction is not inert. It is a contradiction waiting to be adjudicated before the work starts.

The second half of the diagnosis is about capability rather than conflict. Many constraints existed to prevent worst-case behaviour from models that needed them, and Anthropic reports that newer models have better judgement and handle those decisions without explicit rules. Their canonical example is comments: the old prompt banned multi-line comment blocks and multi-paragraph docstrings outright, which was wrong whenever a user wanted documentation or complex code genuinely needed it. The replacement asks Claude to write code that reads like the surrounding code, matching its comment density, naming, and idiom.

That substitution — a rule that is right most of the time, replaced by a criterion that is right whenever the model can apply it — is the shape of every one of the six reversals in Chapter 3.

1.4The lineage this belongs to

The term is recent; the practice is not. Anthropic frames context engineering as the natural progression of prompt engineering, defining it as the strategies for curating and maintaining the optimal set of tokens during inference — everything that lands in the context, not only the prompt you wrote. A 2025 survey argues the underlying discipline traces back more than twenty years, through human–computer interaction work from the early 1990s and the ubiquitous-computing tradition, with each phase shaped by how much the machine could infer on its own.

That framing is useful here for one specific reason. If the discipline is about closing the gap between what a person means and what a machine can reconstruct, then the size of the correct instruction set is a function of the machine, not a fixed best practice. Instructions are calibrated to a generation. When the generation changes, the calibration is stale — not wrong in retrospect, stale.

Two costs, often confused

Reading Anthropic, Effective context engineering for AI agents, on context as a finite resource; Nelson F. Liu et al., Lost in the Middle, TACL 12 (2024); Kelly Hong, Anton Troynikov & Jeff Huber, Context Rot (Chroma, 2025); Anthropic, Prompting Claude Opus 5, the long-context claim.

2.1Why the distinction matters

Almost every write-up of the deletion reaches for the same explanation: models degrade as context grows, therefore less context is better. That explanation is popular, partly true, and not what the source says. Getting this right changes what you should actually cut.

There are two separate costs, with different mechanisms, different evidence, and different remedies.

2.2Conflict cost

The first is the one Anthropic documents. When instructions disagree — across the system prompt, a skill, a project file, and the request itself — the model must reconcile them before it can act. This is a cost of contradiction, not of length. A hundred lines that agree with each other are cheaper than ten that do not.

The remedy is deletion and consolidation, and it works regardless of how good the model's long-context handling is. A capable model resolves contradictions more gracefully; it still has to resolve them. This is the cost that the audit in Chapter 5 attacks directly, and it is why the single most effective move in that chapter is not counting lines but reading every layer at once so the contradictions become visible.

2.3Dilution cost

The second is what the popular explanation is actually gesturing at, and its evidence comes from outside the vendors. The foundational result is Liu and colleagues' finding that models use long contexts unevenly: performance is highest when the relevant information sits at the beginning or the end of the input, and degrades when it is buried in the middle. Chroma's follow-up work, published under the name context rot, reports that increasing input length affects performance in ways that are not uniform across tasks — that a larger window is not the same thing as more usable attention.

Here is where the honest complication sits. Anthropic's own documentation for Opus 5 states that the model's instruction following, tool calling, and reasoning stay consistent throughout its one-million-token window. That is a direct claim that dilution cost has been substantially engineered away, and it is a vendor claim, made about the vendor's own model, with no published independent replication. The research on the other side is independent but describes earlier model generations.

We are not in a position to adjudicate that, and this guide will not pretend otherwise. What we can say is narrower and still useful: the case for deletion does not depend on which side is right. Conflict cost is documented by the vendor itself and is unaffected by long-context improvements. If dilution cost has genuinely been reduced, subtraction is still worth doing — you simply lose one of the two reasons for doing it.

2.4What this means for what you cut

If conflict cost is the mechanism you are attacking, the priority order changes. The most valuable deletion is not the longest file. It is the instruction that is stated in three places in three registers, because that is three voices to reconcile rather than one instruction reinforced. Duplication across layers is the highest-yield target, and it is mechanically findable, which Chapter 5 exploits.

The six reversals

Reading Shihipar, The new rules of context engineering, the "Then and now" section in full; Anthropic, Prompting Claude Opus 5, on over-verification, subagent spawning, and self-correction; the Loop Engineering guide, for the golden rule that §3.2 draws a line against.

3.1The table, and the mechanism behind it

Six practices are named as having become myths. The list is easy to memorise and easy to misapply, so what follows is each one with the reason attached.

3.2The two that surprise people

Two of these reverse advice that is close to universal in prompting guidance, and both deserve their own treatment.

The first is examples. Giving examples of correct tool use was, in Anthropic's telling, the number one rule; the finding now is that examples constrain the model to a certain exploration space. The replacement is to invest in interface design instead — what parameters exist, how expressive they are, what the shape of the input implies about correct use. Their illustration is a task-tracking tool whose status field is an enumeration of pending, in progress, and completed: the type communicates how the tool works without a single worked example, and one instruction about keeping a single item in progress defines the behaviour they want.

The second is verification, and it is the one most likely to be sitting in your own files right now. Anthropic's model-specific documentation is unusually direct: if your prompt contains explicit verification instructions, remove them, because the model verifies its own work without being told, and instructions like these cause over-verification while removing them reduces wasted tokens with no loss in quality. The same guidance extends to legacy harness scaffolding that adds separate verification steps, to instructions to re-check or double-check before responding, and — in the other direction — to subagent delegation, where the documented behaviour is that the model already delegates readily and benefits from explicit caps rather than encouragement.

This one is worth sitting with, because it cuts against a principle this library has argued for elsewhere. The golden rule of loop engineering is that something in the loop has to be able to say no, and that the generator must not grade its own work. That principle is not overturned here. What is being deleted is the instruction to be careful, not the independent check. A test suite, a type checker, a separate verifying agent with its own context, a rubric applied by something other than the writer — all of those remain exactly as load-bearing as they were. Telling a model that already self-verifies to verify itself is not a check. It is a second voice agreeing with the first, and paying for the privilege.

3.3Progressive disclosure is the one with mechanics

Of the six, progressive disclosure is the only one that changes the architecture rather than the prose. The claim being retired is a specific myth: that a project file must be a central repository of every practice you might ever need, because the model would not otherwise find it. The replacement is a tree of files loaded at the right time.

Anthropic applied this to itself twice over. Verification and code review moved out of the system prompt and into skills that could be called selectively. The same pattern extends to tools, some of which are deferred-loading — the agent searches for a full definition before using it, so a large tool surface costs nothing in context until something needs it.

The accounting matters more than the technique. Deleting a line is only safe if the information was genuinely unnecessary. Much of what gets cut in one of these audits is instruction, which disappears cleanly. But some of it is real content that matters occasionally, and that content should not be deleted at all. It should move behind a pointer. The distinction between deleting and moving is the difference between an audit and a loss.

Where each thing belongs

Reading Shihipar, The new rules of context engineering, "Applying this to your context"; Anthropic, Claude Code skills documentation.

4.1Four layers

The guidance resolves into four places where standing context lives, each with a different job. Most bloat comes from content sitting in the wrong one.

The system prompt is tied to the product: what the assistant is operating inside and what it is for. If you use a finished product you will likely never touch it. If you are building your own agent harness, this is where the design effort belongs, and it is the layer Anthropic spent its own effort cutting.

The project file — CLAUDE.md or its equivalent — should be light on description and heavy on gotchas. Anthropic's guidance is to briefly describe what the repository is for and spend most of the tokens on the surprising things inside it: the monolithic types file, the generated directory nobody should edit, the build step that fails in a non-obvious way. The instruction that does the most work here is negative: avoid stating the obvious things the model could learn by looking at the file system.

Skills are lightweight guides that let the model find information when it needs it. The guidance is to avoid making them overconstrained except in genuinely high-stakes areas, and to split long ones across multiple files so progressive disclosure can operate inside a single skill. The best ones encode opinions, knowledge, or practices particular to you, your team, or your product — precisely the things a general model cannot infer.

References are files brought in for a specific piece of work: specs, mockups, entire codebases. The guidance is to prefer artifacts in code, because they are high-fidelity instructions in a language the model knows well. An HTML mockup of a design produces better results than a description of it, and better than a screenshot. A failing test that reproduces a bug is a better specification than a paragraph about the bug. A rubric is a reference too — a way of encoding taste that a verifying agent can apply.

4.2The test that sorts a line

Four layers tell you where things go. They do not tell you whether a given line should exist. For that, one question does most of the work:

Would a capable model behave worse without this line?

It separates two things that look identical in a file. Instruction that duplicates competence fails the test — write clean code, think carefully, check for errors — because a capable model already does it and the line only adds a voice to reconcile. Information the model cannot derive passes — the generated files that must never be edited, the deploy window, the incident that produced a constraint — because no amount of capability recovers a fact that is not in the repository.

Applying it honestly, most lines fail. That is the finding practitioners running this audit keep reporting, and it is the reason the exercise is uncomfortable.

Running the audit

Reading Anthropic, Claude Code skills documentation, on bundled skills; Shihipar, The new rules of context engineering, the closing section; Abdo Mobayad, The New Rules of Context Engineering for the Claude 5 Family (Claude Fast, July 2026) — a commercial framework vendor's account of the same surgery; the Who the Agent Rewards guide, on why self-reported productivity is the weakest evidence available.

5.1The command

Anthropic shipped an automated first pass alongside the announcement. In Claude Code it is invoked as /doctor, and the documentation lists it as one of a set of bundled skills — prompt-based rather than hard-coded, giving Claude detailed instructions and letting it orchestrate the work with its own tools. It audits your accumulated configuration and proposes changes.

Two cautions, both from the shape of the thing rather than from any dispute about it. First, a prompt-based audit is a model reading your files and forming a view, not a static analyser producing a proof; it will be good at finding duplication and staleness and worse at knowing which of your lines encode an opinion it has no way to infer. Second, published practitioner accounts already include at least one case of the command recommending no changes to a skill set that the operator's own evaluations showed did need changing. Treat it as a strong first pass that reduces the manual work, not as a verdict.

Run it before you start cutting by hand, because starting from its output beats starting from a blank diff.

5.2The pass it cannot do for you

Here is the move that surfaces what an automated audit structurally cannot: concatenate every layer into one document and read it the way the model receives it.

Your project file, your rules directory, every skill, every agent definition, every tool description you control — in one buffer, in one sitting. Working file-by-file is what allows contradictions to persist, because each file is locally coherent. The conflict only becomes visible when the instruction not to add comments sits four hundred lines from the instruction to document thoroughly, in the same document, the way they actually arrive together in a single request.

This takes twenty minutes and it is the highest-yield step in the chapter. It is also the step most likely to be skipped, because it produces no artifact and feels like reading rather than working.

5.3The sequence

1. Run the automated audit first        → a free first pass; start from its output
2. Concatenate every layer, read it once → contradictions are invisible file-by-file
3. Apply the test line by line           → would a capable model behave worse without this?
4. Sort survivors: KEEP or MOVE          → always-needed stays; occasional goes behind a pointer
5. Hunt duplication across layers        → same rule in three places is three voices, not emphasis
6. Strip verification and delegation nudges → keep deterministic gates, cut "be careful"
7. Replace thresholds with criteria      → and spend saved lines calibrating them
8. Re-run your own evals                 → the only step that tells you whether it worked

Step eight is the one that separates this from a tidying exercise, and it is the one the published accounts are weakest on. Anthropic re-ran internal coding evaluations. Most practitioners reporting dramatic cuts are reporting how the result felt, sometimes across a handful of sessions, which is the class of evidence this library has argued elsewhere is close to worthless for judging productivity. If you have no evaluation harness, the honest description of what you are doing is a well-motivated experiment, not a measured improvement.

5.4What the surgery looks like at scale

One published account is worth reading because it reports a diff rather than an impression. A commercial framework vendor ran the same audit across a production Claude Code setup in the week the announcement landed and published the before-and-after: eighteen agent definitions reduced from 8,798 lines to 664, a project file from 260 lines to 165, a rules primer from 256 to 147. They report the agent fleet became measurably better at following plans, and they name four categories that survived — operator opinions, surprising project facts, routing rules with real thresholds, and named integrations — against four that did not: persona framing, restated general knowledge, emphasis scaffolding in capitals, and redundant verification demands.

Two qualifications belong with those numbers. The account comes from a company selling a Claude Code framework, and the post closes by offering the already-cut version as a product; that is a commercial interest in the conclusion being true. And the figures are described as verifiable in the project's version history without a link to it, so they are a self-report rather than something a reader can check. The categories are more useful than the numbers, and the categories are the part that generalises.

What subtraction costs

Reading Dan Shipper & Katie Parrott, Vibe Check: Claude Opus 5 Is Brilliant in Flashes, Frustrating in Practice (Every, July 2026); Anthropic, Prompting Claude Opus 5, on scope and effort; the Who the Agent Rewards guide on the verification burden.

6.1Backward compatibility is the real cost

The clearest independent account of the transition comes from Every, a publication running much of its editorial and engineering work on Claude-based agents. Testing Opus 5 across a week, they reported that it argued with instructions, stopped before work was finished, and did not work well with their existing skills and plugins — including compound engineering, their own open-source workflow system. Their fix was not better prompting. They deleted their existing skills and started from scratch, and reported dramatically better results.

That is the cost stated plainly. The teams who invested most in elaborate scaffolding for previous models are the ones for whom the new generation breaks hardest, and the remedy is throwing away work that was correct when it was written. The maintainer of that plugin subsequently rebuilt it. Two directions of the same finding: heavy harnesses fight capable models, and the fight is expensive to end.

Anthropic's own documentation is more sanguine — it says the model performs well out of the box on prompts written for its predecessor — and both things can be true. A thin setup migrates painlessly. A deep one does not.

6.2Leaner context is not fewer guardrails

The most dangerous misreading of this material is that constraint itself has been deprecated. It has not, and conflating two kinds of constraint will cost you money.

What is being removed is steering — instructions about style, thoroughness, and care, aimed at behaviour the model now handles by judgement. What is not being removed is bounding: iteration caps, spend ceilings, permission scopes, stop conditions, deterministic gates like tests and type checks. Those are not context engineering at all. They are the control surface, they live outside the prompt, and a model with better judgement does not reduce the need for a budget it cannot exceed.

The relevant asymmetry is that better judgement makes a model better at doing what you asked, including doing more of it. Anthropic's documentation notes that Opus 5 can expand the scope of a task and that delegation to subagents multiplies cost when applied to small work. A leaner context with no ceiling is not restraint. It is a faster path to the same invoice.

6.3The lines that look boring and are not

The audit's characteristic failure is destroying project facts. They read like boilerplate — a note that a directory is generated, a warning that a build step is order-dependent, a constraint traced to an incident nobody remembers. They fail a casual reading of the test because they do not look like they are doing anything. They pass the honest version, because no capability recovers a fact that is not written down anywhere the model can see.

The published accounts include exactly this failure: a build gotcha cut on the theory that it read like filler, restored after a session rediscovered it the expensive way. If you are unsure about a line, its category tells you more than its prose. Instruction can be re-derived from a capable model. Institutional memory cannot.

6.4What this evidence does not settle

Three open questions, stated as questions.

The attribution question. Is the deletion possible because models improved, or because system prompts were overbuilt all along and nobody had audited one? Anthropic's own diagnosis supports both readings at once: over-constraining is a description of the prompt, better judgement is a description of the model. Nothing published separates them, and the practical consequence is that we do not know how much of this transfers to other vendors' models or to the next generation.

The generalisation question. Every measurement here comes from inside one ecosystem — one vendor's models, one vendor's harness, and practitioners working within it. There is no published account of the same subtraction on a different vendor's stack producing the same result. That is not evidence against; it is an absence, and it should make you test rather than assume.

The measurement question. The vendor re-ran internal evaluations. Almost nobody else has. The practitioner corpus is overwhelmingly composed of self-reported impressions gathered over days, and this library has argued at length that self-reported productivity is the weakest evidence available — strong enough, in one randomised trial, to invert the sign of the actual effect. The direction of this finding is well-supported by the vendor's own instruments. The magnitude, outside them, is not yet established.

6.5The durable part

Strip away the version numbers and one thing remains true regardless of which model you use. Standing instructions accumulate and nothing forces a review. Every line you write is calibrated to the system that existed when you wrote it, and it will still be read, unchanged, by systems that no longer need it.

The practice worth keeping is not this particular deletion. It is the habit of periodically reading everything you have accumulated, at once, and asking what it is still for. That habit outlives any generation of models, and it is the only part of this guide that will not expire.