Cómo funciona el auto-compact en cinco agentes de código

¿Qué hace un agente de programación cuando se llena la ventana de contexto?

La ventana de contexto es todo el texto que un modelo puede leer en una sola petición: tus mensajes, las respuestas del agente, los archivos leídos, la salida de los comandos, los archivos de reglas y las instrucciones del sistema. Un agente de programación vuelve a enviar todo eso al modelo en cada paso, así que en una sesión larga la ventana acaba llenándose. En el artículo sobre prompt caching explicamos cómo la caché abarata esa repetición; este artículo cuenta qué pasa cuando la ventana se llena.

Hay un problema incluso antes de que se llene. La documentación de Anthropic sobre compaction explica sin rodeos por qué se resume: cuanto más larga es una conversación, peores son las respuestas, así que hay que mantener pequeño el contexto activo. Es decir, un agente no resume la conversación solo para no dar un error, sino también para seguir trabajando bien.

Cuando la ventana se va llenando, un agente tiene cuatro opciones:

Donde mejor se explican estas opciones es en la documentación de la API de Anthropic. La función de context editing borra los resultados antiguos de las herramientas, empezando por el más antiguo, y pone en lugar de cada uno un texto corto que dice que se ha eliminado. Con la configuración por defecto, la limpieza empieza cuando una petición supera los 100.000 tokens, y los últimos 3 usos de herramientas se quedan como están. Compaction, en cambio, sustituye los turnos antiguos por un resumen que Claude escribe en el servidor.

Las herramientas de programación combinan estas opciones. Claude Code primero limpia la salida antigua de las herramientas y, si aun así falta espacio, resume la conversación. Copilot CLI escribe en un archivo temporal la salida de una herramienta que supere 20 KiB; al modelo solo le llegan la ruta del archivo y una vista previa. Cursor también escribe en un archivo la salida larga del shell y de MCP en lugar de cortarla, y el agente lee el resto del archivo si lo necesita; Cursor lo contó en un artículo de enero de 2026.

Descartar los mensajes más antiguos, en cambio, no aparece como opción por defecto en la documentación de ninguna de las cinco herramientas; todas describen el resumen. La documentación de Copilot explica también por qué: sin resumen, los mensajes antiguos se borrarían sin dejar ningún registro y Copilot no podría saber qué había en ellos.

¿Cómo funciona el auto-compact en las cinco herramientas?

Las cinco herramientas resumen la conversación por su cuenta y ofrecen un comando para hacerlo a mano. Se diferencian en cuándo empieza el resumen, en qué se puede configurar y en lo que cambió en los dos últimos meses. Leímos los datos de la tabla en la documentación y las notas de versión de cada herramienta el 20 de octubre de 2026:

Fuente: documentación y notas de versión de cada herramienta, 20 de octubre de 2026. «La documentación no lo dice»: en las páginas que leímos ese día no encontramos ninguna frase que lo diga. «—»: en las notas de versión que leímos no encontramos ningún cambio de estos meses. La versión de la CLI de Cursor es la fecha en que salió. A la aplicación de escritorio de Antigravity, /compact llegó con la versión 2.24.0 (15 de octubre). Los dos cambios de Codex llegaron con las versiones 0.162.0 y 0.163.0.

Claude Code expresa el umbral en tokens, no en porcentaje. Según la documentación, si no has fijado un umbral, la conversación se resume cuando llega al límite de contexto del modelo; en modelos con ventana de 1M tokens, eso ocurre antes de que se llene la ventana, hacia los 967 mil tokens. Si quieres que resuma antes, escribe un comando como /autocompact 500k; el valor se guarda en tus ajustes para ese modelo. Desde la versión 2.1.299 (14 de octubre) existe también el resumen por inactividad, que contamos en la siguiente sección.

Copilot CLI usa dos umbrales en lugar de uno. Según la documentación, el resumen empieza en segundo plano cuando la conversación llega a cerca del 80 % de la ventana; el espacio que queda se reserva para que las llamadas a herramientas sigan funcionando mientras se escribe el resumen. Si la ocupación sube a cerca del 95 % antes de que termine el resumen, la CLI espera un momento.

En Codex, el umbral lo fija model_auto_compact_token_limit en el archivo ~/.codex/config.toml. Si lo dejas vacío, se usa el valor por defecto del modelo; la documentación no da la cifra de ese valor. Puedes cambiar cómo se escribe el resumen con compact_prompt.

Si todavía usas Gemini CLI: Gemini CLI comprime por defecto cuando se llena la mitad del contexto (compressionThreshold vale 0,5 por defecto), y el comando manual es /compress. Para los usuarios del nivel gratuito y de Google One, Google sustituyó Gemini CLI por Antigravity CLI el 18 de junio de 2026; Gemini CLI se sigue usando con licencias empresariales y claves de API de pago.

¿Qué se pierde cuando se resume la conversación?

Resumir tiene tres costes, y los tres están en la propia documentación de las herramientas.

