The Ledger Before the Cut

Every prompt to my coding agent used to load about 242 KB of context before it read a single word I typed. A memory index alone ran 2,127 lines. Add a startup summary written for an earlier version of my setup, and the agent paid a fixed tax on every task, regardless of size.

I fixed it. The interesting part is the discipline I imposed on myself before touching anything: nothing gets removed until it is proven safe to remove, and nothing gets removed in a way I cannot undo.

Two things were fair game for cutting: what loads into every session by default, and anything that could make the agent trigger the wrong skill or the wrong policy. Two things were off limits: historical evidence and the ability to recover anything I changed. Every decision below sorts into one of those four buckets.

Snapshot first, cut second

Before I modified a single source document, I copied it. Every file about to change got a snapshot, and every snapshot got a SHA-256 checksum recorded against it. Then I built a restoration ledger: a table mapping every archived item to the active replacement now standing in for it. If I need to know what an old skill file used to say, or which memory document a new one folded in, the ledger answers it in one lookup.

A migration you cannot verify is one you cannot trust. Checksums and a ledger turn a claim into a proof.

Retire instructions, don’t rewrite them

The old global agent instruction file had accumulated years of policy, much of it now handled elsewhere or overtaken by how the agent actually works today. The obvious move is to edit it in place. I skipped that.

I retired it instead. The new global file is a short context-routing note, a pointer that sends the agent to the policy it actually needs for the task in front of it. The old instructions remain, unedited, available as optional historical reading for anyone who wants to see what the previous policy said. Nothing about it is hidden. It simply no longer loads by default.

The 242 KB tax

The largest single win was memory. A startup summary and a 2,127-line memory index loaded into every session regardless of whether the task touched any of it. I replaced both with a concise default context and a navigation index, and always-loaded memory dropped from roughly 242 KB to 5.2 KB.

The compact documents route to the full material rather than compressing it. They link directly to the full index, the raw memory files, past rollout summaries, and the observational archives recording what actually happened in earlier sessions. All of that history still exists in full. None of it loads unless the current task asks for it.

I made this argument before, from the other direction, in Every AI IDE Is Doing Context Management Wrong: the failure mode is rarely too little memory. It is memory with no routing layer, so everything loads every time and nothing gets prioritized.

Seven skills wearing the same name

Skill discovery had 117 entries, and eight of those had exact name collisions, meaning the agent could resolve one name to more than one file and pick the wrong one silently. Seven duplicate local skills caused it. I moved them out of automatic discovery while keeping the files intact, and wrote a canonical-skill document recording each one’s old location, its archive location, and the active replacement that now owns that name.

Skill discovery is down to 110 entries. Collision groups are down to six. The remaining six are a separate problem, and I am leaving them alone until I understand why they still collide.

Fifteen paths that pointed nowhere

The trusted-project configuration held fifteen records pointing at paths that no longer existed on disk. Those are unambiguous. A path either resolves or it does not, and a trust record for a path that resolves to nothing carries no offsetting value. I removed them.

Everything else in that configuration stayed exactly where it was: enabled integrations, plugin caches, active worktrees, stashes, session transcripts, backups, raw observations. None of that is provably dead the way a missing path is dead. A worktree untouched for three weeks might still be mid-task. A plugin cache might be expensive to rebuild and cheap to keep. Deleting those on a hunch trades a small, uncertain storage saving for the certainty of breaking something later. That trade costs more than it saves without real evidence that the thing is unused, and I do not have that evidence yet.

Two smaller changes

Default reasoning effort dropped from extra-high to high. Extra-high is still available. A task now has to earn it by showing it needs the depth; it is no longer the starting position for every request.

A model-benchmark skill had its entrypoint hard-coding a specific pool of providers and models. I removed the hard-coding. The entrypoint now requires a catalog refresh and live provider resolution before a benchmark run, so it can never quietly run against a stale list of models that stopped reflecting what is actually available.

Checking the work

I validated the migration on six axes: checksums against the recorded values, whether configuration loads cleanly, whether every archive reference in the new compact documents actually resolves, whether every remaining trusted path exists on disk, whether the model-bench skill reports correctly, and whether the retired policies are genuinely undiscoverable by default rather than just moved somewhere less obvious. All six passed.

What remains

There is more to consolidate. The plugin list still carries redundancy I have not touched, and some document-format skills probably overlap in ways the collision count does not fully capture. I am leaving that alone for now. Consolidating a skill correctly requires knowing how often it actually gets invoked, and I do not have that telemetry yet. Cutting on assumption is exactly the mistake this migration was built to avoid repeating. When the invocation data exists, that becomes the next pass. Until then, the ledger stays open and nothing else gets touched.

First published September 21, 2026 on 42 Insights.