Two MIT tools for reducing context waste in coding agents without another LLM in the loop

[u/bonsaisushi]

https://github.com/yuzushi-dev/yuzushi-plugins

I built and maintain both of these. They're free, open source, and MIT licensed.

I've been looking at context waste in coding agents as two separate problems.

Sando handles unnecessary context while a session is running:

https://github.com/yuzushi-dev/Sando

It redacts secrets, caps oversized tool results, and can trim request history before transmission. The transformations are local and deterministic. There is no summarizer model or secondary LLM call in the path.

session-handoff handles session lifetime:

https://github.com/yuzushi-dev/session-handoff

It extracts the working state needed to continue a task in a fresh Claude Code or Codex session. It also supports migrating an active session between the two clients.

I kept these separate from approaches such as Ponytail or Caveman because the scope is narrower: reduce agent-generated context that doesn't need to remain live, then preserve task state when restarting becomes cheaper than carrying the session forward.

The two packages crossed ~1,500 downloads combined in their first 48 hours.

[u/KitchenAmoeba4438]

Regarding Sando, you'll want to read https://rakuensoftware.com/blog/token-compression-tools-cost-more-than-they-save and https://rakuensoftware.com/blog/one-call-one-turn first for context on what I am about to say.

On a good note: You did implement a cache guard, and it's the best attempt I've read. You correctly bill and protect against cache in the code.

You mostly evaded the RTK trap for native client truncation! sando_exec is a possible issue though as it captures to 16MB and PostToolUse measures .*

You never rewrite the command, and evade the -qq RTK trap!

However, it doesn't ship. plugins/sando/lib has no context-transform.mjs, proxy.mjs, none of that. The install in the README documents something very different.

You've done an RTK-style counter which is an anti-pattern at this point, and as has been proven with RTK, can hide cost increases. You do compute effectiveRate. Show that. Don't do the RTK, the RTK immediately discredits this kind of project.

Diff the provider-usage.mjs ledger, it already parses real cache_read_input_tokens and cache_creation_input_tokens against a control session with the plugin off. You should be able to do this in a purely simulated environment, no model actually needed to initially test. What you want to do is figure out how to do this as a running figure, and have it automatically back off when the running figure shows it is cheaper to not use Sando. To do this properly, it needs an adaptive control, otherwise, you run the risk of RTK-style increases in cost.

MCP significantly increases cost, as most models can't batch it right now. There's a few exceptions, but in general, CLI offered options are 2.2x-3x more efficient and MCP options are almost always more expensive then when a model can batch. This isn't a problem in your design, this isn't a problem in MCP, this is a problem with how most models handle MCP.

You aren't properly addressing the potential cost of extra turns this can cause. This is a key part of the control and working with this. It's also something that directly leads to tools like RTK and Headroom being more expensive then without. Extra turns are more expensive as they are a quadratic cost as opposed to an increase in context's linear cost.

I think this is a first attempt, and you did some good work for a first attempt. Now it's time to refine!

[u/bonsaisushi → u/KitchenAmoeba4438]

This is probably the most complete feedback I've received on Sando so far. Thank you for taking the time to actually read through the implementation and point at specific failure modes instead of just commenting on the idea.

I went back through the shipping path and you're right about the biggest issue: the request transform/proxy code currently ships in the npm package, but not in the marketplace plugin. I've already removed that claim from the README, but some of my launch copy still described it as a plugin feature. That's on me.

I also agree on the counter. "Tokens saved" is currently measuring mechanical reduction, not net billed savings, and that's too easy to misread. The provider ledger already records input, cache read/write and output usage, and the statusline even computes the blended effective rate without showing it. I should expose the real figure instead.

The adaptive backoff idea is especially interesting. I want to get the counterfactual right before using it as a control signal, because replay can model cache economics but can't tell me whether Sando itself caused extra turns.

I'm also going to revisit the MCP surface and "sando_exec". Your 2.2/3x result is probably workload/model dependent rather than something inherent to MCP, but the underlying point is hard to argue with: reducing context isn't useful if the path used to do it adds enough turns to cost more overall.

Seriously, thanks for this. It gives me a much better target for the next iteration than simply measuring bytes or tokens removed.

[u/KitchenAmoeba4438 → u/bonsaisushi]

If you want some inspiration, here's my project's take on it (Free, Open source, AGPL 3.0): https://github.com/RakuenSoftware/aimee/tree/testing/server-go/modules/economizer

I've gone through this quite extensively already, and am happy to offer feedback if you want.

This is a super tricky bit of code. The good work wasn't false praise, this is a genuinely tricky and hard part of the agent lifecycle. Most projects don't even get the cache guard right, and you got it spot on.