Tout modèle oublie — sans discernement.
Compresh oublie de façon sélective.
Reconstruisez le contexte au lieu de le renvoyer. Donnez au modèle une mémoire, pas seulement un historique.
Des chiffres, pas des promesses
~66% de tokens d'entrée en moins. Aucune perte de qualité mesurable.
Mesuré sur 360 questions-réponses réelles (issues de fils publics StackExchange), rejouées comme une seule session longue et croissante — et non un dialogue synthétique. 108 d'entre elles renvoient à des échanges antérieurs, afin de tester le rappel. Nous avons comparé l'historique complet (raw) au cœur de compression open source de Compresh (tulbase).
Au-delà de la compression, la couche mémoire payante (TUL 2.0) est évaluée séparément sur T-bench — un benchmark de mémoire épisodique. Nous ne publions que ce que nous avons mesuré : voir le résumé ci-dessous et le rapport complet sur tulv.ing.
| Métrique | raw | tulbase |
|---|---|---|
| Tokens d'entrée (total) | 40,881,263 | 13,880,456 |
| Économie de tokens vs raw | — | 66.0% |
| Tokens de sortie (total) | 378,927 | 372,899 |
| Équivalence vs vérité terrain (précision) | 90.0% | 87.5% |
| Cosinus vs vérité terrain (0–1) | 0.670 | 0.667 |
Ce que signifient les chiffres
Précision — proportion de réponses qu'un modèle juge indépendant a estimées équivalentes en sens à la réponse StackExchange validée par l'humain.
Cosinus — similarité d'embedding sémantique entre la réponse et la réponse validée (0–1 ; plus la valeur est haute, plus c'est proche).
Économie de tokens — réduction des tokens d'entrée par rapport à l'envoi de l'historique complet et non compressé à chaque tour.
Les tokens de sortie restent stables dans les trois cas — la compression n'alourdit pas les réponses.
Fidélité — la compression modifie rarement la réponse : tulbase retrouve le cosinus de raw (0.667 contre 0.670) et reste à ~2.5 points sur l'équivalence (87.5% contre 90.0%), avec 66% de tokens d'entrée en moins.
Modèle testé : GPT-5-mini. Juge : chaque réponse a été notée par un modèle distinct (Llama 3.3 70B, via Groq) ; le cosinus repose sur la similarité d'embeddings de phrases (all-MiniLM-L6-v2). Mêmes questions et même system prompt pour les trois exécutions.
Mémoire épisodique, mesurée
Plus votre modèle est faible, plus la couche mémoire compte.
Sur trois modèles répondeurs, le même retrieval aide d'autant plus que le modèle est faible. Sur un modèle puissant, il égale la qualité du contexte complet avec ~99% de tokens en moins ; sur de petits modèles ouverts, il améliore nettement la précision — et sur le moins cher, l'historique brut ne tient même pas, si bien que le retrieval est le seul moyen de faire tourner la conversation.
| Modèle répondeur | raw | tulngin | Gain du retrieval |
|---|---|---|---|
| gpt-5-mini · puissant | 95.5% | 98.8% | +3.3pp |
| Qwen-2.5-7B · petit / ouvert | — | 83.2% | possible uniquement avec retrieval |
| Llama-3.1-8B · petit / ouvert | 60.2% | 82.0% | +21.8pp |
tulngin = tulbase + TUL 2.0 (en production ; TUL 2.1 à venir). Tokens d'entrée par probe (modèle puissant) : 31,947 → 275 (−99.1%). Qwen raw : l'historique long dépasse le contexte de 32k du modèle, donc le fournisseur rejette la requête ; le retrieval (~280 tokens) passe.
Le même benchmark déterministe et pré-enregistré — et nous publions aussi là où nos propres systèmes échouent, pas seulement là où ils réussissent.
T-bench v1.1 · 976 probes · gpt-5-mini, Qwen-2.5-7B, Llama-3.1-8B · jeu de données + harness ouverts (CC BY-SA, avec attribution). Reproductible à partir du jeu publié.
Mémoire épisodique, de bout en bout
Le rappel du contexte complet — avec une fraction des tokens.
EpBench est un benchmark de mémoire épisodique indépendant et publié (le modèle de rappel de Tulving) : des questions indicées sur un long livre généré. Avec le même répondeur (gpt-5-mini) et le même juge — et le propre barème du benchmark — Compresh dépasse le rappel en contexte complet tout en répondant à partir d'une tranche ciblée par la requête, et non le livre entier de 196 chapitres (~103k tokens).
| Méthode · gpt-5-mini | Simple Recall | Contexte lu |
|---|---|---|
| raw / contexte complet | 0.804 | 196 ch. |
| naive RAG · chapitre | 0.796 | 17 ch. |
| Compresh · TUL 2.0 | 0.828 | ciblé requête |
Benchmark indépendant et publié (EpBench, livre de 200 événements), évalué avec la propre méthode du benchmark. Même répondeur (gpt-5-mini) et même juge sur les trois variantes (notre juge : OpenRouter gpt-4o ; le juge du papier place raw à 0.830 — à ~2 points près). Compresh est en tête sur le Simple Recall — son avance grandit sur les questions à plusieurs événements — en ne lisant qu'une tranche ciblée par la requête, pas tout le livre. Sur l'ordre chronologique, naive RAG est en tête (0.65 contre 0.44) ; détail complet dans le dépôt de benchmarks.
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.
Comment Compresh se situe parmi les approches mémoire
Ces approches excellent dans leur domaine. Compresh se concentre sur un axe différent.
| Approche | Points forts | À mesure que la conversation s'approfondit |
|---|---|---|
| Mémoire par récupération | Excellente pour extraire les faits pertinents de vastes ensembles de données. | Récupère les segments correspondants par similarité. |
| Fenêtres à long contexte | Excellentes lorsque toute la conversation tient et que le coût n'est pas une contrainte. | Conserve l'historique complet — le coût croît à chaque tour. |
| Tampons de résumé | Adaptés au maintien d'une trame d'ensemble dans une continuité simple. | Remplace le détail par un résumé évolutif. |
| Compresh | Reconstruction épisodique pour les conversations qui s'approfondissent — là où le coût en tokens s'accumule tour après tour. | Reconstruit ce qui comptait — les économies croissent avec la profondeur. |
Essayez Compresh gratuitement
Une ligne à intégrer — changez votre base URL, gardez tout le reste. Vous verrez les économies sur vos propres conversations longues en quelques heures.
Où nous en sommes
Compresh s'adresse à trois publics principaux. Nous en sommes à des stades différents avec chacun.
Pour les créateurs d'agents et de chatbots
Si vous construisez des outils qui maintiennent de longues conversations multi-tours avec les utilisateurs — agents, copilotes, bots de service client — Compresh est prêt pour la production. Changez votre base_url, et vos conversations sont compressées automatiquement. Vous constaterez des réductions significatives de tokens sur les conversations profondes en quelques heures.
Ce que nous attendons de vous : des charges de travail réelles. Compresh apprend plus vite à partir du trafic de production que des benchmarks synthétiques.
Intégrez-nous →Pour les développeurs RAG
La mémoire épisodique et la génération augmentée par récupération partagent une question commune : comment sélectionner ce qui est pertinent ? L'approche par tags de Compresh complète le RAG dans certains workflows, en remplace des parties dans d'autres. Les premiers signaux sont prometteurs.
Si vous travaillez sur la récupération à grande échelle, nous aimerions tester le chevauchement ensemble.
Tester le chevauchement →Pour les équipes utilisant l'IA en interne
Si vos employés utilisent ChatGPT, Claude ou n'importe quelle API LLM pour leur travail quotidien, Compresh s'intercale en amont. Un seul changement de base_url par développeur, un seul compte maître pour l'IT. Conversations compressées, économies sur les prompts système partagés, analyses d'usage par employé — sans changer la façon dont chacun travaille.
Ce qu'il nous faut de vous : taille de l'équipe, principaux cas d'usage, exigences de conformité.
Demander des tarifs équipe →Vous opérez à l'échelle d'une plateforme avec de longs system prompts répétés ? C'est une conversation pour plus tard — contactez-nous et nous trouverons ensemble la solution adaptée.
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
Protocole ouvert, implémentation différenciée.
TCCP — Tag Cloud Context Protocol
Le format de transmission et les conventions pour l'identité de conversation et la signalisation de compression. N'importe qui peut implémenter un proxy ou un SDK compatible TCCP.
github.com/compreshMoteur de compression
Architecture de mémoire épisodique — classification liée aux tours et compression progressive et notée. Le marquage est un processus interne : le modèle ne reçoit jamais les étiquettes, seulement le contexte reconstruit qu'elles produisent. Demande de brevet déposée (TR).
C'est ainsi que fonctionnent les standards ouverts — le protocole est libre, la meilleure implémentation s'impose. Nous gagnons dans le sens où pointe notre intérêt : uniquement quand vous économisez.