The Eighty Percent That Did Not Transfer

A vendor trimming its own system prompt and a user trimming their configuration are doing two different operations, and the second inherits none of the first's ratio. Anthropic cut Claude Code's system prompts by up to 80% for a new model generation, which raised an obvious question for anyone maintaining a configuration stack on top of it, so the same audit ran against a real one: every file that loads before the user types a word, measured, ranked, and costed.

The always-loaded surface came to roughly 22,400 tokens: about 15,400 in files the user wrote, and about 7,000 in the rosters the harness injects, whose content the user also controls. Token counts were bytes divided by 3.8 rather than tokenizer output, since no tokenizer was available on the machine, so the byte counts are exact and the token figures carry about ten percent of slack.

The audit found about 6,900 tokens, or 31%, of defensible cuts, and did not find 80%. The reason is a distinction worth having a name for. A vendor's system prompt is mostly capability scaffolding: instructions on how to use a tool, how to plan, how to break down a task, written for a weaker model and now trained in. That text deletes cleanly when the model improves. A configuration stack is mostly facts a model cannot infer at any capability level: which host is primary, which account owns which repository, what was decided on a particular date and which failure produced which rule. Capability growth does not make a fact redundant. Chasing the vendor's ratio on this kind of text deletes scar tissue, and each piece of scar tissue in this stack traced back to the specific incident that produced it.

What does transfer is the principle underneath the vendor's number, which is to remove scaffolding built for limitations the current generation no longer has. That is where the 31% came from, and roughly half of it was one class: text duplicated by the harness itself, sections telling the model something its own system prompt now states more accurately. A further 15 to 20% is reachable structurally rather than textually, by loading rules only in the directories where they apply, and the largest single saving in the audit was not a deletion at all but a routing change, running mechanical scheduled jobs in a lean mode that skips the whole stack, since those jobs pay the full surface on every run and never consult a line of it.

Two findings landed outside the size question. The stack contained a table of current model identifiers whose automated updater had been broken for ten days, and it asserted the previous generation as the frontier while the session reading it was running on the current one, which inverts what a configuration file is for: instead of adding knowledge the model lacks, it subtracted knowledge the model had. And the file sizes over four months show pruning to be a periodic heroic act against continuous growth, at about 129 bytes per day of regrowth after the last prune, on a trajectory back to the pre-prune peak in roughly three months. A trim without a budget mechanism buys a quarter.

Method, the measurement approach, the ranked proposal with risk ratings, the taxonomy of what was kept, and the honest limitations are in the companion methodology and raw data. Nothing was edited: this was a proposal, so there is no confounded before and after to defend, and there is also no behavioural evidence that the cuts are safe.

That absence is the real gap. Every risk rating in the audit was reasoned from text and provenance rather than measured, and the honest way to close it is an A/B run of a fixed task set against trimmed and untrimmed stacks, which is a larger job than the audit and has not been done.