I keep coming back to one small piece of the zcode-plugins bundle. There's a lot in there, Vision for models that can't read images, Headroom for request-layer history compression, a line-level code reviewer, but the part that actually changed how I think about agent plumbing is rtk: command output gets compressed 60-90% *before* it enters the conversation. A single executable, 100+ built-in filters, and the stuff that usually drowns a session, ls dumps, git status walls, build logs, gets squeezed on the way in. The plugin also keeps a way to pull the original back when the filter eats something you needed.
That recovery part is the whole game. Compression you can't undo is just data loss with extra steps.
Why this matters more than it looks
If you've watched an agent lose the plot mid-task, you've probably felt the cause without naming it. One developer's write-up of Codex nails the pattern: frequent context compaction, and once it compacts, it treats whatever it just hallucinated as the main task you asked for. Walk away, come back, and the project directory has sprouted files nobody requested, the test folder is quietly multiplying. Their take was that the model leans on dumping huge context to reason, and the compaction cycle makes it worse, not better.
You can argue about whether that's a Codex-specific quirk or a general failure mode (that's one user's experience, so treat the specifics as unverified). But the mechanism is real enough to design against: the more low-value tokens you shove into the window, the sooner you hit the compaction wall, and compaction is where drift sneaks in. A 4,000-line build log that's 95% repeated warnings isn't helping the model reason. It's just burning the budget that pushes the useful stuff out.
So the durable move isn't "compress everything." It's: decide what's noise, drop it before it lands, and keep a receipt so you can prove what you dropped.
What you can actually rebuild on VicroCode
Here's the honest shape of it, and the boundary matters so I'll put it up front. VicroCode does not run your local shell. It won't execute ls or git or your build on your machine. What it can do is host a Python service that receives text and transforms it. That's the right division of labor anyway: the agent (or your wrapper) runs the command locally, and the raw output gets handed to a filter that lives somewhere stable.
The build is small enough to describe in one breath. You run Python online as a hosted endpoint the agent calls as a tool. Request comes in with the command name and its raw stdout/stderr. Your Python picks the matching filter, collapses the noise, and returns the trimmed version plus a token count. The agent gets the short version in its context; the long version never touches the window.
Structurally that's an API Endpoint Hosting job wired into in-platform tool calls, so the agent treats "filter this output" like any other tool it can invoke. Nothing exotic. The filters themselves are just functions: a git-status filter that keeps changed paths and drops the boilerplate, an ls filter that summarizes counts instead of listing 800 files, a build-log filter that keeps errors and the first instance of each repeated warning. You don't need 100 on day one. Start with the three or four commands that actually blow up your sessions and grow from there.
The ledger is the part people skip
The reason I'd bother rebuilding this instead of just piping output through a regex is the recovery guarantee. Every filter decision goes into a SQLite row: timestamp, which command, which filter ran, how many bytes in, how many out, a hash or stored blob of the original, and a short reason for what got cut. The agent sees the compressed text with a marker like `[ref: 3f9a]`. When a filter eats something that mattered, you hand that ref back to a `recover` tool call and get the untouched original.
VicroCode gives you SQLite databases and database editing in-platform, so when a filter misbehaves you open the SQLite editor and read exactly what happened: which rule fired, how aggressive it was, what the before-and-after looked like. That's the difference between "the agent seems dumber today" and "the ls filter is collapsing a directory I needed, here's the row, let me loosen that rule." You can tune filters against real logged cases instead of guessing.
I'd resist the urge to make this clever. No ML scoring of relevance, at least not first. Deterministic filters you can read and a ledger you can audit beat a smart black box that occasionally deletes the one stack trace you needed and can't tell you why.
Where the boundary bites, and why that's fine
To say it plainly again: this trims context, it does not run the agent's local commands. If your workflow needs the agent to actually execute shell commands on your box, that still happens on your side, through whatever runner you already use. The hosted filter is a text-in, text-out service. It also can't reach into another CLI tool and intercept output automatically the way a native plugin living next to the shell can; the calling side has to send the raw text to the endpoint. That's a real limitation, not a footnote.
But I think it's a clean trade. You lose the seamless "it just happens invisibly" feel of a local plugin. You gain a filter that any agent, any machine, any teammate can call over the same endpoint, with one shared ledger showing what every session dropped. For a small team that's often the better deal, because the compression rules and the recovery history live in one inspectable place instead of scattered across everyone's laptops.
If you want it to double as a reusable tool, you can publish and share the endpoint from the platform so your whole setup points at one filter. And if you've never wired a tool call into an agent before, the AI coding material is a reasonable place to get the request/response contract straight before you start cutting filters.
One caveat worth stating: I haven't measured the 60-90% figure on my own logs, that number comes from rtk's description, and your real compression ratio depends entirely on how noisy your commands are and how hard your filters cut. Measure it with the byte counts you're already logging. The ledger you built for recovery is also your evidence for whether the whole thing is paying off.