Every model forgets — indiscriminately.
Compresh forgets selectively.
Reconstruct context, don't resend it. Hand the model memory, not just history.
Numbers, not promises
~66% fewer input tokens. No measurable quality loss.
Measured on 360 real-world Q&A items (from public StackExchange threads), replayed as one long, growing session — not synthetic dialogue. 108 of them refer back to earlier turns, to test recall. We compared full history (raw) against Compresh's open-source compression core (tulbase).
Beyond compression, the paid memory layer (TUL 2.0) is measured separately on T-bench — an episodic-memory benchmark. We publish only what we've measured: see the summary below and the full report at tulv.ing.
| Metric | raw | tulbase |
|---|---|---|
| Input tokens (total) | 40,881,263 | 13,880,456 |
| Token saving vs raw | — | 66.0% |
| Output tokens (total) | 378,927 | 372,899 |
| Equivalence vs ground truth (accuracy) | 90.0% | 87.5% |
| Cosine vs ground truth (0–1) | 0.670 | 0.667 |
What the numbers mean
Accuracy — share of answers an independent judge model marked equivalent in meaning to the human-accepted StackExchange answer.
Cosine — semantic-embedding similarity between the answer and the accepted answer (0–1; higher is closer).
Token saving — reduction in input tokens versus sending the full, uncompressed history every turn.
Output tokens stay flat across all three — compression adds no response bloat.
Fidelity — compression rarely changes the answer: tulbase matches raw's cosine (0.667 vs 0.670) and stays within ~2.5 points on equivalence (87.5% vs 90.0%), at 66% fewer input tokens.
Model under test: GPT-5-mini. Judge: every answer was graded by a separate model (Llama 3.3 70B, via Groq); cosine uses sentence-embedding similarity (all-MiniLM-L6-v2). Same questions and system prompt across all three runs.
Episodic memory, measured
The weaker your model, the more the memory layer matters.
Across three answerer models, the same retrieval helps more as the model gets weaker. On a strong model it matches full-context quality at ~99% fewer tokens; on small open models it lifts accuracy sharply — and on the cheapest, the raw history doesn't even fit, so retrieval is the only way the conversation runs.
| Answerer model | raw | tulngin | Retrieval gain |
|---|---|---|---|
| gpt-5-mini · strong | 95.5% | 98.8% | +3.3pp |
| Qwen-2.5-7B · small / open | — | 83.2% | feasible only w/ retrieval |
| Llama-3.1-8B · small / open | 60.2% | 82.0% | +21.8pp |
tulngin = tulbase + TUL 2.0 (live; TUL 2.1 on the way). Strong-model input tokens per probe: 31,947 → 275 (−99.1%). Qwen raw: the long history exceeds the model's 32k context, so the provider rejects it; retrieval (~280 tokens) fits.
Same deterministic, pre-registered benchmark — and we publish where our own systems fail, not only where they win.
T-bench v1.1 · 976 probes · gpt-5-mini, Qwen-2.5-7B, Llama-3.1-8B · open dataset + harness (CC BY-SA, with attribution). Reproducible from the published set.
Episodic recall, end-to-end
Full-context recall — at a fraction of the tokens.
EpBench is an independent, published episodic-memory benchmark (Tulving's model of recall): cued questions over a long generated book. With the same answerer (gpt-5-mini) and judge — and the benchmark's own scoring — Compresh edges out full-context recall while answering from a query-aware slice, not the full 196-chapter (~103k-token) book.
| Method · gpt-5-mini | Simple Recall | Context read |
|---|---|---|
| raw / full context | 0.804 | 196 ch |
| naive RAG · chapter | 0.796 | 17 ch |
| Compresh · TUL 2.0 | 0.828 | query-aware |
Independent published benchmark (EpBench, 200-event book), scored with the benchmark's own method. Same answerer (gpt-5-mini) and judge across all three arms (our judge: OpenRouter gpt-4o; the paper's own judge puts raw at 0.830 — within ~2pp). Compresh leads Simple Recall — its margin grows on multi-event questions — while reading a query-aware slice, not the whole book. On chronological ordering, naive RAG leads (0.65 vs 0.44); full per-bin + chronological breakdown in the benchmarks repo.
Holds up as the conversation grows
T-bench v1.1 · gpt-5-miniSame answerer, three conversation lengths. As history piles up, raw re-sends everything — tokens explode and accuracy slips. Compresh sends a query-aware slice: flat tokens, accuracy held.
Each benchmark reports its own correctness metric — EpBench's Simple Recall, T-bench's answer accuracy. Different names, same question: did the model get the answer right?
Token saving = Compresh vs raw input tokens; accuracy = correct answers over 976 probes. Source: T-bench v1.1, gpt-5-mini — reproducible from results/compresh/v1.1.
How Compresh fits among memory approaches
These approaches are strong at what they target. Compresh focuses on a different axis.
| Approach | Best at | As the conversation deepens |
|---|---|---|
| Retrieval-based memory | Excellent at pulling relevant facts from large stores. | Retrieves matching chunks by similarity. |
| Long-context windows | Excellent when the whole conversation fits and cost isn't the constraint. | Holds the full history — cost grows every turn. |
| Summarization buffers | Good for keeping a running gist in simple continuity. | Replaces detail with a rolling summary. |
| Compresh | Episodic reconstruction for deepening conversations — where token cost compounds turn after turn. | Reconstructs what mattered — savings grow with depth. |
Try Compresh free
One line to integrate — change your base URL, keep everything else. You'll see the savings on your own long conversations within hours.
Where we are
Compresh has three primary audiences. We're at different stages with each.
For agent and chatbot builders
If you're building tools that hold long, multi-turn conversations with users — agents, copilots, customer-service bots — Compresh is production-ready. Swap your base_url, and your conversations get compressed automatically. You'll see meaningful token reductions on deeper conversations within hours.
What we want from you: real workloads. Compresh learns fastest from production traffic, not synthetic benchmarks.
Plug us in →For RAG developers
Episodic memory and retrieval-augmented generation share a common question: how do you select what's relevant? Compresh's tag-based approach complements RAG in some workflows, replaces parts of it in others. Early signals look strong.
If you're solving retrieval at scale, we'd like to test the overlap together.
Test the overlap →For teams using AI internally
If your employees use ChatGPT, Claude, or any LLM API for daily work, Compresh fits in front. One base_url change per developer, one master account for IT. Compressed conversations, shared system-prompt savings, per-employee usage analytics — without changing how anyone works.
What we want from you: team size, primary use cases, compliance requirements.
Reach out for team pricing →Running at platform scale with large, repeated system prompts? That's a conversation for later — reach out and we'll figure out the fit together.
Integrate
Compresh fits in two ways. Pick the one that matches your environment — both run the same compression engine, only the privacy posture differs.
Drop-in proxy
Change your base_url to Compresh. Works when you control the client — OpenAI/Anthropic SDKs, raw HTTP, or IDEs that expose an API base URL setting.
- → Anthropic / OpenAI Python or JS SDK
- → Cursor, Aider, LangChain, Claude Code
- → Provider key passes through Compresh
Hook / MCP
Install a hook in your agent platform. Your provider key never leaves the machine — Compresh only sees the transcript fragment your hook reveals.
- → OpenClaw hook (live) · Claude Code hook (next)
- → Compresh-MCP runs locally
- → Provider key stays with you
Works with your stack, not instead of it. RAG brings in your docs, memory layers track who the user is, caching cuts repeat costs — Compresh handles the conversation itself. Drop it in front; the rest keep working.
Open source
Protocol open, implementation differentiated.
TCCP — Tag Cloud Context Protocol
The wire format and conventions for conversation identity and compression signaling. Anyone can implement a TCCP-compatible proxy or SDK.
github.com/compreshCompression engine
Episodic memory architecture — turn-linked classification and progressive, scored compression. The tagging is an internal process: the model never receives the tags, only the reconstructed context they produce. Patent application filed (TR).
That's how open standards work — the protocol is free, the best implementation competes. We earn the way our incentive points: only as you save.Is Compresh for you?
It earns its keep as conversations deepen — so it's built for some workloads, and honestly not for others.
- You run long, multi-turn AI agents
- You operate support bots that never reset
- You're building coding agents or copilots
- You ship a large system prompt on every call
- Your monthly LLM bill is real
- Your conversations stay under ~20–30 messages
- You're doing simple, one-shot RAG
- Your token cost is already low
Pay only on savings.
You only pay a share of the input tokens Compresh removes — no savings, no fee. Free to start, no card. And local or free models? No savings-share at all.
Bring your own provider key — you keep paying your own LLM bill; we only ever take a cut of what we save you.
See full pricing