At Bridgers, we design and deploy AI solutions for our clients: conversational agents, data processing pipelines, intelligent automations. Every project confronts us with the same architectural question: how do you manage the context window when an agent chains dozens of tool calls per session? A single grep on a directory can inject 8,000 tokens into the context, 95% of which is noise. Multiply by 30 calls, and you have an agent paying a premium to be distracted. Context Gateway, the new open-source proxy from Compresr (YC W26), attacks this problem head-on. We tested it locally on our internal projects, and here is our architect's analysis.

The Context Saturation Problem in Agentic Architectures

When we build an AI agent for a client, the context question does not arrive at the end of the project. It shapes the architecture from the start. An agent that uses tools (file reads, API calls, database searches) generates a token volume that grows uncontrollably throughout the session.

The Three Degradation Vectors

Vector 1: Per-session cost. LLM providers charge per input token. A coding agent like Claude Code or Cursor, chaining file reads and grep calls, can consume 500,000 tokens in a single debugging session. With intensive daily use, the monthly bill escalates rapidly.

Vector 2: Inference latency. Transformer attention has quadratic complexity, O(n squared). Doubling the context size does not double inference time; it quadruples it. For production agents that must respond in real time, this is a wall.

Vector 3: Accuracy degradation. This is the least intuitive but most documented point. The GPT-5.4 evaluations cited by Compresr show accuracy dropping from 97.2% at 32K tokens to 36.6% at 1M tokens. Claude Opus 4.6 shows 91.9% needle-in-a-haystack retrieval at 256K, falling to 78.3% at 1M according to AIMultiple. Sonnet 4.6 goes from 90.6% at 256K to 65.1% at 1M.

The counterintuitive conclusion: sending more context to the model degrades its performance. Relevant information drowns in noise, and the model loses retrieval capability.

The Concrete Impact on a Client Deployment

Take a typical case we encounter at Bridgers. A client asks us to build a technical support agent that queries a 50,000-page knowledge base. The RAG pipeline retrieves relevant chunks, but each chunk is 2,000 tokens, and the retriever returns 10 per query. At 20,000 tokens of RAG context per call, plus system prompt and history, the window saturates before the tenth iteration.

Without intelligent context management, there are two options: truncate brutally (and lose information) or pay full price (and accept accuracy degradation). Neither is satisfactory.

