Sobrevivir al pliegue: una escalera para sesiones de agentes de larga duración y la compactación.

Los montañistas no llevan toda la expedición hasta la cima; la dejan almacenada en lugares estratégicos. Una larga ascensión se divide en campamentos, cada uno provisto con lo necesario para la siguiente etapa. Todo lo que no se necesita se queda abajo, disponible en caso de que el grupo deba regresar, pero nunca se transporta más arriba. Lo que llega a la cima es lo que sobrevivió a la decisión de cada campamento sobre qué dejar atrás.

Una ventana de contexto funciona de la misma manera. La capacidad es fija, pero la ruta no; tarde o temprano hay que dejar algo atrás.

El almacenamiento temporal ya proporcionó una regla para los arneses de los agentes: nunca invalidar la caché. Mantener la parte estable activa y aplazar los cambios hasta el final. Sin embargo, esa regla trata a una sesión como una fotografía estática, cuando las sesiones tienen una dimensión temporal. Cada sesión envejece. La conversación crece hasta que la ventana se llena y debe cerrarse.

Un plegado reduce el tamaño de la ventana; esa parte es mecánica. El precio no es tan evidente, ya que el plegado obliga a invalidar la caché. Se paga una sola vez, lo que queda se vuelve a escribir y la sesión continúa. Aun así, la invalidación es un problema secundario. Lo importante real es seleccionar qué elementos sobrevivirán. Una buena compactación no consiste solo en eliminar datos: condensa un historial en una forma a partir de la cual el agente puede seguir funcionando. Además, una sesión prolongada no se pliega solo una vez; se pliega, funciona, se pliega de nuevo, y tarde o temprano se pliega aún más.

Eso reformula la pregunta sobre la planificación. Preguntar cuándo realizar la compactación tiene menos importancia que preguntar qué queda después de repetidas rondas de plegado y qué se ha perdido para entonces. El momento oportuno es un problema de costos, ya que cada invalidación se cobra. La calidad de la compresión es un problema de identidad, porque determina si la sesión posterior sigue siendo la misma que comenzó. Por ambas razones, la compactación debe estar en la cima de la jerarquía, no en la base.

Dónde se acumula la factura

Cada solicitud se divide en dos zonas de facturación. Una es el prefijo, que permanece de una ronda a otra. La otra es la cola, que sigue creciendo.

El prefijo contiene el prompt del sistema, las definiciones de herramientas, el contexto del repositorio estable y los archivos de reglas. Se escribe una sola vez, se almacena en caché y luego se vuelve a leer por una fracción pequeña del precio original. Mantiene el mismo tamaño.

La cola es todo lo que sigue: diálogo, llamadas a herramientas, sus resultados, bloques de razonamiento y diferencias. Solo se expande.

No es la expansión lo que causa problemas, sino la carga repetida. Un nuevo mensaje no viaja solo; el sistema vuelve a enviar el prefijo correspondiente, paga la tarifa por lectura almacenada y la tarifa adicional por escritura del nuevo contenido, y toda la cola se transmite con cada una de esas lecturas. Por lo tanto, 150,000 tokens de cola no son un monto inactivo que permanece en la ventana; se cobra nuevamente en cada turno, independientemente de si el modelo los necesita para la siguiente pregunta. La historia anterior queda, en efecto, arrendada durante toda la duración de la sesión.

En una ventana de 200,000 tokens, gran parte del espacio ya está ocupado. Dependiendo del sistema y varios otros factores, la cantidad realmente disponible para trabajar puede reducirse entre 7,500 y aproximadamente 15,000 tokens.

Los cachés también caducan. La actividad actualiza el tiempo de vida útil, lo que significa que una pausa puede hacer que la siguiente operación sea una escritura “fría”. El tiempo que pasa una persona pensando representa un costo oculto del caché del cual nadie habla.

Visto de esta manera, comprimir la parte final del caché también es una operación sobre él. Se paga un costo único por invalidación a cambio de poner fin al alquiler continuo. Ese es el trato completo, y existen formas más económicas de actuar antes de recurrir a ello.

Una escalera de cinco pasos

Existen cinco medidas contra el crecimiento de la parte final del caché. Son menos alternativas que los peldaños: cuanto más alto se asciende, más se perturba la historia existente.

