Jedes Modell vergisst — wahllos.
Compresh vergisst selektiv.
Kontext rekonstruieren, nicht erneut senden. Gib dem Modell Gedächtnis, nicht nur Historie.
Zahlen statt Versprechen
~66% weniger Input-Tokens. Kein messbarer Qualitätsverlust.
Gemessen an 360 realen Q&A-Beispielen (aus öffentlichen StackExchange-Threads), abgespielt als eine einzige lange, wachsende Session — kein synthetischer Dialog. 108 davon beziehen sich auf frühere Turns, um den Recall zu testen. Wir haben den vollständigen Verlauf (raw) mit dem quelloffenen Kompressionskern von Compresh (tulbase) verglichen.
Über die Kompression hinaus wird die kostenpflichtige Memory-Ebene (TUL 2.0) separat auf T-bench gemessen — einem Benchmark für episodisches Gedächtnis. Wir veröffentlichen nur, was wir gemessen haben: siehe die Zusammenfassung unten und den vollständigen Bericht auf tulv.ing.
| Metrik | raw | tulbase |
|---|---|---|
| Input-Tokens (gesamt) | 40,881,263 | 13,880,456 |
| Token-Einsparung gegenüber raw | — | 66.0% |
| Output-Tokens (gesamt) | 378,927 | 372,899 |
| Äquivalenz gegenüber Ground Truth (Genauigkeit) | 90.0% | 87.5% |
| Cosinus gegenüber Ground Truth (0–1) | 0.670 | 0.667 |
Was die Zahlen bedeuten
Genauigkeit — Anteil der Antworten, die ein unabhängiges Judge-Modell als sinngemäß äquivalent zur vom Menschen akzeptierten StackExchange-Antwort einstufte.
Cosinus — semantische Embedding-Ähnlichkeit zwischen der Antwort und der akzeptierten Antwort (0–1; höher ist näher).
Token-Einsparung — Reduktion der Input-Tokens gegenüber dem Senden der vollständigen, unkomprimierten Historie in jedem Turn.
Die Output-Tokens bleiben über alle drei hinweg konstant — Kompression erzeugt keinen aufgeblähten Antworttext.
Fidelity — Kompression ändert die Antwort nur selten: tulbase erreicht den Cosinus-Wert von raw (0.667 vs. 0.670) und bleibt bei der Äquivalenz innerhalb von ~2.5 Punkten (87.5% vs. 90.0%), bei 66% weniger Input-Tokens.
Getestetes Modell: GPT-5-mini. Judge: Jede Antwort wurde von einem separaten Modell bewertet (Llama 3.3 70B, über Groq); Cosinus nutzt Satz-Embedding-Ähnlichkeit (all-MiniLM-L6-v2). Dieselben Fragen und derselbe System-Prompt über alle drei Durchläufe hinweg.
Episodisches Gedächtnis, gemessen
Je schwächer dein Modell, desto wichtiger ist die Memory-Ebene.
Über drei Antwortmodelle hinweg hilft dasselbe Retrieval umso mehr, je schwächer das Modell ist. Bei einem starken Modell erreicht es die Qualität des vollen Kontexts bei ~99% weniger Tokens; bei kleinen offenen Modellen hebt es die Genauigkeit deutlich — und beim günstigsten passt der rohe Verlauf nicht einmal hinein, sodass Retrieval die einzige Möglichkeit ist, das Gespräch überhaupt laufen zu lassen.
| Antwortmodell | raw | tulngin | Retrieval-Gewinn |
|---|---|---|---|
| gpt-5-mini · stark | 95.5% | 98.8% | +3.3pp |
| Qwen-2.5-7B · klein / offen | — | 83.2% | nur mit Retrieval möglich |
| Llama-3.1-8B · klein / offen | 60.2% | 82.0% | +21.8pp |
tulngin = tulbase + TUL 2.0 (live; TUL 2.1 unterwegs). Input-Tokens pro Probe (starkes Modell): 31,947 → 275 (−99.1%). Qwen raw: der lange Verlauf überschreitet das 32k-Kontextfenster des Modells, daher lehnt der Anbieter die Anfrage ab; Retrieval (~280 Tokens) passt.
Derselbe deterministische, vorab registrierte Benchmark — und wir veröffentlichen auch dort, wo unsere eigenen Systeme versagen, nicht nur, wo sie gewinnen.
T-bench v1.1 · 976 Probes · gpt-5-mini, Qwen-2.5-7B, Llama-3.1-8B · offener Datensatz + Harness (CC BY-SA, mit Namensnennung). Reproduzierbar aus dem veröffentlichten Set.
Episodische Erinnerung, Ende-zu-Ende
Recall wie mit vollem Kontext — mit einem Bruchteil der Tokens.
EpBench ist ein unabhängiger, veröffentlichter Benchmark für episodisches Gedächtnis (Tulvings Modell des Erinnerns): Hinweisfragen über ein langes generiertes Buch. Mit demselben Modell (gpt-5-mini) und Judge — und der eigenen Bewertung des Benchmarks — übertrifft Compresh den Voll-Kontext-Recall, während es aus einem abfragebezogenen Ausschnitt antwortet, nicht aus dem ganzen 196-Kapitel-Buch (~103k Tokens).
| Methode · gpt-5-mini | Simple Recall | Gelesener Kontext |
|---|---|---|
| raw / voller Kontext | 0.804 | 196 Kap. |
| naive RAG · Kapitel | 0.796 | 17 Kap. |
| Compresh · TUL 2.0 | 0.828 | abfragebezogen |
Unabhängiger, veröffentlichter Benchmark (EpBench, Buch mit 200 Ereignissen), bewertet mit der eigenen Methode des Benchmarks. Gleiches Modell (gpt-5-mini) und gleicher Judge in allen drei Varianten (unser Judge: OpenRouter gpt-4o; der eigene Judge des Papers setzt raw auf 0.830 — innerhalb von ~2 Punkten). Compresh führt beim Simple Recall — der Abstand wächst bei Fragen mit mehreren Ereignissen — und liest dabei nur einen abfragebezogenen Ausschnitt statt des ganzen Buchs. Bei der chronologischen Reihenfolge führt naive RAG (0.65 vs. 0.44); vollständige Aufschlüsselung im Benchmark-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.
Wie sich Compresh unter den Memory-Ansätzen einordnet
Diese Ansätze sind stark in dem, worauf sie abzielen. Compresh konzentriert sich auf eine andere Achse.
| Ansatz | Am besten geeignet für | Während die Konversation tiefer geht |
|---|---|---|
| Retrieval-basierter Memory | Hervorragend darin, relevante Fakten aus großen Speichern zu ziehen. | Ruft passende Chunks anhand von Ähnlichkeit ab. |
| Long-Context-Fenster | Hervorragend, wenn die gesamte Konversation hineinpasst und Kosten nicht die Einschränkung sind. | Hält die vollständige Historie — die Kosten wachsen mit jedem Turn. |
| Summarization-Buffer | Gut, um in einfacher Kontinuität eine laufende Zusammenfassung zu behalten. | Ersetzt Details durch eine fortlaufende Zusammenfassung. |
| Compresh | Episodische Rekonstruktion für sich vertiefende Konversationen — wo die Token-Kosten Turn für Turn anwachsen. | Rekonstruiert, was wichtig war — die Einsparungen wachsen mit der Tiefe. |
Compresh kostenlos testen
Eine Zeile zur Integration — ändere deine base URL, lass alles andere unverändert. Du siehst die Einsparungen bei deinen eigenen langen Konversationen innerhalb von Stunden.
Wo wir stehen
Compresh hat drei primäre Zielgruppen. Wir sind bei jeder in einem anderen Stadium.
Für Agent- und Chatbot-Entwickler
Wenn Sie Tools bauen, die lange, mehrstufige Gespräche mit Nutzern führen — Agents, Copilots, Kundenservice-Bots — ist Compresh produktionsbereit. Tauschen Sie Ihre base_url, und Ihre Gespräche werden automatisch komprimiert. Sie werden bei tieferen Gesprächen innerhalb von Stunden spürbare Token-Einsparungen sehen.
Was wir von Ihnen brauchen: echte Workloads. Compresh lernt am schnellsten aus Produktions-Traffic, nicht aus synthetischen Benchmarks.
Jetzt einbinden →Für RAG-Entwickler
Episodisches Gedächtnis und Retrieval-Augmented Generation teilen eine gemeinsame Frage: Wie wählt man aus, was relevant ist? Compreshs tag-basierter Ansatz ergänzt RAG in manchen Workflows, ersetzt Teile davon in anderen. Erste Signale sind vielversprechend.
Wenn Sie Retrieval im großen Maßstab lösen, würden wir die Überschneidung gern gemeinsam testen.
Überschneidung testen →Für Teams, die KI intern nutzen
Wenn Ihre Mitarbeiter ChatGPT, Claude oder eine LLM-API für die tägliche Arbeit nutzen, fügt sich Compresh davor ein. Eine base_url-Änderung pro Entwickler, ein Master-Konto für die IT. Komprimierte Gespräche, geteilte System-Prompt-Einsparungen, Nutzungsanalysen pro Mitarbeiter — ohne die Arbeitsweise zu ändern.
Was wir von Ihnen brauchen: Teamgröße, primäre Anwendungsfälle, Compliance-Anforderungen.
Team-Preise anfragen →Läuft bei dir auf Plattform-Maßstab mit großen, wiederkehrenden System-Prompts? Das ist ein Thema für später — melde dich, und wir finden gemeinsam die passende Lösung.
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
Protokoll offen, Implementierung differenziert.
TCCP — Tag Cloud Context Protocol
Das Datenformat und die Konventionen für Gesprächsidentität und Komprimierungssignalisierung. Jeder kann einen TCCP-kompatiblen Proxy oder SDK implementieren.
github.com/compreshKompressions-Engine
Episodische Memory-Architektur — turn-verknüpfte Klassifizierung und progressive, bewertete Kompression. Das Tagging ist ein interner Prozess: Das Modell erhält nie die Tags, sondern nur den daraus rekonstruierten Kontext. Patentanmeldung eingereicht (TR).
So funktionieren offene Standards — das Protokoll ist frei, die beste Implementierung setzt sich durch. Wir verdienen so, wie unser Anreiz ausgerichtet ist: nur, wenn du sparst.