[Infographic suggestion: architecture diagram showing progressive context saturation in an agentic session, with the signal-to-noise ratio degrading. Bridgers colors: #E02020, #2872E0, #2FA830.]

Context Gateway Architecture: The Transparent Go Proxy

The Processing Flow

``` [Agent: Claude Code / Cursor / OpenClaw / Codex]

|

| HTTP request (tool output in body) v [Context Gateway Proxy, local Go binary]

  1. Intercept outgoing request

  2. Extract tool output from payload

  3. Run Compresr SLM classifier (intent-conditioned)

  4. Replace output with compressed version

  5. Store original in local session store

|

| Modified HTTP request (compressed payload) v [LLM API: Anthropic / OpenAI / etc.]

Background thread:

  • Monitor context window usage

  • At 85% capacity: summarize conversation history

  • Store summary, swap in on next turn

  • Log to logs/history_compaction.jsonl

```

SLM Classifier Compression: Not Summarization

The key architectural distinction: Compresr does not use summarization. Their small language models (SLMs) function as binary classifiers at the token level. For each token in the tool output, the SLM decides: relevant or not relevant, based on the intent of the call.

This approach has three important architectural properties:

Structure preservation. Since there is no text generation, the structure of the original output (indentation, variable names, file paths, error messages) is preserved. A summary would lose this structure.

Intent conditioning. Compression is not uniform. If the agent called grep to search for authentication patterns, the SLM retains lines matching that pattern and eliminates irrelevant results. The same file will be compressed differently depending on the query.

Minimal overhead. A classifier is fundamentally less expensive than an autoregressive generator. No beam search, no sampling, no tokens generated one by one. Compression adds a few milliseconds, not seconds.

The Three Compression Models

Compresr exposes three models through its API, each suited to a different architectural pattern:

Model

Granularity

Target Architecture

espresso_v1

Token-level, agnostic

System prompt compression, static documentation. No query needed.

latte_v1

Token-level, query-conditioned

RAG pipelines, Q&A. Compression depends on the question asked.

coldbrew_v1

Whole chunk

Coarse filtering. Keep or drop complete chunks. Useful as a pre-filter before finer RAG.

For architects designing RAG pipelines, coldbrew_v1 as a first pass followed by latte_v1 on retained chunks is an interesting combination that balances efficiency and precision.

expand(): On-Demand Retrieval

The proxy stores all original tool outputs in a local session store. If the LLM realizes it needs information that was compressed away, it calls expand() to retrieve the full version.

This is the equivalent of a cache mechanism with lazy loading: the compressed version is the default representation, and the full version loads on demand. The architecture assumes the model can detect when it lacks information, which is a reasonable but not guaranteed assumption in deep agentic chains.

Session Management and Observability

Beyond compression, Context Gateway provides operational features that native tools do not offer:

  • Background history compaction: at 85% capacity, without blocking the session (unlike Claude Code's native /compact which blocks for approximately 3 minutes)

  • Web dashboard: tracking current and past sessions (the TypeScript frontend is 6.5% of the codebase)

  • Spend caps: configurable token limits per session, essential for production agents where a runaway agent can generate unexpected bills

  • Slack notifications: alerts when the agent is waiting for user input

  • Auditable logs: all compaction events recorded in logs/history_compaction.jsonl

  • Docker support: Dockerfile included for containerized deployment

For an agency like Bridgers managing agents for clients, spend caps and monitoring are non-negotiable features.

[Infographic suggestion: detailed architecture diagram of the Agent → Proxy → LLM flow with internal components (SLM, session store, background compaction, dashboard). Bridgers colors.]

Performance: What the Numbers Say (and What They Do Not)

The metrics announced by Compresr must be read with discernment.

Metric

Value

Source

Real-World Context

Max compression

200x

Aggressive latte_v1 mode, targeted RAG only

Cost reduction

76%+

Favorable scenario

Latency reduction

30%

Demo scenario

Default proxy ratio

0.5

50% reduction, this is the realistic figure

YC headline

100x

Marketing number

Our architect's reading. The default ratio of 0.5 (50% reduction) is the figure to use for capacity planning. The 200x is an extreme case on a highly targeted RAG workload. The FinanceBench benchmark (141 questions across 79 SEC documents up to 230K tokens) is interesting but references "GPT-5.2," which, as the YC Tier List analysis noted, does not match known OpenAI model naming, which "undermines credibility."

For client deployments, we recommend planning for 40 to 60% token reduction, not the marketing figures. That is still a significant gain.

The Compresr Team: Academic Pedigree That Matters

Founder

Role

Technical Background

Ivan Zakazov

CEO

EPFL PhD on LLM context compression, ex-Microsoft Research, EMNLP-25 and NeurIPS-24 publications

Oussama Gabouj

CTO

EPFL dLab research, ex-AXA, EMNLP 2025 paper on prompt compression

Berke Argın

CAIO

EPFL CS, ex-UBS

Kamel Charaf

COO

EPFL Data Science Masters, ex-Bell Labs

The CEO and CTO have publications at top-tier conferences (EMNLP, NeurIPS) on exactly the subject of their startup. This is a strong signal for architects evaluating the technical soundness of a tool. The GitHub repository shows 412 stars, 34 forks, and 12 releases in 5 weeks, a development pace indicative of an engaged team.

Technical Comparison: Context Gateway, LLMLingua, Google ADK

For an architect choosing a context management strategy, here is a comparison of available approaches.

Proxy vs. Native Framework vs. Research Library

Criterion

Context Gateway

Google ADK Compaction

Microsoft LLMLingua

Claude /compact

Type

Local Go proxy

Framework flag

Python library

Native command

Compression

SLM classifier

LLM-based summary

Perplexity-based pruning

LLM-based summary

Typical ratio

50% (fixed)

Variable

Up to 20x

Variable

Blocking

No

No

N/A (library)

Yes (3 min)

expand()

Yes

No

No

No

Dashboard

Yes

No

No

No

Spend caps

Yes

No

No

No

Agent-agnostic

Yes

ADK only

N/A

Claude only

Open source

Apache 2.0

Yes

MIT

No

Emerging Competitors

The Token Company (YC W26) is building an ML model that compresses LLM inputs before they reach the model. Also YC W26, but focused on general prompt compression rather than a proxy architecture.

The Sentinel paper (arXiv 2026) proposes attention probing for context compression, achieving 5x compression on LongBench with a 0.5B parameter proxy model. No production release, but an indicator that the research frontier is advancing quickly.

The Commoditization Risk

The skepticism expressed on Hacker News (85 points, 49 comments) is architecturally legitimate. The YC Tier List analysis summarizes the risk: "Microsoft Research already ships LLMLingua, and any major LLM provider can internalize compression natively, making this a feature rather than a company."

Commenter @verdverm on HN noted that Google ADK already handles compaction with a simple compaction_interval flag. @kuboble predicted Claude Code would solve the problem itself within months.

This is a real risk. But it is also an argument for the short-term value: as long as native solutions remain coarse (Claude Code's /compact blocks for 3 minutes), a transparent proxy has its place.

Integrating Context Gateway Into an Existing Architecture

Scenario 1: Development Agent (Claude Code / Cursor)

The simplest integration. One-command installation:

``bash curl -fsSL https://compresr.ai/api/install | sh context-gateway ``

The TUI wizard configures the agent, summarizer model, compression threshold, and optional Slack webhook. The proxy runs locally and intercepts requests transparently.

Scenario 2: Production RAG Pipeline

For a RAG pipeline, the Python SDK (pip install compresr) is more appropriate than the proxy. You integrate compression directly into your code:

  • coldbrew_v1 as a first pass to filter irrelevant chunks

  • latte_v1 as a second pass to compress retained chunks at the token level

Scenario 3: Custom Agent with Custom Tools

The proxy's custom mode allows configuring any agent that communicates with an OpenAI-compatible API. The proxy is model-agnostic: it works with Anthropic, OpenAI, or any compatible endpoint.

Architectural Limitations to Anticipate

After testing Context Gateway on our internal projects at Bridgers, here are the limitations we identified that every architect should anticipate.

Prompt cache invalidation. If you use Claude with prompt caching, each compaction changes the context prefix. The cache is invalidated, and you pay full price for the complete history. On workflows that rely heavily on caching, this can negate the compression savings. This is a critical technical point raised on Hacker News.

The fixed ratio does not adapt to content. The 0.5 ratio applies uniformly. A block of structured JSON and a verbose 500-line log receive the same treatment. The team is working on differential structured/unstructured treatment, but it is not yet available.

expand() reliability in deep chains. The expand() mechanism assumes the model detects when it lacks information. In an agentic chain with 15 successive tool calls, this assumption is fragile. A token removed at turn 3 may be needed at turn 12 without the model realizing it.

Security surface. The proxy handles all API keys and all network traffic from the agent. Version 0.4.4 introduced security hardening and OAuth support, implying earlier versions had gaps. For client deployments, a security audit is essential.

Early-stage product. Four founders, 52 commits, version 0.5.2 as of March 12, 2026. The product works, but enterprise hardening is in progress. It is too early to recommend to clients requiring an SLA.

No independent benchmarks. Performance numbers come exclusively from Compresr. No third-party benchmark validates the claims. The "GPT-5.2" reference in website benchmarks remains unexplained.

Who Should Consider Context Gateway?

For your projects if:

  • You are building agents that consume heavy token volumes via tools and your LLM bill is a significant cost item.

  • You need monitoring and spend caps for production agents, and native tools do not provide them.

  • You manage RAG pipelines with large documents and want to optimize the cost-to-accuracy ratio.

  • You are looking for an alternative to Claude Code's blocking compaction to improve developer experience.

It is premature if:

  • Your agent usage is light and token costs are negligible.

  • You operate in the Google ADK ecosystem, which already offers native compaction.

  • Security and compliance require a full audit before any network intermediary, and the product does not yet have the maturity to pass one.

  • You prefer to wait for LLM providers to natively integrate performant context management.

Agency Perspective: Context Management as an Infrastructure Layer

At Bridgers, we are observing a paradigm shift in AI agent architecture. Context management is moving from "implementation detail" to "infrastructure layer." The signals are clear: Google ADK adds compaction as a native flag, Kubernetes forms an AI Gateway Working Group, and multiple YC W26 startups are building products dedicated to this layer.

Context Gateway is one of the first open-source tools to offer an operational solution to this problem. With 412 GitHub stars, 12 releases in 5 weeks, and a team of researchers published at EMNLP and NeurIPS, it is a serious tool that deserves evaluation by any team building AI agents in production.

The strategic question remains open: will this compression layer become a standalone product or a native provider feature? The answer will determine Compresr's long-term viability. In the meantime, for architects facing the problem today, Context Gateway offers a concrete, testable, and open-source solution.

Want to automate?

Free 30-min audit. We identify your 3 AI quick wins.

Book a free audit →
Share