El nuevo truco más popular en GitHub es hablar menos

El nuevo truco más popular en GitHub es hablar menos

El repositorio de más rápido crecimiento en GitHub esta semana es un proyecto de Go llamado caveman, con más de 112.000 estrellas, y toda su premisa es una broma que resulta ser cierta. Su lema dice: por qué usar muchos token cuando pocos token bastan. Es un skill y un proxy para agentes de codificación que afirma recortar el uso de tokens en torno al 65 por ciento haciendo que el modelo hable como un hombre de las cavernas.

Quita la broma y queda una afirmación de ingeniería real. La mayor parte de lo que un agente de codificación envía y recibe no es información. Es andamiaje, cortesía, repetición y los preámbulos educados que los modelos de lenguaje hacen por defecto. Si puedes desechar todo eso sin desechar el significado, la sesión sale más barata y la ventana de contexto llega más lejos.

La broma es también el diagnóstico. Cuando la jugada ganadora es hacer que el asistente suene más tonto, el cuello de botella no es la inteligencia. Es la sobrecarga.

La factura es el contexto, no el modelo

Cuesta un tiempo interiorizar cómo se encarecen de verdad las cargas de trabajo de los agentes. El modelo intuitivo dice que pagas por respuesta, así que una respuesta larga cuesta más. El modelo real es que pagas por cada token de contexto al que el modelo debe prestar atención, y ese contexto crece con cada turno.

Para cuando un agente ha leído un repositorio, ejecutado unos comandos, visto los resultados, escrito algo de código y leído los mensajes de error, la conversación es enorme. Cada turno nuevo arrastra todo el historial consigo. El décimo paso cuesta mucho más que el primero, no porque el modelo se haya vuelto más lento, sino porque carga más.

Por eso una herramienta que recorta el 65 por ciento de los tokens no es una optimización marginal. Aplicada a un agente que funciona durante horas, es la diferencia entre una sesión que cabe en un presupuesto y otra que hay que reiniciar a mitad de camino.

Tres formas de atacar el mismo problema

Los otros proyectos que cabalgan la misma ola atacan el problema desde ángulos distintos, y compararlos resulta instructivo.

Headroom, un proyecto de Python que ganó unas 13.000 estrellas en una semana hasta llegar a unas 39.000, es una capa de compresión de contexto que se ejecuta como biblioteca, proxy o servidor MCP. Ofrece seis algoritmos de compresión y afirma reducciones del 60 al 95 por ciento. La decisión de diseño importante es que es local primero y reversible, lo cual importa porque una compresión que destruye información es peor que no comprimir nada. Poder descomprimir significa que el agente todavía puede recuperar lo que enterró.

Xerj va contra un hábito concreto y muy costoso. Es una herramienta de Rust que indexa código, documentos, registros y PDF con un solo comando, para que un agente pueda consultar un índice estructurado en lugar de quemar tokens explorando con grep y sed, ese bucle de buscar, leer y volver a buscar que consume enormes cantidades de contexto a cambio de unas pocas líneas relevantes. El proyecto afirma usar unas 40 veces menos tokens que grep y se mantiene compatible con Elasticsearch, así que los clientes existentes siguen funcionando.

Pon los tres uno al lado del otro y aparece un patrón. Caveman cambia cómo habla el modelo. Headroom cambia qué se recuerda. Xerj cambia dónde mira el modelo. Los tokens ahorrados son los mismos tokens, pero la palanca es distinta, y un conjunto de herramientas maduro acaba necesitando las tres.

Por qué el truco del hombre de las cavernas funciona siquiera

El enfoque del hombre de las cavernas no debería funcionar tan bien como dicen, y vale la pena entender por qué sí funciona.

Los modelos ajustados con instrucciones están entrenados para ser útiles con un estilo concreto. Repiten tu pregunta antes de responder. Resumen lo que acaban de hacer. Explican su razonamiento en frases completas, cierran con una nota amistosa y formatean todo con encabezados. Nada de eso lo exige la tarea, y todo eso se cobra por token.

Si le indicas al modelo que abandone la cortesía y conserve solo las palabras que sostienen el sentido, obtienes una salida que parece tosca y transmite casi lo mismo. La densidad de información sube porque el ceremonial desaparece. Es la misma razón por la que una nota escueta de un ingeniero puede decir más en diez palabras que un orden del día de reunión en cien.

El equilibrio, sin embargo, es real. Una salida escueta es más difícil de hojear para una persona, y una abreviatura ambigua crea malentendidos que cuestan más de lo que ahorran. Quitar las palabras que hacen explícita la intención es una apuesta a que el contexto circundante carga suficiente significado, y esa apuesta falla justo cuando la tarea es inusual. La compresión ayuda más en el trabajo repetitivo y perjudica más donde importan los matices, una regla que vale la pena recordar antes de aplicarla en todas partes.

La oferta y la demanda de atención

Hay una razón estructural por la que esta categoría está estallando ahora, y no tiene nada que ver con ningún repositorio concreto.

Las ventanas de contexto se han vuelto grandes, pero también el apetito por llenarlas. Los agentes que leen repositorios enteros, mantienen largos historiales de tareas y coordinan subagentes consumirán todo el espacio que se les dé, porque consumir contexto es su forma de hacer las cosas. Cada aumento de capacidad se absorbe en semanas, y la presión vuelve.

Es una dinámica conocida. Ampliar las autopistas no reduce el tráfico a largo plazo, porque la gente responde a un trayecto más barato desplazándose más. Con el contexto pasa lo mismo. Una ventana más grande no acaba con la escasez, redefine qué cuenta como uso razonable, y la escasez se reafirma en un nivel superior.

Lo que significa que la compresión no es un parche. Es una capa permanente de la pila, y los proyectos que la hagan bien acabarán en una posición parecida a la de las bases de datos y las cachés: invisibles, poco glamurosos e imposibles de quitar una vez que la gente depende de ellos.

Qué hay que mirar de verdad

El número de estrellas es una mala guía aquí, porque un nombre divertido viaja más rápido que un buen algoritmo. Merece la pena comprobar tres cosas antes de adoptar cualquiera de esto.

La primera es la reversibilidad. Una compresión con pérdida que no se puede deshacer hace que los errores sean más difíciles de encontrar, porque el agente puede estar razonando a partir de un resumen que dejó caer el detalle que importaba. La segunda es dónde se aplica. Un proxy que comprime todo el tráfico sin distinción acabará tragándose algo que sostiene el sentido, y el fallo parecerá una alucinación del modelo en lugar de un error de la herramienta. La tercera es la medición. 65 por ciento menos tokens es una afirmación sobre un tipo concreto de sesión, y el único número que importa es el que se mide en tu propio tráfico.

El punto más profundo es que la industria pasó dos años persiguiendo capacidad y ahora descubre que la eficiencia es donde vive la siguiente ronda de victorias prácticas. El modelo que responde correctamente es lo mínimo. La canalización que responde correctamente por un décimo del coste es un producto. Caveman, Headroom y Xerj apuntan todos a la misma verdad: en el trabajo de agentes, la atención es el recurso escaso y todo lo demás es contabilidad.