On July 24, 2026, Anthropic published that it had removed over 80% of Claude Code's system prompt for its newest models "with no measurable loss on our coding evaluations" — Anthropic's own figure, measured on Anthropic's own evals. Three days earlier, an independent practitioner had already published raw captures, diffs and a different conclusion: the defensible number is closer to 70%, because a large block of the "deleted" text was made conditional rather than removed.
Both numbers are about a file nobody outside Anthropic maintains. On August 29, 2026 we asked the same question about files we do maintain — the instruction files that load into a coding agent's context before anyone types a word. The result was an 11% cut on one repository, not an 80% one, and a set of findings that had almost nothing to do with byte counts.
A word on the title, because the honest answer matters more than the hook. No deterministic gate broke: all 14 in our validation chain exited 0 after the changes. What broke was the assumption that a vendor's headline reduction transfers to a customer's repository — and, separately, the audit surfaced a stack of things that were already broken and had been for months. Those are the two subjects of this post.
One boundary first, so the scope is unambiguous. This is about the static instruction layer: the files an agent reads on every request regardless of what you ask it — CLAUDE.md
, AGENTS.md
, skill descriptions, a memory index. It is not about managing context while an agent is running; retrieval budgeting, compaction and memory tiering live one layer up, in our runtime context-engineering playbook. And it is not a survey of how common these problems are across other people's repositories — the six named configuration smells from a study of 100 open-source config files are covered in our config-smells reference. This post is one estate, measured on one date, with the measurements written down.
- 01The 80% figure is Anthropic's, on Anthropic's evals.Anthropic published it on July 24, 2026 and stated the quality result against its own coding evaluations. That is the only quality claim in this entire post that rests on a controlled comparison, and it is not ours.
- 02An independent re-measurement says ~70%, not 80%.Pawel Huryn published commit-verified captures on July 21, 2026 and found the memory block had been made conditional rather than deleted. Counting it as loaded on both sides gives 69%; excluding it from both sides gives 73%.
- 03Only frontier models got the cut.Cat Wu of Anthropic: there is now a different system prompt per model, and "it's only our most frontier models that have this 80% token decrease — the older models still have the full system prompt." Huryn's per-model captures corroborate it.
- 04Our own cut was 11%, on a different denominator.Always-on load on our orchestrator repo — root CLAUDE.md plus a memory index plus skill descriptions — went from about 55 KB to about 48.7 KB on August 29, 2026. Most of that load was not over-specification, which is why the headline did not transfer.
- 05The contradictions were worth more than the bytes.Four separate strata each held a pair of instructions that disagreed with each other, including a rebuild document telling a future rebuilder to recreate a defect the drift checker now blocks. Bytes are a proxy; contradictions are the damage.
- 06We measured load, not output quality.All 14 deterministic gates stayed green. That is a regression signal, not a quality signal. We ran no controlled output-quality comparison, so this post reports no quality delta of its own.
01 — The NumberWhose 80% is it, exactly? #
The claim that started this is one sentence, and it is worth quoting in full because almost every retelling drops half of it. Writing on Anthropic's blog on July 24, 2026, Thariq Shihipar — a member of technical staff at Anthropic — said: "We removed over 80% of Claude Code's system prompt for models like Claude Opus 5 and Claude Fable 5 with no measurable loss on our coding evaluations." The reduction is Anthropic's measurement of Anthropic's own file, and the "no measurable loss" is Anthropic's result on Anthropic's own evals. Neither half has been independently reproduced, and both get repeated as though they were general findings.
Three days before that post, on July 21, 2026, the practitioner Pawel Huryn published something the coverage almost entirely ignored: a re-measurement, with the raw captures and diffs committed to a public repository, of how much the Claude Code system prompt had actually shrunk between April and July 2026. His conclusion was not 80%.
The defensible headline is ~70%. 80% is real only if you count a memory-off session (banking the whole memory block as a deletion).Pawel Huryn, phuryn/experiments, July 21, 2026 — commit-verified
The mechanism behind the gap is the single most useful correction available on this topic, and Huryn states it in two words: "Relocation, not deletion." The # auto memory
block accounted for 29% of April's instruction prose. It did not vanish; it became conditional, injected only when memory is switched on, and the surviving memory section was itself rewritten and shrank 59%. Depending on how you treat that block, the same pair of captures yields 81%, 73% or 69% — all three of which are honest, and only one of which reads like a headline.
He also notes that the count of distinct Claude Code prompt fragments grew over the same period — reported by Huryn, citing the Piebald-AI extraction, from roughly 350 to 515 or more — as pieces moved from always-loaded to loaded-on-demand. A prompt can get shorter at the top of every session while the total body of instruction behind it gets larger. That is a different achievement from deletion, and a far more reproducible one.
The table below is the comparison we could not find assembled anywhere: the same class of claim, measured five different ways, with the one column most coverage omits.
| What was measured | Reduction | Who measured it | Output quality evaluated? |
|---|---|---|---|
| Vendor and independent measurements of a vendor's own prompt | |||
| Claude Code system prompt, frontier models only | "Over 80%" | Anthropic, Jul 24, 2026 | Yes — Anthropic's own coding evals, "no measurable loss" |
| Same prompt, instruction prose by word count, memory excluded from both captures | 73% | Pawel Huryn, independent, Jul 21 | No |
| Same prompt, instruction prose by word count, memory loaded in both captures | 69% | Pawel Huryn, independent, Jul 21 | No |
| Lean system-prompt configurations, internal coding-agent eval sample | Tokens −41–66% | OpenAI, model guidance | Yes — eval score +10–15%, stated as "directional" |
| Our own single-site measurements · August 29, 2026 | |||
Orchestrator repo always-on load: root CLAUDE.md + MEMORY.md index + five skill descriptions |
~11% (~55 KB → ~48.7 KB) | Us, Aug 29, 2026 | No — no controlled comparison was run |
Digital Applied repo always-on load: CLAUDE.md + AGENTS.md + GEMINI.md |
~50% (20,587 B → 10,255 B) | Us, Aug 29, 2026 | No — 14 deterministic gates green, nothing more |
Read down the last column and the shape of the public conversation becomes clear. Two rows carry a quality result, and both belong to vendors measuring their own configurations on their own evaluations. The independent measurement does not claim one. Neither do ours. A reader who takes "cut 80% and nothing got worse" as the transferable lesson is taking the half of the sentence that nobody outside a frontier lab has been able to check.
There is one more qualifier, and it is the most load-bearing sentence in the whole story. Speaking in a fireside chat with Simon Willison on July 21, 2026 — the conversation that first surfaced the 80% figure — Cat Wu of the Claude Code team explained the scope: "We actually have a different system prompt per model now, for this very reason. It's only our most frontier models that have this 80% token decrease — the older models still have the full system prompt." The thesis is not "prompts should be shorter." It is "prompts should be shorter for models capable of carrying the judgement the prompt used to spell out" — which is an entirely different instruction to a reader running Haiku in a cost-sensitive pipeline.
Huryn's captures corroborate her independently. On the same day, he pulled the base prompt for every current model through the API and found two prompts, split by capability tier — and the split is stark enough to see at a glance.
Claude Code base system prompt, words per model tier
Source: Pawel Huryn, phuryn/experiments, same-day API capture of every current model, July 21, 2026Two base prompts, not one, and the workhorse models keep the verbose version. Anyone reading the 80% claim as advice about their own configuration should first check which side of that line their model sits on — and note that the instruction layer they are pruning will outlive the model it was written for, a durability asymmetry we set out in why models swap in 48 hours and the harness does not.
02 — Always-On LoadWhat loads before you type a word. #
The design of our audit was deliberately awkward. One reviewer pass by Claude Opus 5 at high effort, then a second pass by Claude Fable 5 in a fresh session at extra-high effort, forbidden from reading the first pass until it had written its own findings, then a synthesis that adjudicated the two. The stated reason, from the audit's own README: this audit is about what loads into context, and a session that already contains the first model's conclusions cannot re-derive them independently.
Both models were handed the same brief and the same method requirement — measure, do not impressionise; report byte counts and estimated token cost for anything that loads every session; cite file and line for specific defects. The first thing they were asked to establish was the baseline: how much text enters the context window before the first user word.
On the orchestrator repository, Opus 5 counted the root CLAUDE.md
at 30,213 bytes, a MEMORY.md
index at 20,497 bytes, and five skill frontmatter descriptions at 4,127 bytes — 54,837 bytes in total, roughly 13,700 tokens at four characters per token, loaded before anything happens. Fable 5, working blind, reported "≈ 55 KB ≈ 13–14 K tokens loaded into every session before the first user word." Two models, two sessions, no shared context, the same number. The synthesis recorded it as the strongest agreement in the whole exercise.
Keep this file lean. Bloated CLAUDE.md makes Claude skim / ignore content.An instruction inside our own 30 KB CLAUDE.md — quoted by the audit, August 29, 2026
That is the finding in miniature. The instruction was correct. The file containing it was 30 KB. Nothing in an instruction file enforces the instruction file's own rules, and prose does not audit itself — which is the argument section 06 turns into a build gate.
The results, and here the denominators matter more than the percentages. Two repositories were audited, measuring different sets of files, and the two numbers are not two samples of one quantity.
| Repo | Files counted (the denominator) | Before | After | Change |
|---|---|---|---|---|
| Mac orchestrator | Root CLAUDE.md + MEMORY.md index + five skill frontmatter descriptions |
~54,837 B (~13,700 tok) | ~48.7 KB | ~11% |
| Digital Applied blog pipeline | CLAUDE.md 9,697 → 7,599 B · AGENTS.md 5,862 → 2,139 B · GEMINI.md 5,028 → 517 B |
20,587 B | 10,255 B | ~50% |
CLAUDE.md
, a memory index and five skill descriptions — on this Mac, on August 29, 2026. The ~50% is always-on load on the Digital Applied repo — three root instruction files, nothing else — on the same day. There is no combined number, because there is no shared denominator to combine them over. A figure taken from the audit's EXECUTION-LOG.md
would also be slightly wrong: its before/after table was drafted before the final edits landed, and the corrected byte counts live in the synthesis document.The reason for the gap between 11% and 80% is structural, not effort. Most of the orchestrator's always-on load was not over-specification at all. It was a hand-maintained memory index and a set of genuinely non-inferrable operational lessons, and only some of that was safe to remove. On the Digital Applied side, by contrast, half the load turned out to be one linter's ruleset restated in prose — which deletes cleanly, because a linter and a formatting hook already enforce every line of it.
Which is the honest generalisation available here: the size of your available cut is set by what your files are made of, not by how aggressively you are willing to edit. A repository whose instruction files are mostly redundant tooling documentation has an 80%-shaped cut waiting in it. A repository whose instruction files are mostly hard-won operational knowledge does not, and pruning to hit a percentage would destroy the valuable part first.
03 — DispositionWhat we cut, what we kept, and why. #
"Cut 80%" is not an instruction anyone can act on. What a reader can act on is a disposition: for each category of content in an instruction file, was the right move to delete it, relocate it, replace it with an executable check, or leave it alone? The table below is our answer for every category we encountered, with the specific file and byte delta attached. Note that the keep rows are as long as the cut rows — that is the finding, not an apology for it.
| Content category | Disposition | Our instance | Why |
|---|---|---|---|
| Removed or relocated | |||
| A linter's ruleset restated in prose | Cut | AGENTS.md 5,862 → 2,139 B; GEMINI.md 5,028 → 517 B; the same ruleset existed in five files |
Biome enforces it and a formatting hook auto-fixes it — the clearest violation of "don't restate what a linter enforces" |
| Component-level knowledge in a root file | Moved | ~3.5 KB relocated into directory-scoped CLAUDE.md files |
Progressive disclosure — it now loads only in the directory where it applies |
| Two adjacent instructions pointing opposite ways | Cut one side | CLAUDE.md:121 deleted, :123 kept |
The exact failure mode Anthropic's post opens with — see section 04 |
| Resolved or expired memory entries | Deleted or condensed | 2 deletions, 6 condensations, 2 rewrites; 20 files carried unswept self-declared delete conditions | A memory index is a working set, not an archive |
| Converted into something executable | |||
| A structural convention held in prose | Turned into a check | check-blog-frame.mjs ; 1,236 of 1,236 posts already conforming when the gate was written |
Three prose documents had disagreed about it; one executable spec cannot |
| A style rule held in prose | Turned into a check — after one failed attempt | Legacy CSS classes: a regex flagged 77, an AST check found 3 | The naive check would have failed every post that teaches the legacy syntax |
| Repaired or kept | |||
| Broken memory plumbing | Repaired, not cut | 63 name: fields and 11 broken links fixed |
Not bloat — the retrieval mechanism was simply broken |
| Non-inferrable safety invariants | Kept | The rm -f ban, Terminal.app for cask operations, the live PNPM_HOME , --archive=tgz on prebuilt deploys |
Expensive lessons no model derives from a file tree |
| Domain and editorial policy | Kept | The topic kill list and the strategic-fit gate | Business context, not a generic convention — see section 07 |
| Deterministic gates | Kept and added to | 14 gates, exit 0 | Executable specs are worth more under the new guidance, not less |
The five-copies row deserves its own sentence, because it is the most widely reproducible finding in the table and it has nothing to do with model generations. One linter's ruleset existed, in near verbatim prose, in AGENTS.md
, GEMINI.md
, a Cursor rules file, a Windsurf rules file, and .github/copilot-instructions.md
. Five copies, one linter, and a formatting hook that already fixes every violation automatically. Nobody decided to do that; it accreted, one per-tool instruction file at a time, which is the structural pressure we described in cross-harness skill portability and lock-in. If you maintain instruction files for more than one agent tool, this is the first place to look and it is usually the largest single cut available.
The "moved" rows matter as much as the "cut" rows, and they are the same mechanic Huryn found on Anthropic's side. Anthropic's post names the myth directly: a common belief is that these files should be a central repository for every practice you might ever need, because the agent would not find it otherwise — and the recommended alternative is a tree of files loaded at the right time. Skills are the standard vehicle for that on-demand tier, which we cover in our agent skills framework guide. Section 05 is about the one place where that vehicle does not actually save anything.
04 — Conflicting GuidanceThe contradictions were worth more than the bytes. #
Anthropic's post does not lead with the byte reduction. It leads with a diagnosis: "Overall, we found that we were overconstraining Claude Code, both through our system prompt and in our CLAUDE.md files and skills." And the named symptom is not length — it is disagreement. Reading transcripts of internal usage, the team saw "several conflicting messages in a single request like 'leave documentation as appropriate,' or 'DO NOT add comments' as our system prompt, skills, and user requests clash with each other."
Shihipar put the mechanism plainly in the fireside chat: the team moved toward more context and fewer "do not do this" instructions, because a prohibition is a strong impulse for the model and "especially if it conflicts with user instructions later on, that can be extremely confusing." A hard negative constraint does not just occupy tokens. It competes with whatever the user actually asked for.
We found four instances of that failure in one day, in four different strata of the same estate. They are the reason this audit was worth running even though the byte reduction was modest.
Delegate freely, and don't over-delegate
CLAUDE.md line 121 said to spawn subagents in parallel and keep working. Line 123 said not to over-delegate, that this model reaches for subagents readily, and to keep spawn counts low. Two adjacent paragraphs, opposite directions — line 121 was written for the previous model generation, line 123 was the correction nobody applied to line 121.
Rebuild the machine into a state we now block
The from-scratch rebuild document instructed a rebuilder to recreate a package-manager prefix hijack that the maintenance log records as a vendor-installer defect, fixed the following day, and which a drift checker now enforces against. Found by the second model only, and still unfixed when this was written.
Treat the stalest section as truth
One section of an editorial fact pack told agents to treat what was in fact its most out-of-date section as authoritative. Another section of the same file declared that section superseded. Both were live, both loaded, and an agent following either one was following the file correctly.
An accurate banner over contradicting content
A framework document carried a banner accurately describing its own status, above roughly 1,200 lines that contradicted the banner. A reader who trusted the banner and a reader who trusted the body got different instructions from one file.
The synthesis document's verdict on the pattern was blunt: "Four passes of the same disease in four different strata — the article's emphasis on this failure mode is earned." That is worth dwelling on. We went in expecting the interesting number to be a byte count. The interesting finding was that our instruction estate contained four live pairs of mutually exclusive instructions, and that no amount of trimming would have found them, because every individual line was reasonable on its own.
The second-stratum item is the one that changed how we think about these files. The second model's framing was: a rebuilder obeying step 7 as written builds the machine into the state the drift checker then flags as broken. That is not bloat and it is not style. It is an instruction file actively instructing a future reader to create a known defect — a failure that gets worse, not better, as the surrounding tooling improves, because the tooling that would catch it is the same tooling the document predates.
How common is this in the wild? Not our question to answer from one estate — but the prevalence work exists, and our config-smells reference covers the academic study that named and counted the pattern across a hundred open-source configuration files. Read that for how often; read this for what it looks like from the inside when you go looking in your own repository.
05 — AdjudicationTwo models, the same files, different fix. #
The two passes converged on the measurement to within about 300 tokens without seeing each other's work. Then they split on the single largest projected saving — and the second model was right, for a mechanical reason the first one missed. This is the most transferable thing in the audit, so it gets a section rather than a footnote.
The orchestrator's root instruction file carried a quick-triggers table of roughly 40 rows: short phrase-to-action mappings the agent consults to route work. Opus 5 recommended converting that table into five skills, projecting a saving of about 6 KB per session. The logic is exactly what Anthropic's guidance recommends — move detail out of the always-on layer and let the agent load it on demand.
Fable 5, reading the same file blind, partially inverted the recommendation on one observation.
Skill descriptions load every session too, so converting a one-line row into a skill saves nothing; it only pays off for the fat rows.Our synthesis document § 4.1, recording the second model's amendment — August 29, 2026
This is worth unpacking slowly, because it is a general result and it is easy to get wrong. Progressive disclosure moves the body of a skill out of the always-on context. It does not move the skill's description — the one-line summary the agent reads to know the skill exists and when to reach for it. That description loads every session, by design; without it the agent cannot discover the skill at all. Our own baseline measurement made this visible and neither model missed it: five skill descriptions accounted for 4,127 bytes of the always-on load.
So the arithmetic of relocating a one-line table row into a skill is roughly: remove one line from the always-on layer, add one description line to the always-on layer, net zero, plus a new discovery step the agent has to take on a cold session. Progressive disclosure pays for itself in proportion to the ratio between a skill's body and its description. For a fat, multi-paragraph procedure, that ratio is enormous and the move is obviously correct. For a one-line trigger, the ratio is about one and the move is pure overhead.
The amended recommendation was to compress the table in place, mint at most one or two skills for the genuinely fat rows, and keep every trigger phrase discoverable — with the second model's own projection being roughly the same 6 KB per session the first model had forecast, with no cold-session discovery loss. Same saving, opposite structural move.
A second disagreement ran the same way. The first pass proposed rebuilding an existing blog-authoring skill as a six-file router. The second pass checked for inbound references and found zero — nothing in the execution kit, the editorial charter, or the agent definitions called that skill at all — and recommended a 3–4 KB pointer instead, on the grounds that the component contract had already moved into code, and "a third prose copy of the frame is the drift pattern this whole audit exists to remove." The first pass had independently scored the same skill against the six governance concepts it claimed to own and found it scored zero on all six.
| Item | First pass (Opus 5) | Second pass (Fable 5, blind) | Outcome |
|---|---|---|---|
| Orchestrator always-on load | ~13.7 K tokens | ~13–14 K tokens | Converged independently | | Quick-triggers table, ~40 rows | Convert to five skills, ~6 KB/session | Compress in place — skill descriptions load every session too | Amended; the second version was executed | | The blog-authoring skill | Rebuild as a six-file router | Zero inbound references — make it a 3–4 KB pointer | Amended; the second version was executed | | Per-tool-call hook context cost | Flagged as an unmeasured risk | Measured: zero context injected on ordinary calls | Closed with evidence | | Rebuild document, step 7 conflict | Not in scope | Highest-severity item found | Second pass only | | Five copies of one linter's ruleset | Found | Not in scope | First pass only | | Missing structural gate | Found; gate written | Reviewed; ship as-is | Agreed |
The coverage split was intentional and the reviewers described it themselves: the passes barely overlap by design, and where they touch they agree. The first audited the always-on layer; the second audited the on-demand layer the first had declared out of scope. No finding of the second contradicted a finding of the first — it contradicted two of the first's recommendations and closed three of its open questions with evidence.
The reusable lesson is a division of labour. Measurement converges reliably; two capable models counting the same bytes will agree. Recommendations do not converge, because they involve projecting a saving through a mechanism, and a mechanism can be misunderstood in a way a byte count cannot. So measure once, and adjudicate the recommendations with a second, blind pass. Notably, the first pass had already flagged the quick-triggers conversion as its own most-likely-wrong call and left it unexecuted — which is the only reason the second pass could overturn it cleanly rather than reverse work already shipped.
06 — Executable SpecsA prose rule becomes a check. #
The strongest version of "don't restate what your tooling already enforces" is not deletion. It is building the enforcement, then deleting the prose — because now the rule is checked rather than hoped for, and it cannot drift into three disagreeing copies.
Our clearest example was structural consistency across published posts. Every post shares a required component frame, and that consistency had been produced entirely by cloning a named reference post — code as specification, which is exactly what the new guidance recommends and which had worked well. But two documents disagreed about which post to clone, a third claimed authority over the same question, and no check verified structure at all. In the deep dive's own words: a post missing its takeaways block, or closing without the call to action, ships clean today.
So we wrote the gate: an abstract-syntax-tree check asserting that the ten frame components appear exactly once each, in render order, that the table of contents and right rail are present, and that every section heading carries an anchor id and a number. Measured before the gate was written, all twelve invariants were already at 1,236 of 1,236 conforming posts. It was then negative-tested against a deliberately broken post — duplicated hero, missing takeaways, out-of-order FAQ, a heading missing its id and number — and correctly exited 1.
That is the pleasant version. The same day produced the unpleasant one, and it is more instructive.
*"That recommendation was wrong and would have shipped a broken gate."*A grep found
77 apparent violations— but most sat inside posts that
teachthe migration away from those very classes, quoting the old syntax as the thing being replaced. Rewritten as an AST check that inspects
className
string literals only, the real count was 3. A 96% false-positive rate, caught before the gate went in.
The honest version of "turn your prose rules into checks" has to include that failure, because it is the predictable one. A rule stated in prose can rely on a reader's judgement about context; a check cannot. Every time you convert one, you are forced to decide what the rule actually means at the boundary — and a naive implementation will confidently enforce a version of the rule you never intended. The near-miss cost about an hour. Shipped, it would have blocked 74 legitimate posts and taught everyone to bypass the gate.
07 — The Keep ListWhat survived by design. #
Both passes, independently, produced almost the same keep-list — and the first pass's framing of it is the sentence to take away: the first rule says trade rules for judgement, "but not all of these are over-specification." Some instructions encode information that is not derivable from the repository at any level of model capability, and cutting those is not rightsizing. It is deleting the only copy.
Non-inferrable invariants
Never use rm -f or rm -rf on user files, because it bypasses both the Trash and iCloud Recently Deleted. Homebrew cask operations need Terminal.app. The live PNPM_HOME is a specific path. Append a dated log entry after each maintenance run. Pass --archive=tgz on prebuilt deploys. Every one is a lesson someone learned the expensive way, and none is visible in a file tree.
Domain policy
Asked directly whether editorial guardrails should go, the deep dive said no: the rules-to-judgement shift is about generic conventions a capable model can infer — comment density, naming, code idiom. It is not about domain policy. A kill list encoding which topics a business will not write about is business context no model derives from a repository.
Broken retrieval
Most memory files had a name field that did not match their filename — unquoted YAML truncating at the first space, producing five files all named the same thing, plus entries named simply AI, Strict and PENDING. The contract says links resolve via that slug, so with those values they could not resolve. Eleven links were broken outright. That is not bloat; it is a mechanism that had quietly stopped working.
Deterministic gates
The counter-intuitive consequence of the new guidance is that executable specifications get more valuable, not less. Every rule you can move from prose into a gate is a rule that no longer competes for context, cannot contradict another file, and does not decay when a model generation changes underneath it.
The memory corpus deserves its own note, because it is where the "instruction files are bloated" framing fits worst. Yes, there was accretion: the largest single memory file was 125,369 bytes across 438 lines — roughly 34,000 tokens if recalled — a run journal whose own entries said their lessons had already been folded into a repository README. A closed legal-case memory ran to 41,924 bytes and instructed its own deletion twice. Twenty files carried self-declared expiry conditions and nothing swept them.
But stale memory was not just occupying space; it was actively contradicting the live documentation. One environment file listed six uninstalled applications as installed and named the wrong model as the current default, against a root instruction file that named the right one. A profile file said the blog held about 1,000 posts; the live count is over 2,100. Every one of those is a fact an agent would have used, stated with the same confidence as the correct facts beside it. The fix for that is not a smaller file. It is a sweep, and something that runs the sweep on a schedule.
One more finding worth recording, in the interest of not only reporting the alarming ones. The backup was not a backup: the mirror held 92 of 142 files and had last synced 71 days earlier, verified by checking the timestamp on the backup's own index, while the restore document described the backup as holding 32 files. Nobody would have discovered that except by trying to restore.
08 — The LimitWhat we did not measure. #
Everything above is a measurement of load and a record of defects found. It is not a measurement of whether the agent got better. Nothing in this audit establishes that, and the audit said so about itself before we ever considered publishing it.
What we do have is a regression signal. After the changes, the full validation chain — 14 deterministic gates including a TypeScript check, the new frame gate, the legacy-class gate and a link check across every edited document — exited 0, and the second model re-ran the whole chain independently and confirmed it. Every markdown link in the eight edited context files resolved. The lint pass was clean on every edited file.
That is a meaningful thing to have and a small thing to claim. It says we did not break the deterministic parts. It says nothing about whether the agent now writes better code, follows instructions more faithfully, or needs fewer corrections — because measuring that requires a controlled comparison on representative tasks, and we did not run one. Anyone who tells you their instruction-file cleanup improved agent quality, without describing the eval they ran, is telling you how they feel about their files.
OpenAI's own model guidance is unusually direct about the missing step. Its "Favor leaner prompts" section reports that in a sample of internal coding-agent eval runs, leaner system-prompt configurations "improved evaluation scores by roughly 10–15% while reducing total tokens by 41–66% and cost by 33–67%" — and immediately adds that results will vary by workload and the ranges should be treated as directional and validated on representative tasks from your own application. Its method prescription is two sentences long: start from a prompt and tool set that already works, remove one group of instructions, examples or tools at a time, then rerun the same evals. That is the loop we did not close, and it is the honest next step for anyone doing this work — ours included.
It is also worth remembering what "minimal" was supposed to mean. Anthropic's own engineering post from September 29, 2025 defines the target as "finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome" — and then pre-registers the caveat that the 80% headline invites people to ignore: "Note that minimal does not necessarily mean short; you still need to give the agent sufficient information up front to ensure it adheres to the desired behavior." The same post calls the target the "right altitude," a Goldilocks zone between brittle hardcoded logic and vague high-level guidance. A percentage is not an altitude.
09 — MethodologyRun it on your own files. #
The design is reproducible with any two capable models and an afternoon. The two things that made it work were the blindness of the second pass and the requirement to cite bytes and line numbers rather than impressions.
Measure the always-on layer first
Byte-count every file that loads before the first user word — root instruction files, per-tool instruction files, skill or command descriptions, any memory index. Write the total down with the date and the exact file list. That list is your denominator, and you will need it every time you quote a percentage.
Two passes, the second one blind
Give both models the same brief. Forbid the second from reading the first's findings until it has written its own. Measurement will converge and confirm itself; recommendations will diverge, and the divergence is where the mechanical errors surface. Then synthesise, and record which recommendations were overturned.
Hunt contradictions, not length
Grep for pairs. Any two instructions that could both be followed but not at once — a permissive line and a restrictive line on the same subject, a rebuild document older than the fix it predates, a banner disagreeing with its own body. These are worth more than any byte count and no linter finds them.
Convert, then delete — and close the eval loop
Move a prose rule into a check before deleting the prose, and negative-test the check against a deliberately broken input. Then do the part we did not: remove one group of instructions at a time and rerun the same evals on representative tasks from your own workload. Green gates are a regression signal, not a quality result.
What this measurement is. A single-site audit of two repositories on one machine, executed 2026-08-29. Design: one reviewer pass by Claude Opus 5 at high effort; one blind second pass by Claude Fable 5 in a fresh session at extra-high effort, withheld from the first pass's output until its own findings were written; then a synthesis adjudicating both. Both passes received the same brief, which tested six rules drawn from Anthropic's 2026-07-24 post plus two added emphases — eliminate conflicting guidance, and don't restate what the repo structure, a linter or the code already enforces — and required byte counts, estimated token costs and file-and-line citations.
Byte counts come from
wc -c
, with token estimates at roughly four characters per token. Verification was the repository's own 14-gate chain, exit 0, re-run independently by the second pass.
What it is not: a benchmark, a multi-site study, or a controlled output-quality comparison. No quality delta is reported because none was measured. Percentages are per-repository and are not comparable across repositories.
www.digitalapplied.com/blog/ai-agent-instruction-file-audit-what-we-cut
. When citing our figures, carry the denominator: "always-on context load, single repository, measured 2026-08-29." When citing the 80% figure, it is Anthropic's, measured on Anthropic's own coding evaluations, and it applies to frontier models only — pair it with Huryn's independent ~70% re-measurement of 2026-07-21.One last piece of context on where this layer sits. Instruction files are the static tier — loaded before anything happens, identical on every request. Everything about what an agent does with context once it is running, and how to keep a long session coherent, is a separate discipline covered in our agent reliability playbook. The two interact — a leaner static tier leaves more room for runtime context — but they fail differently and you fix them with different tools. If you want help auditing either layer against your own workload, that is part of what our AI transformation engagements cover.
10 — ConclusionA percentage is not an instruction. #
The vendor's 80% was measured on the vendor's evals, an independent re-measure says 70%, and our own cut was 11%. The gap is made of what the files are made of.
Anthropic removed over 80% of Claude Code's system prompt and reported no measurable loss on its own coding evaluations — its figure, its evals, its file, and frontier models only. An independent, commit-verified re-measurement published three days earlier puts the defensible number nearer 70%, because the memory block was made conditional rather than deleted. Both facts belong in any honest retelling, and most retellings carry only the first.
Our own always-on load fell about 11% on the orchestrator repository — root instruction file, memory index and five skill descriptions, on this machine, on August 29, 2026 — because most of that load was never over-specification. It was operational knowledge and a memory index, and only some of it was safe to remove. On a separate repository, measuring three root instruction files, the cut was about 50%, almost entirely because half of it was one linter's ruleset restated in prose. Different denominators, different answers, no combined number.
What made the day worth it was not either percentage. It was four live pairs of contradictory instructions in four different strata of one estate, a rebuild document instructing a future reader to recreate a defect the tooling now blocks, a retrieval mechanism that had silently stopped resolving, a backup 71 days stale, and one genuinely mechanical correction — that skill descriptions load every session too, so relocating a one-line rule into a skill saves nothing. Go looking for length and you find bytes. Go looking for disagreement and you find the damage.
And the discipline that has to survive all of it: we measured load, recorded that 14 deterministic gates stayed green, and stopped there — because a green gate is a regression signal, not a quality result. The next honest step is the one OpenAI's guidance describes and we have not yet taken: remove one group of instructions at a time, and rerun the same evals on your own work.