Ogni modello dimentica — senza criterio.
Compresh dimentica in modo selettivo.
Ricostruisci il contesto invece di reinviarlo. Dai al modello una memoria, non solo una cronologia.
Numeri, non promesse
~66% di token in input in meno. Nessuna perdita di qualità misurabile.
Misurato su 360 domande e risposte reali (da thread pubblici di StackExchange), riprodotte come un'unica sessione lunga e in crescita, non un dialogo sintetico. 108 di queste fanno riferimento a turni precedenti, per testare il richiamo. Abbiamo confrontato la cronologia completa (raw) con il core di compressione open source di Compresh (tulbase).
Oltre alla compressione, il livello di memoria a pagamento (TUL 2.0) è misurato separatamente su T-bench — un benchmark di memoria episodica. Pubblichiamo solo ciò che abbiamo misurato: vedi il riepilogo qui sotto e il report completo su tulv.ing.
| Metrica | raw | tulbase |
|---|---|---|
| Token in input (totale) | 40,881,263 | 13,880,456 |
| Risparmio di token rispetto a raw | — | 66.0% |
| Token in output (totale) | 378,927 | 372,899 |
| Equivalenza rispetto al ground truth (accuratezza) | 90.0% | 87.5% |
| Coseno rispetto al ground truth (0–1) | 0.670 | 0.667 |
Cosa significano i numeri
Accuratezza — percentuale di risposte che un modello giudice indipendente ha valutato equivalenti nel significato alla risposta StackExchange accettata dall'utente.
Coseno — similarità degli embedding semantici tra la risposta e la risposta accettata (0–1; più alto significa più vicino).
Risparmio di token — riduzione dei token in input rispetto all'invio dell'intera cronologia non compressa a ogni turno.
I token in output rimangono costanti in tutti e tre i casi — la compressione non aggiunge gonfiore alle risposte.
Fedeltà — la compressione cambia raramente la risposta: tulbase eguaglia il coseno di raw (0.667 vs 0.670) e resta entro ~2.5 punti sull'equivalenza (87.5% vs 90.0%), con il 66% di token in input in meno.
Modello sotto test: GPT-5-mini. Giudice: ogni risposta è stata valutata da un modello separato (Llama 3.3 70B, tramite Groq); il coseno utilizza la similarità degli embedding di frase (all-MiniLM-L6-v2). Stesse domande e stesso system prompt in tutte e tre le esecuzioni.
Memoria episodica, misurata
Più debole è il tuo modello, più conta il livello di memoria.
Su tre modelli risponditori, lo stesso retrieval aiuta tanto più quanto più debole è il modello. Su un modello potente eguaglia la qualità del contesto completo con ~99% di token in meno; su piccoli modelli aperti aumenta nettamente l'accuratezza — e sul più economico la cronologia grezza non ci sta nemmeno, quindi il retrieval è l'unico modo per far funzionare la conversazione.
| Modello risponditore | raw | tulngin | Guadagno del retrieval |
|---|---|---|---|
| gpt-5-mini · potente | 95.5% | 98.8% | +3.3pp |
| Qwen-2.5-7B · piccolo / aperto | — | 83.2% | possibile solo con il retrieval |
| Llama-3.1-8B · piccolo / aperto | 60.2% | 82.0% | +21.8pp |
tulngin = tulbase + TUL 2.0 (in produzione; TUL 2.1 in arrivo). Token di input per probe (modello potente): 31,947 → 275 (−99.1%). Qwen raw: la cronologia lunga supera il contesto da 32k del modello, quindi il provider rifiuta la richiesta; il retrieval (~280 token) ci sta.
Lo stesso benchmark deterministico e pre-registrato — e pubblichiamo anche dove i nostri sistemi falliscono, non solo dove vincono.
T-bench v1.1 · 976 probe · gpt-5-mini, Qwen-2.5-7B, Llama-3.1-8B · dataset e harness aperti (CC BY-SA, con attribuzione). Riproducibile dal set pubblicato.
Memoria episodica, end-to-end
Recupero a contesto pieno — con una frazione dei token.
EpBench è un benchmark di memoria episodica indipendente e pubblicato (il modello di recupero di Tulving): domande con indizi su un lungo libro generato. Con lo stesso modello (gpt-5-mini) e giudice — e il punteggio proprio del benchmark — Compresh supera il recupero a contesto pieno rispondendo da una porzione mirata alla query, non l'intero libro di 196 capitoli (~103k token).
| Metodo · gpt-5-mini | Simple Recall | Contesto letto |
|---|---|---|
| raw / contesto pieno | 0.804 | 196 cap. |
| naive RAG · capitolo | 0.796 | 17 cap. |
| Compresh · TUL 2.0 | 0.828 | mirato alla query |
Benchmark indipendente e pubblicato (EpBench, libro da 200 eventi), valutato con il metodo proprio del benchmark. Stesso modello (gpt-5-mini) e giudice in tutte e tre le varianti (il nostro giudice: OpenRouter gpt-4o; il giudice del paper colloca raw a 0.830 — entro ~2 punti). Compresh è in testa nel Simple Recall — il vantaggio cresce nelle domande a più eventi — leggendo solo una porzione mirata alla query, non tutto il libro. Nell'ordine cronologico è in testa naive RAG (0.65 vs 0.44); dettaglio completo nel repository dei benchmark.
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.
Come Compresh si colloca tra gli approcci alla memoria
Questi approcci sono efficaci per ciò a cui mirano. Compresh si concentra su un asse diverso.
| Approccio | Punto di forza | Man mano che la conversazione si approfondisce |
|---|---|---|
| Memoria basata sul retrieval | Eccellente nel recuperare fatti rilevanti da grandi archivi. | Recupera blocchi corrispondenti per similarità. |
| Finestre a contesto lungo | Eccellenti quando l'intera conversazione entra nel contesto e il costo non è il vincolo. | Mantiene l'intera cronologia — il costo cresce a ogni turno. |
| Buffer di riassunto | Validi per mantenere un riassunto continuo in casi di continuità semplice. | Sostituisce il dettaglio con un riassunto continuo. |
| Compresh | Ricostruzione episodica per conversazioni che si approfondiscono — dove il costo dei token si accumula turno dopo turno. | Ricostruisce ciò che conta — il risparmio cresce con la profondità. |
Prova Compresh gratis
Una riga per integrarlo — cambia il tuo base URL, lascia tutto il resto invariato. Vedrai il risparmio sulle tue conversazioni lunghe nel giro di poche ore.
Dove siamo
Compresh ha tre pubblici principali. Siamo a fasi diverse con ciascuno.
Per chi costruisce agenti e chatbot
Se state costruendo strumenti che gestiscono conversazioni lunghe e a più turni con gli utenti — agenti, copiloti, bot di assistenza clienti — Compresh è pronto per la produzione. Cambiate il vostro base_url e le conversazioni vengono compresse automaticamente. Vedrete riduzioni significative di token nelle conversazioni profonde nel giro di poche ore.
Ciò di cui abbiamo bisogno da voi: carichi di lavoro reali. Compresh impara più velocemente dal traffico di produzione, non da benchmark sintetici.
Collegateci →Per sviluppatori RAG
La memoria episodica e la generazione aumentata da recupero condividono una domanda comune: come si seleziona ciò che è rilevante? L'approccio basato su tag di Compresh complementa RAG in alcuni flussi di lavoro e ne sostituisce parti in altri. I segnali iniziali sono promettenti.
Se state risolvendo il recupero su scala, ci piacerebbe testare la sovrapposizione insieme.
Testare la sovrapposizione →Per team che usano IA internamente
Se i vostri dipendenti usano ChatGPT, Claude o qualsiasi API LLM per il lavoro quotidiano, Compresh si inserisce davanti. Un solo cambio di base_url per sviluppatore, un master account per l'IT. Conversazioni compresse, risparmi sui system prompt condivisi, analisi d'uso per dipendente — senza cambiare il modo in cui chiunque lavora.
Ciò di cui abbiamo bisogno da voi: dimensione del team, casi d'uso principali, requisiti di conformità.
Richiedi prezzi per team →Operi su scala di piattaforma con system prompt grandi e ripetuti? Questa è una conversazione per dopo — contattaci e troveremo insieme la soluzione giusta.
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
Protocollo aperto, implementazione differenziata.
TCCP — Tag Cloud Context Protocol
Il formato di trasmissione e le convenzioni per l'identità della conversazione e la segnalazione della compressione. Chiunque può implementare un proxy o SDK compatibile con TCCP.
github.com/compreshMotore di compressione
Architettura di memoria episodica — classificazione collegata ai turni e compressione progressiva e valutata. Il tagging è un processo interno: il modello non riceve mai i tag, ma solo il contesto ricostruito che ne deriva. Domanda di brevetto depositata (TR).
È così che funzionano gli standard aperti — il protocollo è libero, la migliore implementazione compete. Guadagniamo nel modo in cui puntano i nostri incentivi: solo quando risparmi.