Edgee Claude Code Compressor V2

Nice to see actual sign tests and confidence intervals in the writeup instead of a bare headline number. Lossless trimming? Very interesting - I need to check this out!

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?

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?

If you’re using coding agents all day, them tokens add up really fast and cutting them would save a lot of money. Does the token compression ever affect the quality of the responses?

I enjoy products that improve existing tools of replacing then. how does Compression V2 perform on very long debugging sessions with repeated tool calls? Publishing those numbers could answer another important question for engineering teams.

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.

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.

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

That's clever. Does it figure out the active task on its own, or do you need to pass in context?

Me noticed the emphasis on keeping results semantically lossless. could users review before and after token reports for every session? That level of transparency might encourage wider adoption across larger engineering organizations.

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.

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.

Hey friendsSacha 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-reductionIt 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