Todo modelo olvida — sin criterio.
Compresh olvida de forma selectiva.
Reconstruye el contexto en lugar de reenviarlo. Dale al modelo memoria, no solo historial.
Números, no promesas
~66% menos tokens de entrada. Sin pérdida medible de calidad.
Medido sobre 360 elementos reales de preguntas y respuestas (de hilos públicos de StackExchange), reproducidos como una única sesión larga y creciente, no como un diálogo sintético. 108 de ellos hacen referencia a turnos anteriores, para poner a prueba la memoria. Comparamos el historial completo (raw) con el núcleo de compresión de código abierto de Compresh (tulbase).
Más allá de la compresión, la capa de memoria de pago (TUL 2.0) se mide por separado en T-bench, un benchmark de memoria episódica. Solo publicamos lo que hemos medido: consulta el resumen más abajo y el informe completo en tulv.ing.
| Métrica | raw | tulbase |
|---|---|---|
| Tokens de entrada (total) | 40,881,263 | 13,880,456 |
| Ahorro de tokens frente a raw | — | 66.0% |
| Tokens de salida (total) | 378,927 | 372,899 |
| Equivalencia frente a la verdad de referencia (precisión) | 90.0% | 87.5% |
| Coseno frente a la verdad de referencia (0–1) | 0.670 | 0.667 |
Qué significan los números
Precisión: proporción de respuestas que un modelo juez independiente marcó como equivalentes en significado a la respuesta de StackExchange aceptada por humanos.
Coseno: similitud de embeddings semánticos entre la respuesta y la respuesta aceptada (0–1; cuanto mayor, más cercana).
Ahorro de tokens: reducción en los tokens de entrada frente a enviar el historial completo y sin comprimir en cada turno.
Los tokens de salida se mantienen estables en los tres casos: la compresión no añade volumen a las respuestas.
Fidelidad: la compresión rara vez cambia la respuesta: tulbase iguala el coseno de raw (0.667 frente a 0.670) y se mantiene dentro de ~2.5 puntos en equivalencia (87.5% frente a 90.0%), con un 66% menos de tokens de entrada.
Modelo evaluado: GPT-5-mini. Juez: cada respuesta fue calificada por un modelo independiente (Llama 3.3 70B, vía Groq); el coseno usa similitud de embeddings de oraciones (all-MiniLM-L6-v2). Las mismas preguntas y el mismo system prompt en las tres ejecuciones.
Memoria episódica, medida
Cuanto más débil sea tu modelo, más importa la capa de memoria.
En tres modelos de respuesta, el mismo retrieval ayuda más cuanto más débil es el modelo. En un modelo potente iguala la calidad del contexto completo con ~99% menos tokens; en modelos abiertos pequeños eleva la precisión de forma notable — y en el más barato, el historial sin comprimir ni siquiera cabe, así que el retrieval es la única forma de que la conversación funcione.
| Modelo de respuesta | raw | tulngin | Ganancia del retrieval |
|---|---|---|---|
| gpt-5-mini · potente | 95.5% | 98.8% | +3.3pp |
| Qwen-2.5-7B · pequeño / abierto | — | 83.2% | posible solo con retrieval |
| Llama-3.1-8B · pequeño / abierto | 60.2% | 82.0% | +21.8pp |
tulngin = tulbase + TUL 2.0 (en producción; TUL 2.1 en camino). Tokens de entrada por probe (modelo potente): 31,947 → 275 (−99.1%). Qwen raw: el historial largo supera el contexto de 32k del modelo, así que el proveedor rechaza la solicitud; el retrieval (~280 tokens) cabe.
El mismo benchmark determinista y pre-registrado — y publicamos también donde nuestros propios sistemas fallan, no solo donde ganan.
T-bench v1.1 · 976 probes · gpt-5-mini, Qwen-2.5-7B, Llama-3.1-8B · dataset y harness abiertos (CC BY-SA, con atribución). Reproducible a partir del conjunto publicado.
Memoria episódica, de extremo a extremo
Recuerdo de contexto completo — con una fracción de los tokens.
EpBench es un benchmark de memoria episódica independiente y publicado (el modelo de recuerdo de Tulving): preguntas con pistas sobre un libro largo generado. Con el mismo modelo (gpt-5-mini) y juez — y la propia puntuación del benchmark — Compresh supera el recuerdo de contexto completo respondiendo desde un fragmento orientado a la consulta, no el libro entero de 196 capítulos (~103k tokens).
| Método · gpt-5-mini | Simple Recall | Contexto leído |
|---|---|---|
| raw / contexto completo | 0.804 | 196 cap. |
| naive RAG · capítulo | 0.796 | 17 cap. |
| Compresh · TUL 2.0 | 0.828 | orientado a consulta |
Benchmark independiente y publicado (EpBench, libro de 200 eventos), puntuado con el propio método del benchmark. Mismo modelo (gpt-5-mini) y juez en las tres variantes (nuestro juez: OpenRouter gpt-4o; el juez del paper sitúa raw en 0.830 — dentro de ~2 puntos). Compresh lidera en Simple Recall — su ventaja crece en preguntas de múltiples eventos — leyendo solo un fragmento orientado a la consulta, no todo el libro. En el orden cronológico, naive RAG lidera (0.65 vs 0.44); desglose completo en el repositorio 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.
Cómo encaja Compresh entre los enfoques de memoria
Estos enfoques son sólidos en aquello para lo que están diseñados. Compresh se centra en un eje distinto.
| Enfoque | Mejor en | A medida que la conversación se profundiza |
|---|---|---|
| Memoria basada en recuperación | Excelente para extraer hechos relevantes de grandes almacenes. | Recupera fragmentos coincidentes por similitud. |
| Ventanas de contexto largo | Excelente cuando toda la conversación cabe y el coste no es la restricción. | Mantiene el historial completo: el coste crece en cada turno. |
| Búferes de resumen | Útiles para mantener una idea general en continuidad simple. | Sustituye el detalle por un resumen continuo. |
| Compresh | Reconstrucción episódica para conversaciones que se profundizan, donde el coste en tokens se acumula turno tras turno. | Reconstruye lo que importó: el ahorro crece con la profundidad. |
Prueba Compresh gratis
Una línea para integrarlo: cambia tu base URL y conserva todo lo demás. Verás el ahorro en tus propias conversaciones largas en cuestión de horas.
Dónde estamos
Compresh tiene tres audiencias principales. Estamos en diferentes etapas con cada una.
Para constructores de agentes y chatbots
Si está construyendo herramientas que mantienen conversaciónes largas y de múltiples turnos con usuarios — agentes, copilotos, bots de atención al cliente — Compresh está listo para producción. Cambie su base_url y sus conversaciónes se comprimen automáticamente. Verá reducciones significativas de token en conversaciónes profundas en cuestión de horas.
Lo que necesitamos de usted: cargas de trabajo reales. Compresh aprende más rápido del tráfico de producción, no de benchmarks sintéticos.
Conéctenos →Para desarrolladores de RAG
La memoria episódica y la generación aumentada por recuperación comparten una pregunta común: ¿cómo se selecciona lo relevante? El enfoque basado en etiquetas de Compresh complementa RAG en algunos flujos de trabajo y reemplaza partes de él en otros. Las señales tempranas son prometedoras.
Si está resolviendo la recuperación a escala, nos gustaría probar la intersección juntos.
Probar la intersección →Para equipos que usan IA internamente
Si sus empleados usan ChatGPT, Claude o cualquier API de LLM para su trabajo diario, Compresh se coloca delante. Un cambio de base_url por desarrollador, una cuenta maestra para IT. Conversaciones comprimidas, ahorros en system prompts compartidos, analíticas de uso por empleado — sin cambiar la forma en que nadie trabaja.
Lo que necesitamos de usted: tamaño del equipo, casos de uso principales, requisitos de cumplimiento.
Pedir precios para equipo →¿Operas a escala de plataforma con system prompts grandes y repetidos? Esa es una conversación para más adelante: escríbenos y veremos juntos cómo encaja.
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.
Código abierto
Protocolo abierto, implementación diferenciada.
TCCP — Tag Cloud Context Protocol
El formato de transmisión y las convenciones para identidad de conversación y señalización de compresión. Cualquiera puede implementar un proxy o SDK compatible con TCCP.
github.com/compreshMotor de compresión
Arquitectura de memoria episódica: clasificación vinculada a los turnos y compresión progresiva y puntuada. El etiquetado es un proceso interno: el modelo nunca recibe las etiquetas, solo el contexto reconstruido que generan. Solicitud de patente presentada (TR).
Así funcionan los estándares abiertos: el protocolo es libre y la mejor implementación compite. Ganamos en la dirección que apunta nuestro incentivo: solo cuando tú ahorras.