Paso uno: nunca lo genere. Limite la salida de la herramienta. La herramienta de editor de texto de Anthropic admite max_characters y su búsqueda en la web permite establecer max_uses. Por defecto, Codex limita las salidas individuales de las herramientas a entre 10,000 y 16,000 tokens antes de que se incluyan en el cálculo de compactación. Una variante más disciplinada es el recorte: conservar el inicio y el final y eliminar la parte central, basándose en la idea de que cómo comenzó una orden y dónde terminó son más importantes que el contenido intermedio. La desventaja es que se truncan los datos antes de saber qué es relevante, y un rastro de llamadas que omita el marco correspondiente es peor que no tenerlo.

Paso dos: elimina los datos innecesarios. Si no se necesita toda la observación, no la conserves. Cuando el resultado de una herramienta supera un umbral de tamaño, el sistema lo guarda en disco y deja una referencia. El archivo completo permanece, mientras que el contexto en tiempo real no. Esto difiere de la truncación porque no se descarta nada. Un registro de compilación de 500 mil líneas puede quedar en disco, mientras que el contexto solo alberga su ruta, metadatos o un índice buscable, y posteriormente una herramienta de búsqueda o lectura recupera únicamente la parte relevante. Conserva el archivo y elimina la observación. De esta manera se separa claramente el almacenamiento del contexto, de modo que la información permanece duradera sin generar costos adicionales en etapas posteriores.

El problema es que el sistema de gestión debe ofrecer la forma de encontrarlo de nuevo. Derramar datos solo sirve de algo cuando el agente puede buscar lo que guardó, leerlo y comprenderlo; sin eso, el desbordamiento de contexto se convierte en un sistema de archivos lleno de elementos imposibles de recuperar.

La convergencia entre estos sistemas de gestión es notable. Claude Code escribe en disco cualquier resultado de herramienta que supere aproximadamente 100 k de tamaño y devuelve una vista previa junto con una ruta, mientras que Hermes aplica el mismo límite de 100 k por resultado. Ambos establecen la misma excepción para la herramienta de lectura, ya que una lectura que genera un desbordamiento solo proporciona una ruta que el agente leería una y otra vez, generando nuevos desbordamientos indefinidamente. Es fácil caer en este tipo de bucles. La única herramienta cuya función es recuperar contenido es la que nunca debe generar desbordamientos.

Tercer paso: mantenerlo fuera. Entregue el trabajo a un subagente. Equipado con las herramientas nativas del arnés, puede leer archivos, examinar registros y analizar el repositorio, acumulando un amplio contexto privado, sin que nada de eso llegue al proceso principal. Una vez completada la tarea, su ventana de ejecución se descarta y solo el valor de retorno es transmitido. Los proveedores de arneses han hecho de esta función una de las más ampliamente implementadas este año.

Existe un límite, porque explorar es más seguro que cambiar cosas. Un trabajador que lee los archivos incorrectos simplemente obliga a realizar una nueva ejecución. Un trabajador que edita los archivos equivocados deja daños una vez que su contexto ha terminado, por lo que es importante decidir qué modelo se le confía para realizar los cambios. Los ejércitos antiguos lo ilustran: los exploradores eran personas rápidas y desechables enviadas al frente, ya que observar no cuesta nada y el informe puede verificarse, mientras que la acción decisiva real se confiaba a los mejores comandantes porque no se puede revertir. La misma división se aplica aquí. Encomienda la exploración a un contexto económico y temporal, reserva el modelo más potente para el paso que modifica el mundo, y mantén al padre involucrado en la verificación. El padre paga por la respuesta y no por la investigación.

Paso cuatro: cámbielo por un puntero. Si el contenido ya está almacenado de forma duradera, ya sea como archivo, artefacto, informe generado o resultado obtenido, la conversación solo necesita una referencia a él. Volver a consultarlo implica ir al lugar donde se encuentra el material, en lugar de llevarlo consigo. La herramienta de memoria de Anthropic hace precisamente esto, y OpenAI permite un comportamiento similar mediante llamadas a funciones. El costoso estado de la conversación se convierte así en una referencia económica a un estado duradero. Hay una advertencia: el ahorro solo dura mientras el contenido subyacente permanezca fuera del alcance. Una vez vuelva a leerse, vuelve a ser contenido temporal y comienza a generar costos de inmediato.

