100K de contexto bastan: comprime la memoria en vez de comprar una ventana más grande

La ventana no es el problema

Cada pocos meses un laboratorio saca un modelo con una ventana de contexto más grande y la conversación vuelve a empezar: doscientos mil tokens, luego un millón, luego dos millones. La promesa implícita es que la memoria es un problema de hardware y que alguien se encargará de agrandarla.

billion-context, un proyecto TypeScript de ranxianglei que lleva subiendo desde finales de septiembre, plantea lo contrario en su eslogan: con 100K de contexto basta. No "basta por ahora". Basta, si dejas de tratar la conversación como un registro al que solo se añade.

Es un proxy que se coloca entre tu agente de código y la API del modelo. Las peticiones pasan por él, se comprimen y se reenvían. Las respuestas se reescriben a la vuelta. Del modelo no cambia nada. El argumento: lo caro nunca fue el tamaño de la ventana, sino lo que nos empeñábamos en meter dentro.

Cómo funciona la compresión

El proxy analiza cada petición en formato Anthropic u OpenAI, pasa su núcleo de compresión por la conversación e inyecta cuatro herramientas que el modelo puede llamar por su cuenta: comprimir un rango de mensajes en un resumen, descomprimir un rango cuando vuelven a hacer falta los detalles exactos, buscar por palabra clave en los resúmenes comprimidos y en los mensajes visibles, y consultar el uso del contexto.

La decisión de diseño importante es que el modelo decide cuándo comprimir, no un umbral fijo. El resumidor integrado de un host suele dispararse cuando la ventana se llena y sustituye todo lo anterior a un punto de corte por un único resumen que no se puede deshacer. billion-context comprime por rangos pequeños, los mantiene reversibles y deja intacta la caché de prefijo.

Ese último punto es el detalle de ingeniería que importa. La caché de prefijo es lo que hace asequibles las sesiones largas de agente; si cada compresión reescribe el principio de la conversación, la caché falla y vuelves a pagar precio completo por todo el historial. El proyecto afirma que una sesión sana mantiene una tasa de acierto de caché de prefijo del 95-97% y que la compresión en sí no cuesta más de un 2% de sobrecarga. Son cifras suyas, y trae comandos para atribuir una caída de la tasa a una causa, normalmente la expiración del TTL de la caché aguas arriba o un cambio de modelo.

La cifra que hace creíble la promesa

Los proveedores presumen de ahorro de tokens todo el tiempo. Lo raro aquí es un estudio longitudinal que viene con el código: cuatro meses y medio, tres hosts, 174,327 llamadas al modelo, 18.76 mil millones de tokens de entrada acumulados en un solo host y unos 24.7 mil millones entre todos. El informe dice que las sesiones más largas llegaron a entre 8,584 y 12,049 llamadas, con cero violaciones de la ventana de contexto en modelos de 204,800 tokens.

Cero violaciones es la frase que importa. Significa que ninguna sesión murió porque la conversación se hiciera más grande que el modelo. Todo lo demás del estudio cuelga de ahí.

También redefine qué es una "sesión larga". Casi todo el mundo vive los límites de contexto como un deterioro lento: el agente se vuelve más vago, olvida una restricción de hace dos horas, empieza a releer archivos que ya leyó. Para cuando la ventana está realmente llena, la sesión suele llevar un rato siendo mala. Una compresión que corre de forma continua ataca el deterioro, no solo el corte seco.

Si funciona como promete en tu carga de trabajo es otra pregunta. Las cifras las reporta el propio autor, el benchmark es su propio uso, y "5 veces menos tokens" depende por completo de lo repetitivas que sean tus sesiones. Una sesión que lee cuarenta archivos y toca tres se comprime de maravilla. Una que lee un único archivo enorme y razona línea por línea tiene mucha menos redundancia que plegar.

Qué cambia en el día a día

La diferencia práctica aparece en el tramo aburrido de una tarea larga. Un agente metido en un refactor tiene tres tipos de memoria: lo que decidió, lo que leyó y lo que probó y descartó. Una transcripción en bruto mantiene los tres con la misma resolución, y por eso un refactor de cuarenta archivos llena la ventana con trazas de pila que ya no importan.

La compresión deja al agente conservar las decisiones con toda la fidelidad, plegar la evidencia en resúmenes y volver a buscar las líneas exactas solo cuando las necesita. Es más o menos como trabaja una persona: te acuerdas de que moviste la validación al middleware, no de los seis intentos que fallaron antes.

El modo de fallo es igual de humano. Si un resumen se deja fuera la única restricción que importaba, "este endpoint tiene que seguir siendo compatible hacia atrás", el agente la romperá tan contento cuarenta minutos después, y la capa de compresión te habrá ahorrado dinero a cambio de un bug. La reversibilidad es lo que hace que se pueda sobrevivir a eso: puedes descomprimir y comprobar qué decía realmente el resumen.

Por qué esto ya es una categoría

Hay al menos tres enfoques distintos compitiendo por el mismo problema. Uno es la respuesta del laboratorio: construir una ventana más grande. Otro es la del harness: recuperar en vez de recordar y mantener solo un conjunto de trabajo en el contexto. El tercero, el que representa billion-context, es conservar la conversación y comprimirla en su sitio, de forma reversible.

Los equilibrios son reales. Una ventana más grande es lo más simple y lo menos controlable; la pagas en cada llamada, sea o no relevante el historial. La recuperación es lo más barato pero pierde continuidad, porque el agente no sabe qué ha olvidado. La compresión en el sitio intenta mantener continuidad y coste a la vez, a cambio de sentarse en mitad del camino de tus peticiones.

Ese último coste es el que conviene pensar. Un proxy en medio ve cada prompt y cada completion. Para un desarrollador en solitario está bien. Para una empresa con normas de tratamiento de datos es una conversación de cumplimiento, y "hemos leído el código, está bien" no es lo mismo que una auditoría.

También está el asuntito de la licencia. El artículo técnico es MIT y vive en el repositorio. La licencia del repositorio en sí aparece como "Other" en lugar de una licencia OSI estándar. Si lo vas a desplegar dentro de una empresa, esa distinción va a salir.

La implicación incómoda

Si la compresión funciona lo bastante bien como para que 100K basten, buena parte del marketing sobre ventanas de contexto apunta a un problema que sale más barato resolver en software. Eso no vuelve inútiles las ventanas grandes, un documento de 400 páginas tiene que caber en algún sitio, pero sí significa que "tenemos un millón de tokens" es un argumento más flojo de lo que suena. Es como anunciar un depósito más grande en vez de un mejor consumo.

También cambia cómo deberías escribir un agente. Si la memoria es compresible, conviene animar al agente a anotar lo que aprende en forma estructurada, porque las notas estructuradas se comprimen mucho mejor que los registros en bruto. Una frase como "el middleware de auth lee el tenant de la cabecera, no de la cookie" vale mil líneas de traza. La capa de compresión premia la buena contabilidad, y es una propiedad agradable para una herramienta.

El proyecto pasa del millar de estrellas y ronda las 400,000 descargas mensuales en npm, con insignias para más de veinte clientes. No es una base instalada de hobby. Sugiere que el dolor es real y está muy repartido, y que la respuesta que la gente busca no es otro cero en el tamaño de la ventana.

Esa es la conclusión útil, uses la herramienta que uses al final. El contexto es un presupuesto, no un recipiente. Los equipos que lo tratan así seguirán haciendo más por dólar, y los que esperan una ventana más grande seguirán pagando por el privilegio de no decidir qué importa.