Edgee Claude Code Compressor V2 - Fewer tokens, same context, 50% cost reduction

Hey friends

Sacha here, founder of @Edgee.

Back in March we shipped our first compressor. One technique, tool result trimming, inspired by the RTK project. It delivered around 10% cost savings on real coding sessions. Safe, simple, limited.

Today we're launching Compression V2, and it is a different beast. 

Three orthogonal techniques, each attacking a different layer of an agent request, each toggleable independently:

1. Brevity (output layer). The model still does every tool call and produces the same final patches, it just stops narrating its plan. Output is the most expensive token class, and this is where the big 

win lives.

2. Tool surface reduction a.k.a TSR (input layer). Agents send the model the union of every MCP tool on every request, even when 95% are irrelevant. V2 runs a fast classifier that scores each tool against the task and strips the rest before the request hits the model. Your IDE still exposes everything, the model just sees a curated subset.

3. Tool result trimming (history layer, refined from V1). Cleans up the verbose tool outputs that pile up over a long session without dropping what the model needs.

Because the three touch different layers, they compose cleanly. Combined, that lands around 50% cost reduction on a typical session.

The part I am most proud of is not the number, it is how we measured it. Our research engineer @0kham ran this on SWE-bench Lite in agent mode, with paired sign tests, bootstrap confidence intervals, per-replicate cache nonces so no run gets an unfair cache advantage, and token counts read straight from the raw usage fields. We published the full methodology, including where each technique is strong and where it is modest. Brevity is ~30% median on coding, TSR is a huge token-volume win on tool-heavy MCP work, trimming compounds over long sessions. No single inflated headline number, just the decomposition and the stats behind each claim.

Full technical write-up here if you want the tests and the CIs: https://www.edgee.ai/blog/posts/introducing-compressor-v2-three-compression-layers-measured-end-to-end-for-a-50-cost-reduction

It is semantically lossless on code tasks, drop-in for Claude Code, Codex, OpenCode, Github Copilot and Cursor, with under 12ms P50 gateway overhead. Your CLAUDEmd and MCP servers stay exactly where they are.

A few questions I would love your take on:

• Which of the three techniques sounds most useful for your workflow?

• Anyone running heavy MCP setups who wants to try tool surface reduction and tell us what you see?

Will be in the comments all day. Thanks for checking it out

The 50% cost reduction claim is the kind of thing that varies a lot depending on what's actually in the context window. Conversations with heavy tool call output, long file reads, or repeated error traces compress very differently than a tidy back-and-forth session. Curious what the benchmark corpus looks like and whether that number holds on real agentic sessions rather than cleaner workloads. Also wondering whether the compression is lossy in any meaningful way, specifically whether there are cases where the model behaves differently after compression because something subtle got dropped from an earlier turn.

Coding agents are amazing until you realize how much token waste is hidden in the background. not just the actual code changes, but repeated tool context, long outputs, noisy history, and models explaining things I didn't really need explained. The TSR idea is the most interesting part for me. with more MCP tools connected, the "tool surface" can get huge very fast, and sending irrelevant tools to the model on every request feels like exactly the kind of invisible cost that compounds.

I also really respect that you published the methodology instead of just saying "up to 50% cheaper". paired tests, cache nonces, and decomposition by technique makes the claim much easier to trust. Curious how you think about the risk side of TSR. if the classifier removes a tool that would've been useful later in the task, can the agent recover, or does it need to restart with a wider tool set?

Rare to see a cost claim backed by paired sign tests and per-replicate cache nonces instead of one headline number — that got me to read the full write-up. The one thing I couldn't work out: how compression interacts with prompt-cache prefix stability. On Anthropic, a cache read costs ~1/10 of uncached input, and a long Claude Code session gets most of its economics from the prefix staying byte-stable. History-layer trimming that touches an already-sent tool result mutates the prefix and invalidates everything after it — and TSR looks like it has the same tension, since the tool block sits at the very top of the prefix, so a per-task curated subset would change the first bytes of the prompt as the task evolves. Two questions: (1) Is trimming append-only — freeze what's already been sent, compress only new turns — or re-optimized per request? (2) When you say ~50%, is that net of the lost cache discounts, or measured on uncached token counts? The nonces read like caching was deliberately neutralized — the right call for isolating each technique, but it leaves the production net effect open. Asking as squarely the target user: solo dev, long-running sessions, a bill that's mostly cache reads.

Curious how Edgee handles the “gateway” part in practice for coding agents. Is the main idea routing requests across different agent providers for cost and speed, or is it more about giving engineering teams one place to manage access and workflows? The “cheaper, faster, unstoppable” promise is clear, just wondering where the biggest control point is.

plugged it into my Claude Code setup over the weekend and actually saw the token count drop on a refactor job. nice that it just routed around my OpenAI rate limit without me even noticing.

Looks nice. How does it compare to tools like headroom? Any benchmarks?

Token compression is most valuable when it preserves the parts humans forget to restate: constraints, failed attempts, release risk, and why a decision was made. If those survive compression, this becomes more than a cost tool; it becomes a safer long-running-agent primitive.

Brevity being the biggest win makes sense to me — I notice Claude Code narrating plans I never asked for. Does suppressing that narration change how easy it is for a human to follow along mid-session, or is it only trimmed on the wire?

the TSR classifier is the clever bit — scoring every MCP tool against the task and stripping irrelevant ones before they bloat the context. how much latency does the classifier itself add on each request, and does it run per-turn or only at task start?