Peldaño cinco: retíralo después. Elimina, comprime o pliega. Solo este peldaño invalida lo que ya está en caché. Se invierte un turno intercambiando la historia acumulada por algo más pequeño, con la esperanza de poder seguir a partir de ahí en el turno siguiente. La transcripción completa puede permanecer en el disco, pero el contexto en tiempo real es diferente.

A partir de aquí, la economía se convierte en una apuesta. ¿El ahorro en costos durante el resto de la sesión supera lo que cuesta ahora reescribir la historia? Comprimir temprano significa desechar un caché útil que podría haber servido para cientos de turnos económicos. Comprimir tarde implica haber pagado ya los costos por una gran cantidad de historia, durante la cual el modelo podría haber empeorado en su uso de ella. La mayoría de las conversaciones sobre sesiones largas comienzan con esta pregunta, pero no debería ser así. Los cinco peldaños en orden:

1. Nunca generarla: detén el crecimiento excesivo desde la fuente.
2. Revelarlo: sacar la observación voluminosa y conservar el artefacto.
3. Mantenerlo fuera: enviar la investigación a otro contexto.
4. Aludir a él: dejar una referencia barata en la conversación.
5. Eliminarlo más tarde: comprimir o doblar y vivir con la pérdida.

El contexto más económico no es el contexto comprimido; es el contexto que nunca hubo que incluir.

Conjuntos de herramientas como apuesta sobre dónde pagar

Es importante saber dónde se encuentra la definición de una herramienta. Las definiciones ocupan el prefijo, un costo fijo que se escribe una vez y se almacena en caché. Los resultados ocupan la parte final, un costo variable que se paga continuamente. Por lo tanto, elegir un conjunto de herramientas es una apuesta sobre qué zona debería asumir el costo de la información. Pocas herramientas significan un prefijo pequeño, pero más observaciones en bruto en la parte final; muchas herramientas implican gastar más tokens en el prefijo para obtener observaciones más pequeñas y estructuradas.

Terminus 2 representa el extremo minimalista: un terminal sin interfaz gráfica, basado en la convicción de Unix de que se puede componer una herramienta general sin límites. A menudo se lo agrupa con Codex, lo cual solo es parcialmente justo. Su prefijo nativo no es precisamente pequeño, ya que cuenta con unos 20 herramientas siempre presentes, un conjunto de herramientas multiagente y una combinación de versiones v1/v2. Evita el sobrecarga mediante la diferición, indexando las herramientas MCP y de conector en un motor de búsqueda y cargándolas cuando son necesarias. Codex apuesta realmente por lo mínimo en la parte final del proceso. apply_patch ilustra esto, ya que una pequeña diferencia entre versiones sustituye a miles de tokens de archivo reescrito, y los límites en la salida de cada herramienta impiden que se acumulen observaciones en bruto. Ambos llegan a resultados similares por rutas diferentes: Terminus 2 mantiene el prefijo pequeño, mientras que Codex mantiene la parte final pequeña.

Claude Code y Hermes destinan una mayor parte de su capacidad a herramientas especializadas que devuelven observaciones estructuradas en lugar de datos en bruto. El catálogo de Claude Code supera los 40 elementos si se incluyen LSP, modo de planificación, worktrees y cron, mientras que Hermes alcanza alrededor de 55, agrupados en conjuntos de herramientas para terminal, archivos, memoria, habilidades, delegación y más. El patrón común es que Grep devuelva coincidencias en lugar de un archivo completo: se utiliza un prefijo ligeramente más extenso para evitar miles de tokens en la parte final del resultado.

Por lo tanto, la comparación que se debe hacer no se refiere al número de herramientas. Se trata de si el gasto adicional en prefijos elimina suficiente crecimiento posterior como para retrasar el pliegue. Se trata del mismo equilibrio entre actuar con prontitud y hacerlo justo a tiempo, pero aplicado a un nivel más elevado. Anthropic lo explica claramente en su carga diferida: las definiciones de herramientas pueden descubrirse cuando se necesitan en lugar de incluirse en cada solicitud. Claude Code hace esto mediante un mecanismo ToolSearch que mantiene visibles los nombres de las herramientas diferidas y retiene los esquemas completos hasta que el modelo lo solicita, activándose automáticamente cuando las definiciones de herramientas MCP ocupan alrededor del 10 % de la ventana de contexto. Incluso el orden se elige para proteger el prefijo, ya que el orden alfabético mantiene el bloque de definiciones idéntico en bytes entre turnos y, por lo tanto, susceptible de ser almacenado en caché. El prefijo está diseñado para permanecer activo, independientemente de su tamaño.

