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 8th launch from Edgee. View more
Edgee Codex Compressor V2
Launching today
We benchmarked Codex alone against Codex routed through Edgee's compression gateway on the same repo, with the same model, under the same workflow. The result: Codex + Edgee used 49.5% fewer input tokens, improved cache hit rate from 76.1% to 85.4%, and reduced total session cost by 35.6%. This post breaks down why context compression makes Codex more efficient, more frugal, and materially cheaper to run without sacrificing useful output.
Launch Team / Built With
Helicone AI
Portkey Prompt Engineering Studio
Edgee
Edgee
Hey friends !
Nicolas here, head of developper experience @Edgee
A few weeks ago we launched Compressor V2 for Claude Code, and the response blew us away. But one message kept coming back in the comments, in our DMs, and in every second issue on GitHub: "cool, now do Codex."
So we did. Today we're shipping Compressor V2 for Codex.
Codex users had a specific pain we couldn't ignore. The agent is fantastic, but sessions get expensive fast, tool outputs pile up, and the context window fills long before the task is done. Porting the compressor wasn't a copy-paste, we had to rework the pipeline around Codex's request shape, its tool protocol, and its streaming behavior. It took a proper engineering push, but it was worth it.
Same three orthogonal techniques as the Claude Code release, each attacking a different layer of an agent request, each toggleable independently:
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 biggest win lives.
Tool surface reduction a.k.a TSR (input layer). Codex sends 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. One thing that mattered a lot to us: we made it fully compatible with Codex's native search tool. That compatibility was one of the toughest parts of the port to get right, and it does mean TSR is slightly less aggressive on Codex than on Claude Code, but the tradeoff was worth it. Nothing in your normal Codex workflow breaks.
Tool result trimming (history layer). 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, we're seeing around 50% cost reduction on a typical Codex session, in line with what we measured on Claude Code.
As a reminder, our research engineer @0kham published the full methodology behind the V2 numbers, SWE-bench Lite in agent mode, paired sign tests, bootstrap CIs, per-replicate cache nonces, token counts from raw usage fields. Same rigor applied to the Codex port, write-up here if you want the details: https://www.edgee.ai/blog/posts/introducing-compressor-v2-three-compression-layers-measured-end-to-end-for-a-50-cost-reduction
Semantically lossless on code tasks, drop-in for Codex, with under 12ms P50 gateway overhead. Your AGENTS.md and MCP servers stay exactly where they are.
A few questions I would love your take on:
Codex users, which of the three techniques sounds most useful for your workflow?
Anyone running heavy MCP setups on Codex 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, and thanks to everyone who nudged us to make this happen.