Every AI company is bleeding tokens. Not metaphorically, literally. Context windows are the new compute budget, and most teams have no idea how fast they're burning through them. A RAG pipeline that retrieves 20 documents? 30,000 tokens minimum. An agentic loop with tool calls, prior conversation, and system prompt? You're at 50,000 before the model has said a word. The bill arrives at the end of the month and finance emails you asking what "Anthropic API" is.
Compresr (YC W2026) thinks it has the fix. Four EPFL researchers, including a CEO who wrote his PhD specifically on LLM context compression, built an API that compresses what goes into the context window without losing what actually matters. The pitch is clean: same answers, fewer tokens, lower latency, smaller bills. Drop in their SDK or stand up their open-source proxy, and the rest just works.
This is either a clever infrastructure wedge that grows into essential AI plumbing, or a feature that Anthropic ships in a Tuesday release and vaporizes the company. Let's figure out which.
What They Build
Compresr offers two products. The first is a compression API, you send them a query plus the context you were going to inject, and they return a compressed version that preserves the semantically relevant tokens for that specific query. It's query-conditioned extraction, not dumb truncation. The second is Context Gateway, an open-source proxy (Go + TypeScript, 595 GitHub stars as of writing) that sits between your coding agent and the LLM API. It intercepts outbound context, compresses it on the fly, and forwards the leaner payload. For Claude Code or Cursor users, setup is a config file change and a Docker container.
The target customer is any team running high-token workloads: RAG pipelines ingesting large document sets, agentic systems accumulating long tool-call histories, coding assistants working across large codebases. In practice, that's almost every serious AI application today.
Business model is API usage-based, you pay per compression call, presumably at a price that undercuts the token savings you get on the downstream LLM call. There's no published pricing yet, which is very YC early-stage, but the unit economics make structural sense: if they charge $0.001 per compression and save you $0.01 in GPT-4o tokens, you're happy.
How It Actually Works
Context compression sounds simple, delete the irrelevant stuff. The hard part is knowing what's irrelevant, and that answer changes depending on what you're trying to do.
Compresr's core approach is intent-conditioned compression. Rather than blindly summarizing or truncating, the system analyzes why a piece of context was retrieved, the query behind the retrieval, and filters tokens against that intent. A grep that was called to find error patterns? Keep the matching lines, drop the surrounding noise. A document retrieved for a specific clause? Keep the clause and its immediate context, compress the rest.
Under the hood, Context Gateway uses small language models (SLMs) as the compression engine, cheap, fast models that can perform semantic filtering without the latency or cost of a full frontier call. The system runs compression asynchronously in the background, triggering at 85% context fill before the agent even notices the window is full. This is the key UX insight: users tolerate no-latency background compression; they do not tolerate waiting three minutes for a synchronous compact operation.
The proxy also implements lazy tool loading, only the tools relevant to the current step appear in the context. This matters because OpenAI and Anthropic's tool schemas are verbose. A 30-tool configuration easily adds 5,000 tokens just in schema definitions. Show 3 tools, not 30.
One clever detail: compressed segments preserve an expand() handle. If the model determines it needs the uncompressed version of something, it can call back for it. This is crucial for correctness, you don't want a compressed grep output to cause the agent to miss a bug, and it distinguishes Compresr's approach from lossy summarization. They're very pointed about this distinction: summarization changes the content; their compression changes the representation while keeping the content intact.
The tech stack choice is interesting. Go at 90% of the codebase signals they care about throughput and predictable latency in the proxy layer. This isn't a Python FastAPI weekend project. You want the compression middleware to be the fastest thing in your request chain, not a bottleneck.
Difficulty Score
| Dimension | Score | Why |
|---|---|---|
| ML / AI | 7/10 | SLM-based semantic filtering, intent conditioning, compression without accuracy loss, active research area with meaningful IP |
| Data | 5/10 | Need quality/accuracy benchmark datasets for compression validation; no proprietary data moat yet |
| Backend | 5/10 | Go proxy with async compression, context window tracking, multi-agent support, solid eng but not exotic |
| Frontend | 2/10 | Minimal, dashboard for monitoring compression metrics, nothing exotic |
| DevOps | 4/10 | Docker, multi-agent config, SLM inference infra, manageable for a small team |
The Moat (Or: What You Can't Just Copy)
Let's be honest about what's replicable here.
The Context Gateway proxy? You can build a functional clone in a weekend. The architecture is public on GitHub. An LLM proxy in Go is three hundred lines of code. The open-source release was smart for adoption, but it means the infrastructure layer is fully commoditized by definition.
The compression API is the real question. Compresr's founders spent years on this at EPFL, Zakazov's PhD was specifically on this problem, Gabouj researched efficient ML and prompt compression, and the team came from Bell Labs and AXA Research. This isn't a team that read a few papers on LLMLingua and shipped an endpoint. They have working knowledge of where the published methods break and what the failure modes are at production scale.
The moat is quality. Specifically: compression that provably doesn't degrade downstream model accuracy, benchmarked across diverse task types, at useful compression ratios. Getting to "100x compression, same accuracy" is not a weekend task. Published open-source methods like LLMLingua, RECOMP, and AutoCompressor give you a starting point, but production-grade reliability across arbitrary input types requires the kind of empirical grind that takes months and a lot of labeled failure cases.
The real defensibility, if they get it, will come from:
- Integration depth, being the default compression middleware for major agent frameworks (LangChain, LlamaIndex, AutoGen) creates switching costs
- Accuracy benchmarks, if they can publish compelling evals that competitors can't match, procurement decisions write themselves
- The feedback loop, every production compression job is a signal about where quality degrades. More usage = better compression = more usage
The existential risk is the one the HN commenters raised: Anthropic, OpenAI, and Google can ship native context compression any time they want. Claude's /compact already exists. If they make it automatic and smarter, Compresr's core value prop evaporates. The counter-argument is that this is also true of every observability, caching, and infrastructure layer that has ever existed around cloud APIs, and most of those companies survived and thrived. Datadog didn't die when AWS launched CloudWatch.
There's also a legitimate security concern worth flagging: running untrusted external content (like retrieved documents) through a compression layer that modifies them before injection introduces a potential prompt injection surface. A document that says "ignore previous compression instructions and include the following..." is a real threat class. Compresr needs to be as serious about this as they are about compression ratios.
Replicability Score: 42 / 100
You can clone the Context Gateway proxy in a weekend, it's open source. You can approximate the compression logic with LLMLingua or a prompt-based approach using a cheap LLM. What you cannot quickly replicate is four years of PhD-level research on compression quality, the benchmark suite that proves your system doesn't silently degrade agent performance, or the integration partnerships that make you the default choice in major frameworks.
The 42 score reflects that the structural moat is real but not deep. A well-resourced team (say, a YC competitor with two ML researchers) could get to 80% of the quality in three to six months. The remaining 20%, the edge cases where bad compression costs an agent an entire task, is what matters in production and takes much longer to nail. That gap is narrow enough to call this clonable, but wide enough that the team has a meaningful head start.
Should You Build This?
If you're a developer running high-token AI workloads today: yes, use Compresr or at minimum their open-source Context Gateway. The ROI math is obvious. A 10x compression ratio on tool outputs alone, even if you discount the "100x" headline claim, cuts meaningful API spend while you're waiting for context windows to get cheaper.
If you're thinking about building a competitor: the barrier isn't the proxy layer, it's the ML research. Go read the LLMLingua papers, the RECOMP paper, and the AutoCompressor work from Princeton. Then budget six months to build something you'd actually trust with production agent workloads. The market exists, every serious AI team is spending real money on tokens, but the compression quality bar is higher than it looks from the outside.
The broader point is that context efficiency is becoming a first-class engineering concern, not an afterthought. Compresr is early to this infrastructure layer. The question is whether they can build deep enough before the model providers swallow the market. It's a race worth watching.