El eje mantiene su utilidad, pero su papel cambia. No decide si compactar o no; decide cuánta historia se acumula primero. Y esa historia no es homogénea. Los resultados de búsqueda suelen poder derivarse de nuevo, pero las decisiones no. Se puede reconstruir una ruta de archivo, mientras que la razón por la que se rechazó un enfoque podría no serlo. Cuanto más tiempo dura una sesión, más costoso resulta confundir esos dos tipos de memoria.

La delegación como límite de memoria

La delegación destaca como el elemento que elimina la historia sin tocar la caché del padre, y eso vale más que un descuento en el trabajo a realizar. Un subagente tiene su propia ventana de contexto. Puede desarrollar una cola enorme, llenar la ventana, compactarse internamente y luego desaparecer, todo sin reescribir ni una palabra de la historia del padre.

Una suposición común necesita ser ajustada. Es atractivo imaginar una bifurcación del mismo modelo, en la cual un hijo hereda la cola acumulada del padre junto con su prefijo inicial. Las implementaciones que se pueden probar en su mayoría no hacen esto. Claude Code, OpenCode, Codex y Hermes inician cada uno un contexto de trabajo separado, y no una copia de toda la cola del padre. Algunos permiten utilizar un modelo diferente: Codex aplica una sobrescritura de modelo al iniciarse y Claude Code deja que cada subagente elija entre soneto, opus o haiku. Esto no es universal, ya que el delegado de Hermes no cuenta con una forma directa de cambiar de modelo. Lo que se transmite entre los diferentes entornos es el contexto separado, no la elección del modelo.

Esto indica algo más importante que simplemente dividir tareas. La “cola” del subagente puede descartarse: puede leer cuarenta archivos, analizar registros y establecer una convención de nomenclatura, y todo ese contexto desaparece mientras vuelve a aparecer un párrafo. La delegación funciona como un límite de memoria. El agente principal asigna una tarea y especifica qué se necesita, lo que equivale a una compresión realizada de antemano, ya que el subagente sabe quién leerá sus resultados y qué decisión deben respaldar. Cuando el subagente regresa, el agente principal normalmente verifica el resultado. Hacerlo requiere unos pocos pasos y es una práctica sensata.

La compactación se realiza al revés, posteriormente. Debe resumir para un lector que aún no existe, anticipándose a cualquier pregunta que pueda surgir después. La compresión previa tiene la ventaja de contar con un lector conocido. Esto da lugar a un principio de presupuestación: presupuestar para lo que se devolverá, no para el proceso en sí. Un trabajador puede gastar cientos de miles de tokens sin que ninguno de ellos se convierta en memoria padre. El texto devuelto sí se convierte en memoria. Cuatrocientos tokens de respuesta terminan en la cola del padre y se facturan en cada turno posterior, por lo que, a lo largo de una sesión larga, una diferencia bruta puede costar más que un trabajador caro que devuelva una sola oración útil. La investigación es temporal y la respuesta se convierte en historia; esa respuesta, a su vez, tendrá que sobrevivir a un proceso de plegado.

Qué ofrecen las plataformas

La plataforma del modelo determina cuánta de esta infraestructura debe construir por sí misma.

Anthropic ofrece dos tipos de ayuda dirigidos a problemas diferentes. El primero, clear_tool_uses_20250919, es preciso. Cuando el prompt supera un umbral (100 mil tokens de entrada por defecto, manteniendo los tres últimos usos de herramientas), elimina los resultados antiguos de las herramientas en el servidor y coloca un marcador de posición en cada lugar. Su opción clear_at_least distribuye el costo de invalidación al requerir que se elimine una cantidad mínima. El segundo, compact_20260112, es la herramienta más potente: realiza una resumen completo del lado del servidor que genera una nueva versión de la conversación, en lugar de hacer cortes en la existente.

