Prompt Stack Trim: Method, Taxonomy and the Ranked Proposal

What was measured

Every file and injected block that enters a session's context before the user types anything, for an agent configuration stack layered on Claude Code: global memory, its imports, the project memory files on the working directory's path, and the rosters of skills and agents that the harness injects, whose text the user writes.

Two categories, measured separately because they have different owners and different fixes:

Method caveat that governs every number here. No tokenizer was available on the machine and the plan carried no API key, so token figures are bytes divided by 3.8, which tracks the vendor's tokenizer to roughly ten percent on markdown prose with tables. Byte counts are exact; treat the token counts as carrying that slack.

Scope caveat. "Always loaded" is measured for a session in one working directory. Deeper paths load more project memory, and the worst case measured in this stack was about 17,000 tokens of user authored text before the rosters.

One structural fact worth checking in any similar stack: the per account configuration directories were symlinks into a single tree, so there was exactly one prompt stack across four accounts rather than four. Any cut lands on every account simultaneously, which raises the blast radius of a bad one.

What did not count as bloat

On demand content was inventoried and then set aside as working correctly: skill bodies load only on invocation, extracted reference documents load only when read, and tool schemas defer through the harness's own search mechanism. A stack can carry a large library cheaply. What it cannot carry cheaply is text that loads unconditionally.

The taxonomy

The finding that decides the ratio is a distinction between two kinds of text.

Capability scaffolding describes how to do something the model can now do unaided: how to use a tool, how to plan, how to decompose a task, how to manage a context window. It was written for a weaker model, it is trained in now, and it deletes cleanly when the model improves. A vendor's system prompt is mostly this, which is why a vendor can cut 80% of one.

Irreducible facts are propositions no capability level can infer: which host is primary, which account owns which repository, what was ruled on a particular date, which incident produced which rule. A user's configuration stack is mostly this. Capability growth does not make a fact redundant, so the vendor's ratio does not transfer, and pursuing it deletes the specific knowledge the file exists to carry.

Applying that distinction to this stack yielded about 6,900 tokens, or 31%, of defensible cuts.

Categories of cut, ranked by tokens times confidence

Stated as categories rather than as a file inventory, since the object measured is a private configuration.

1. Skill bodies imported inline that are also registered as skills. The largest single item, roughly 2,850 tokens, paid twice: once as a roster description and once as an inlined body, while the compressed decision content already sat inline above each import. The action is to replace each import with a pointer and keep the compressed routing lines. The risk is real and worth naming: a routing table is load bearing precisely because the model may not know it needs to consult it, and a skill that fires on description match can fail to fire.
2. A subsystem manual that duplicates documentation one read away, about 1,620 tokens, where every section already ended with a pointer and every pointer target was verified to exist. Cut to one line per subsystem. The risk here is discovery rather than detail: a session that does not know a subsystem exists will not go looking, so the index must preserve the names even when it defers the commands.
3. Roster hygiene, about 800 tokens, in two halves. Retiring skills confirmed dead by the stack's own text is safe. Compressing descriptions is not, because the description is the discoverability surface, and over compression presents as the skill not existing rather than as an error.
4. Conditional content in project memory, about 800 tokens, where explanations of mothballed or directory specific work load for every session anywhere in the tree.
5. Sections the harness now states itself, about 530 tokens, verified line by line against the session's own system prompt rather than assumed.
6. A stale reference table, about 300 tokens, discussed below as a correctness fix.

Two items are structural rather than textual, and the second is worth more than all six above.

Conditional loading. A further 15 to 20% is reachable by scoping rules to the directories where they apply, which is a mechanism the harness supports and this stack barely used.

Lean modes for mechanical scheduled jobs. More than a hundred scheduled entries existed, of which four used any lean invocation mode. Every other job paid the full always on surface on every run, including jobs doing purely mechanical work that will never consult a behavioural profile or a routing tree. This saves more total tokens per day than every deletion combined and costs interactive sessions nothing, because it changes who pays rather than what exists. The caveat is that the leanest mode also drops hooks, so jobs depending on session lifecycle hooks must be audited individually, and jobs doing judgment work should keep the full stack, since the context is what makes their judgment match the author's.

The correctness finding

The stack contained a table of current model identifiers, maintained by an automated updater that had been broken for ten days. It asserted the previous model generation as the frontier while the session reading it was running on the current one, and the harness's own system prompt stated the current family correctly.

That inverts what a configuration file is for. Instead of adding knowledge the model lacks, it subtracted knowledge the model had, and a session trusting it would have reported a superseded model as current or dispatched work to an alias believing it got the older one. The fix was to delete the rows the harness supplies and keep the rows it does not, which are third party models and the routing decisions attached to them. A self updating table becomes a liability the moment its updater dies quietly, and nothing in the stack would have surfaced that.

The regrowth curve

Sizes of the largest always loaded file, from version control snapshots:

Regrowth since the last prune runs at about 129 bytes per day, which returns the file to its pre-prune peak in roughly three months. Pruning is a periodic heroic act against continuous growth, so a trim without a budget mechanism buys one quarter. The proposed mechanism is a byte budget per always loaded file asserted by an existing scheduled checker, firing on breach and silent when healthy, where a breach is a prompt to extract rather than to delete.

What was kept, and why

Every rule traced to a specific failure that produced it was kept, and the audit dated each one from version control history. The categories that survived without compression:

• rules encoding a failure mode with a mechanism the harness does not cover, such as detecting a silently truncated tool result, or the specific behaviour of background timers that stopped firing;
• rules that are counter-instinctive, where the model's default behaviour is the wrong one;
• privacy and publication rules, which are not compressed to save tokens under any budget;
• values rules, which are not capability questions at all;
• the behavioural profile, the second largest always loaded file and the most tempting target by size, kept because none of it is inferable, all of it was validated against its subject, and parts of it exist specifically as corrections of earlier wrong compressions of the same file. Deleting behavioural calibration to save tokens makes every response slightly worse to save a few percent of context, and the right lever on that file is not deletion but the routing change above.

Protocol proposed for execution

1. The correctness fix first and alone, since it is reversible in one edit.
2. Archive rather than overwrite, keeping the pre-trim copy beside the file.
3. Remember the blast radius: one stack, several accounts, including any session running at the time.
4. Stage the cuts, lowest risk first, with days of normal use between stages, because the riskiest item changes routing behaviour in a way that shows up as worse tool choices rather than as an error. That needs observation time, not a test.
5. After compressing any skill description, confirm the skill still fires on its intended phrasing before considering it done.

Limitations

• Token counts are estimates, bytes divided by 3.8, plus or minus about ten percent.
• No behavioural impact was measured. Every risk rating is reasoned from text and provenance rather than from an A/B run. A real validation would run a fixed task set against trimmed and untrimmed stacks, which is a larger job than this audit and was not done.
• The claims that the harness now covers a given rule are grounded in one session's system prompt, on one model and one CLI version. If the harness prompt changes, those claims must be re-derived, and they should not be treated as permanent.
• Usage counts conflate reference with invocation, so low counts were used only as a negative signal and cross checked against modification times, separating old and quiet from new and quiet.
• Nothing was edited. This is a proposal, so there is no confounded before and after, and also no evidence beyond reasoning that the cuts are safe.