Edgee is the gateway for your coding agents. It compresses tokens before they reach Anthropic, OpenAI, or any other LLM rrpovider (up to 50% lower cost), routes to faster or cheaper models when you want, and falls back automatically when a provider goes down or your plan hits its limit. Plus team attribution per repo and per PR.
Same Claude Code, same Codex, lower bills, no downtime.
This is the 7th launch from Edgee. View more
Edgee Claude Code Compressor V2
Launched this week
Compression V2 cuts coding-agent token bills with three techniques across two layers: sharper tool result trimming, new task-aware tool surface reduction, and output brevity. Drop-in for Claude Code, Codex, OpenCode, and Cursor. Semantically lossless.
Free
Launch Team / Built With
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?
Edgee
@sabber_ahamed Our gateway is written in Rust, and it's super fast. The full compression takes less than 50ms on average, and it's done at every turn.
@sachamorard 50ms per turn in Rust is basically invisible. do you cache the classifier scores between consecutive turns if the tool context hasn't changed?
Edgee
@sabber_ahamed We do use cache strategies on our side for different things, but not for tool results trimming as its processing is really fast.
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.
Edgee
@krekeltronics I can confirm that all useful elements survive our compression layers. Don't hesitate to test it and give us your feedback ;)
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?
Edgee
Hey @reda_roqai_chaoui . Our token compression layers are made to be as lossless as possible. Feel free to read @0kham blog post who made a lot of benchmark with SWE to evaluate our compression strategies: https://www.edgee.ai/blog/posts/introducing-compressor-v2-three-compression-layers-measured-end-to-end-for-a-50-cost-reduction
Foyer
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.
Edgee
@fberrez1 You are absolutely right. Some compression strategies (particularly Tool result trimming) vary depending on your use case.
To evaluate the effectiveness of each of our compression algorithms, @0kham used SWE Benchmark. I invite you to read his blog post which explains everything: https://www.edgee.ai/blog/posts/introducing-compressor-v2-three-compression-layers-measured-end-to-end-for-a-50-cost-reduction
That's clever. Does it figure out the active task on its own, or do you need to pass in context?
Edgee
@dhiraj_patel5 Everything happens automatically, no need to specify anything. Edgee receives the full request from the agent, processes it as a whole, then forwards it to the model. We try to make the experience as smooth as possible.
Possessions.
Looks nice. How does it compare to tools like headroom? Any benchmarks?
Edgee
@ch1rag We do not benchmark our competitors ;)
What I can tell you, however, is that we spend an enormous amount of time fine-tuning our algorithms to ensure that our compression does not trigger any additional turns, or negatively impact the efficiency of the model.
the brevity layer raises a question beyond live readability: when an agent does something wrong three sessions later and you're doing a postmortem, do you still have the verbose reasoning trace anywhere, or did it only ever exist on the wire in brief form. cost optimization and debuggability usually pull in opposite directions - would love a mode that keeps the full narration in a log for audit while only sending the brief version to the model, so you're not trading "cheaper now" for "unexplainable failure later"