Claude Code es un buen estudio de caso, ya que incluso el mecanismo de integración creado por la empresa que distribuye estas primitivas parece coordinar por sí mismo su versión /compact más pesada. Este soporte proviene del reverse engineering realizado por la comunidad, que se remonta a un único código fuente publicado en GitHub, y no de la documentación pública de Anthropic. La limpieza ligera se realiza en el servidor, mientras que la decisión sobre qué estado de conversación se mantiene es gestionada por el cliente.

OpenAI se concentra en la compresión. Su endpoint /v1/responses/compact devuelve un bloque opaco encriptado que el cliente devuelve sin examinar su contenido, en parte para evitar rutas de inyección de instrucciones mediante resúmenes manipulados que pudieran influir en pasos posteriores. No existe allí nada equivalente a una limpieza precisa, por lo que Codex debe gestionar por sí mismo el tamaño de la salida de la herramienta; además, bajo ambos enlaces existe una solución de último recurso: si la ventana sigue desbordándose, Codex descarta el elemento de historial más antiguo e intenta nuevamente.

DeepSeek ofrece una gestión de contexto mucho más limitada. Su caché de prefijos en el lado del servidor reduce los costos, pero no resuelve el problema de la ventana fija, por lo que cualquier herramienta que utilice este sistema debe manejar todo el proceso de compresión por sí misma. La herramienta oficial de DeepSeek crea uno de estos procesos sin destruir ninguna información: los eventos guardados permanecen en el registro y siguen siendo accesibles. Una interfaz de terminal de terceros que se probó omite este paso y nunca realiza la compresión de forma proactiva.

Lo importante no es la calidad del endpoint de compactación de una API en particular, sino quién es responsable de decidir qué se mantiene. Hermes es un caso límite revelador porque abarca varios proveedores y no puede asumir que alguno de ellos ofrezca las primitivas adecuadas. Por lo tanto, utiliza su propio compresor en el lado del cliente como punto de referencia, aplicando dos umbrales: el 50% según su propio sistema de contabilidad de tokens, y el 85% según una verificación más rudimentaria a nivel de gateway que detecta sesiones que crecen entre turnos mientras nadie las observa. Cada vez que el proveedor activo cuenta con una solución mejor, pospone la acción.

Ese es el diseño general adecuado. El mecanismo de integración debería encargarse de la compresión por defecto, ya que dispone de información que un servidor podría nunca ver, y transferirla a la plataforma cuando esta la haya ganado. Sea quien sea quien realice la compresión, la pregunta sigue siendo la misma: ¿qué es aceptable olvidar?

Regresando al campamento

Todo lo anterior asumió que la sesión nunca se detiene. Pero las sesiones sí se detienen: las laptops se cierran, los procesos mueren, las tareas de CI finalizan, y alguien escribe /resume con la esperanza de continuar desde donde se quedaron.

Es la orden más sencilla del día, pero conlleva el costo más elevado para reanudar la sesión. Tiene siete caracteres, incluida la barra, y su formato es similar al de /help o /clear; no requiere argumentos, no hay confirmación ni obstáculos. Nada en ella indica su costo, y la interfaz está diseñada para que volver a continuar parezca algo gratuito.

Se puede restaurar la conversación, pero no el caché. Una sesión reanudada no es un proceso que se haya pausado. El sistema reproduce el transcripción desde el disco y reconstruye el historial de mensajes, por lo que el diálogo vuelve a aparecer desde el almacenamiento, mientras que el prefijo temporal no lo hace. De esto se derivan dos costos de recuperación diferentes.

Lo primero es el dinero. La caché de prefijos de Anthropic dura cinco minutos por defecto, o una hora si se adquirió la versión de mayor capacidad, y solo la actividad la actualiza. Un estado de inactividad es el tiempo de inactividad llevado al extremo, un período en el que no existe ningún proceso. El prefijo que antes era económico vuelve a estar inaccesible, y en el turno siguiente hay que pagar el precio completo para reconstruirlo. El caso más costoso ocurre cuando se recupera una sesión que estuvo activa durante días, lo cual es una buena razón para gestionar las sesiones con cierto cuidado.