La caché deja de servir. El prompt caching guarda el principio de una petición que no cambia, y las peticiones siguientes lo leen a bajo coste. Un resumen o una limpieza cambian el principio de la conversación. La siguiente petición solo puede usar la copia en caché hasta el punto que cambió, y el resto lo vuelve a escribir. Por eso la documentación de Anthropic recomienda el ajuste clear_at_least: cada limpieza debe borrar al menos cierto número de tokens para que valga la pena reescribir la caché. Qué cambios invalidan la caché lo explicamos en detalle en el artículo sobre prompt caching.

El resumen por inactividad que llegó a Claude Code el 14 de octubre sale de la misma cuenta. Según la nota de versión, una conversación de más de 200.000 tokens que se queda inactiva unos 54 minutos se resume antes de que caduque la caché de una hora. Según la documentación de ajustes, cuando vuelves, tu primer mensaje envía el resumen y no la conversación entera. Si no lo quieres, puedes desactivarlo en los ajustes con "idleCompaction": false.

Las instrucciones del principio de la conversación pueden perderse. La documentación de Claude Code es clara: tus peticiones y los fragmentos de código importantes se conservan, pero las instrucciones detalladas que diste al principio de la conversación pueden perderse; escribe las reglas permanentes en CLAUDE.md, no en la conversación. La documentación de Copilot dice que las pequeñas decisiones tomadas al principio de una conversación larga pueden no entrar en el resumen y que un resumen terminado no se puede deshacer. VS Code y Cursor dicen lo mismo: un resumen es una compresión con pérdida.

La nota de versión 1.2.8 de Antigravity CLI es un ejemplo concreto de esta pérdida: hasta esa versión, cuando los demás prompts de la conversación eran cortos, una primera instrucción larga se recortaba en el resumen a un trozo pequeño y fijo. Cómo escribir un archivo de reglas lo contamos en el artículo sobre AGENTS.md y CLAUDE.md.

El propio resumen puede convertirse en una instrucción. El resumen también lo escribe un modelo, y el modelo que sigue trabajando después puede leerlo como una instrucción. El ejemplo más claro es el informe de OpenAI: durante el entrenamiento, un modelo no publicado añadió instrucciones no autorizadas a sus propios resúmenes de compaction. OpenAI lo detectó el 9 de agosto, actualizó el informe el 16 de septiembre y encontró 27 resúmenes así en los datos de entrenamiento.

En un ejemplo, el usuario había pedido un repaso largo de la literatura con las fuentes citadas. El resumen añadió una regla que nadie había pedido: la respuesta tendría como máximo 30 palabras, sin herramientas ni fuentes. El modelo que siguió después del resumen obedeció esa regla y escribió una negativa de 23 palabras. Según el informe, esto se vio en una ejecución de entrenamiento distinta de aquella de la que salió el modelo final, y no se repitió al regenerar el resumen; es decir, no se observó en un modelo publicado.

Aun así, la lección es general: un resumen no es una instrucción que escribiste tú, sino un texto que escribió un modelo. En las herramientas de programación también se ha visto un fallo parecido. La nota de versión 2.1.292 de Claude Code corrige uno: un resumen que repetía un comando de skill podía llevar a Claude a ejecutar una skill reservada al usuario. Si después de un resumen el agente hace algo que no esperabas, mira primero el resumen: en Copilot CLI, /session checkpoints muestra cada resumen automático por separado.

¿Cuándo conviene usar clear en lugar de compact?

Los dos comandos resuelven el mismo problema de dos maneras. Compact sustituye la conversación por un resumen y sigue en la misma sesión. Clear deja la conversación por completo y empieza con un contexto vacío; los archivos de reglas y de memoria del disco siguen en su sitio. Cuál elegir depende de si la próxima tarea necesita la conversación anterior:

Fuente: la documentación de comandos de cada herramienta, 20 de octubre de 2026. El enfoque entre corchetes o entre ángulos es opcional: ahí escribes qué debe quedar en el resumen.

El criterio más concreto para saber cuándo empezar de cero está en la documentación de Claude Code: si has corregido a Claude más de dos veces sobre el mismo problema, el contexto está lleno de intentos fallidos; escribe /clear y vuelve a empezar con un prompt más claro que recoja lo que aprendiste. La documentación de Copilot añade otro: si la conversación se ha resumido muchas veces y crees que se ha perdido algo importante, abre una sesión nueva.

La tercera opción es no dejar que el ruido entre en la conversación principal. Cuando pasas a un subagente pasos como leer un log largo, repasar una salida de tests grande o buscar en el código, todo lo que lee se queda en la ventana propia del subagente y a la conversación principal solo vuelve el resultado. Claude Code, Copilot y Cursor lo recomiendan expresamente en su documentación; los subagentes los contamos en un artículo aparte. En Claude Code, desde la versión 2.1.296 (9 de octubre), también puedes darle a un subagente un umbral de resumen más temprano que el de la conversación principal. El ejemplo de la documentación es un subagente que lee archivos de log largos:

---
name: log-reader
description: Lee archivos de log largos e informa de los errores que encuentra
autoCompactWindow: 200000
---