El segundo factor es la información. Cuando la transcripción es más larga que la ventana disponible, el sistema podría necesitar comprimirla antes de que se realice cualquier acción nueva. Se trata de una compresión especialmente arriesgada, ya que tiene lugar antes de que alguien pueda volver a determinar qué es importante. Una restricción que explicaría una decisión tomada nueve pasos atrás podría estar presente en la transcripción, pero faltar en la versión comprimida. El agente reanuda su funcionamiento con una ventana más pequeña y un historial creíble, que no necesariamente es el mismo que hizo que las decisiones anteriores fueran razonables.

Lo que sobrevive a un pliegue también sobrevive a un resumen, y ese es el caso más profundo en relación con un estado duradero. Las reglas de la raíz del proyecto pueden volver a cargarse desde el disco, los archivos pueden leerse de nuevo, la lista de tareas puede reconstruirse y el registro de compilación generado puede almacenarse y consultarse. Una decisión que existe únicamente en la conversación no tiene ninguna fuente externa. Si solo ha perdurado porque la transcripción la contenía, tendrá que volver a establecerse al regresar, y si el pliegue la eliminó, podría desaparecer para siempre.

Por lo tanto, la clasificación tiene en cuenta tanto la durabilidad como el precio. De lo más resistente a lo más frágil: estado que puede reconstruirse, estado externo duradero, estado de conversación en tiempo real, y luego observaciones transitorias. Cuanto más abajo se encuentre un elemento, más expuesto está a un pliegue.

Dos formas en que falla el pliegue

El proceso de plegado falla de dos maneras. La más evidente es fácil de detectar: la compresión funciona, luego una gran cantidad de resultados llena inmediatamente la ventana, el sistema vuelve a comprimir, aparecen los mismos resultados y el ciclo se repite, como si se intentara vaciar un barco mientras se le hace un agujero. Claude Code deja de intentarlo en lugar de seguir consumiendo recursos en un bucle, gracias a una lógica integrada que detecta que está atascado y no avanza. Ese es el comportamiento correcto, pero el bucle en sí es una señal de que se está utilizando el método inadecuado. Lo ideal sería que el agente retrocediera y probara otro enfoque en lugar de volver a intentar usar la misma herramienta nativa. Si un único archivo de gran tamaño sigue forzando la compresión, establecer un umbral más bajo no es la solución; lo adecuado sería leer solo un rango limitado de líneas, realizar búsquedas dentro de un ámbito restringido, dirigirse a resultados duraderos o entregar el archivo a un subagente cuya ventana sea reemplazable. Cada vez que se inicia el ajuste de compactación, pregúntese si la solución está un nivel más alto o en un enfoque completamente diferente.

La falla lenta es más sutil. La compactación pierde información, y las sesiones largas nunca se compactan solo una vez. Se compactan, trabajan, se compactan de nuevo, trabajan y se compactan una vez más: resúmenes encima de resúmenes.

Pliegues sobre pliegues

Un primer proceso de resumen puede ser excelente y, aun así, llevar a un tercer resultado deficiente. El segundo resumidor nunca ve la historia original, solo la representación elegida por el primer resumidor. El tercero no ve nada de eso, solo el veredicto del segundo sobre el veredicto del primero. Observe el efecto que esto tiene en los hechos frente a las razones. El primer proceso podría conservar “se eligió el enfoque B”. El segundo podría conservar “B es la implementación actual”. El tercero podría conservar “la implementación utiliza B”. Cada uno es cierto, pero la razón por la cual se rechazó el enfoque A ha desaparecido. El sistema no ha perdido la decisión; ha perdido lo que hacía comprensible dicha decisión, y ese es el daño específico causado por procesos de resumen superpuestos.

Qué debe sobrevivir

En diferentes sistemas, los resúmenes estructurados convergen aproximadamente en las mismas categorías:

• Intención: ¿qué se está logrando?
• Estado: ¿qué se ha aprendido o cambiado?
• Trabajo y tareas pendientes: ¿qué se ha hecho y qué queda por hacer?
• Temas abiertos: ¿qué preguntas siguen sin resolver, están restringidas o en proceso de análisis?

Las etiquetas varían entre los diferentes sistemas, pero la estructura se repite, lo que indica que se acerca al estado práctico más mínimo que debe mantener una sesión. Varios sistemas también incluyen pasos de restauración de archivos para poder volver a cargar el conjunto de trabajo después de un cierre.