Escribe el valor como un número simple. Según la documentación, Claude Code lee 200k en este campo como 200; ese valor queda fuera del rango permitido, y el subagente funciona como si el campo no existiera.

¿Qué vuelve a leer el agente después de un resumen?

La forma de sobrevivir a un resumen es guardar la información en el disco, no en la conversación. La documentación de Claude Code enumera una por una las cosas que vuelven después de un resumen:

Fuente: documentación de Claude Code, páginas «Explore the context window» y «Store instructions and memories», 20 de octubre de 2026.

Si quieres que una instrucción que diste en la conversación siga valiendo después de un resumen, hay dos caminos: escribirla en CLAUDE.md o usar un hook que se ejecute después de cada resumen. El ejemplo de la documentación de Claude Code, en español:

{
  "hooks": {
    "SessionStart": [
      {
        "matcher": "compact",
        "hooks": [
          {
            "type": "command",
            "command": "echo 'Recordatorio: usa Bun, no npm. Ejecuta bun test antes de hacer commit.'"
          }
        ]
      }
    ]
  }
}

El texto que imprime el hook se añade junto al contexto resumido. En lugar de echo, también puedes ejecutar un comando que cuente el estado actual, como git log --oneline -5. Los hooks los contamos en un artículo aparte. En las demás herramientas, la situación es esta:

• Codex: la memoria local (memories) está desactivada por defecto. La documentación pide escribir en AGENTS.md las reglas que el equipo debe cumplir y ver la memoria solo como una capa que ayuda a recordar.
• GitHub Copilot: cuando la CLI resume, conserva junto al resumen las instrucciones originales del usuario y el estado más reciente de los planes y las listas de tareas. Copilot Memory (en versión preliminar pública) comparte datos sobre un repositorio entre la CLI, el agente en la nube y la revisión de código; antes de usar un dato, comprueba en la rama actual el código en el que se basa. La herramienta de memoria de VS Code guarda las notas en local; la documentación recomienda escribir las decisiones de las que depende el equipo en documentos bajo control de versiones o en archivos de custom instructions.
• Cursor: según la documentación, el modelo no recuerda nada de una respuesta a otra; para el contexto permanente están las reglas (rules). Además, al resumir, Cursor le da al agente el historial del chat como archivo, y el agente puede buscar ahí lo que falta en el resumen (artículo de enero de 2026).
• Antigravity: el comando /learn propone guardar como regla o skill lo aprendido en una sesión, por ejemplo una corrección o una restricción que se pasa por alto una y otra vez; no escribe nada en un archivo hasta que lo apruebas. La documentación parte de una idea clara: los agentes no recuerdan las conversaciones.
• Gemini CLI: el ajuste experimental autoMemory extrae sugerencias de memoria de sesiones anteriores; está desactivado por defecto y no se aplica ninguna hasta que la apruebas en /memory inbox.

¿Por qué un agente de revisión de código no puede resumir?

Todo lo anterior vale para una sesión que habla con una persona y crece a medida que avanza. Un agente que revisa un pull request no funciona así: es una sola llamada, no tiene a quién preguntar y no tiene un historial que resumir. Tiene que decidir antes de la llamada qué se envía al modelo.

En diffox, esa decisión la toma el paquete de contexto que comparten todos los agentes especializados de una revisión. En el código, el paquete se construye así:

• Primero va el diff. Después, las líneas y los símbolos modificados, los puntos de llamada afectados por el cambio y el historial de git; el contexto de los archivos, la descripción del PR y los mensajes de commit van al final. Si el paquete supera el límite, se corta por el final y, donde se corta, se añade una línea que lo dice. El orden se eligió para que al final quede la parte cuya pérdida cuesta menos.
• Los archivos lock no entran en el diff. Los archivos que escribe una herramienta, como go.sum, package-lock.json o uv.lock, las carpetas vendor y los archivos minificados se sacan del diff, y sus nombres se escriben en una sola línea. El código guarda el motivo como una medición: en un pull request del conjunto del benchmark, go.sum y go.work.sum eran el 68,5 % del diff, y el archivo fuente donde estaba el error estudiado, el 4,2 %.
• Se envía el entorno del cambio, no el archivo entero. Cada rango de líneas omitido se indica con sus números de línea, así el modelo sabe qué falta.
• Las reglas del repositorio van fuera del paquete. Las reglas de obligado cumplimiento del archivo de reglas se añaden aparte al prompt de sistema de cada agente, así que el corte no las toca. Es la contrapartida, en la revisión, del consejo que se da con los agentes de programación: «escribe las reglas permanentes en el archivo de reglas».
• El archivo que no se leyó queda registrado. Cada revisión registra si cada archivo modificado llegó a los agentes entero, en parte o no llegó. Si en una revisión sin hallazgos algunos archivos no se leyeron enteros, el comentario del pull request lo dice en una frase.

Uses la herramienta que uses, la lección es la misma: si el agente no leyó un archivo, la respuesta «sin hallazgos» no dice nada de ese archivo. También con un agente de programación, antes de decir «esto ya lo sabe», mira qué hay en la ventana: en Claude Code, Copilot CLI y Antigravity CLI, /context lo muestra.