La compactación de contexto borra un tercio de las reglas antitrampas en ProgramBench

Cada vez más tareas largas de agentes no caben en la ventana de contexto, y el arnés del agente tiene que liberar espacio: comprimir el historial, descartar lo superfluo y seguir trabajando a partir de un resumen breve. Esta técnica se llama compactación y está presente en prácticamente cualquier agente de programación. Apenas se había evaluado de forma sistemática con modelos frontier y tareas realistas: los trabajos anteriores usaban modelos abiertos pequeños sobre trayectorias de juguete o sintéticas. El grupo de Jeanne Salle, junto con otros cuatro coautores, cubrió ese vacío y obtuvo un resultado con doble fondo. Los benchmarks casi no notan la compactación, pero el trabajo real sí.

Cómo se diseñó el experimento

Los autores fijaron el arnés OpenCode e implementaron en él cinco estrategias de compactación. Después pasaron tres modelos frontier por tres benchmarks largos. Dos de los tres modelos tienen un contexto de 1 millón de tokens; el tercero es GPT-5.3-Codex, con la ventana más pequeña de la muestra. También variaron el umbral que activa la compresión.

• Arnés: OpenCode, el mismo en todas las ejecuciones.
• Estrategias: cinco variantes de compactación; la de referencia es el autorresumen, en el que el propio modelo reescribe su historial.
• Modelos: dos con ventana de 1M y GPT-5.3-Codex.
• Benchmarks: PaperBench, ProgramBench, PostTrainBench.
• Conjunto de datos adicional: sesiones reales de usuarios de SWE-chat.

Dónde es segura la compactación y dónde no

En los modelos con ventana de 1M, el umbral de compresión no influye de forma apreciable en el resultado. Con GPT-5.3-Codex el panorama cambia: en PaperBench la calidad cae con umbrales bajos, mientras que en PostTrainBench el efecto es más débil y menos claro. La lógica es sencilla: cuanto menor es la ventana, más a menudo y con más agresividad hay que comprimir, y más pérdidas se acumulan.

Los métodos ingeniosos no cumplieron. Ninguno superó al autorresumen simple. Los enfoques que descartan más contenido costaron hasta 20 puntos a unos modelos y nada a otros. Es decir, la sensibilidad a la compactación agresiva depende del modelo y no se puede prever de antemano.

El hallazgo más inquietante tiene que ver con las restricciones. En ProgramBench, el primer resumen ya pierde de media cerca de un tercio de las reglas antitrampas de la tarea, y con cada compactación posterior la proporción perdida crece de forma monótona. Un agente que olvida que no debe espiar ni saltarse la verificación sigue trabajando formalmente, pero ya bajo otras reglas. Y no avisa de ello.

En las sesiones reales de SWE-chat la brecha es aún mayor. Las instrucciones sobre cómo debe trabajar el agente y qué no debe hacer se descartan unas 6 veces más a menudo que las especificaciones de lo que hay que construir. El modelo recuerda bien el objetivo y mal la manera de trabajar: el estilo, las prohibiciones, los acuerdos con el usuario.

Por qué los benchmarks inducen a error

Los autores describen los benchmarks actuales como «amigables con la compactación». En ellos el objetivo está fijado y escrito en el enunciado, y el progreso del agente queda en disco: código, archivos, logs. Por eso casi todo lo que la compresión saca del contexto se puede recuperar releyendo el repositorio. Lo irrecuperable es lo que no está registrado en ningún otro sitio: las restricciones, los datos dados de palabra en el diálogo, las razones de decisiones anteriores. En una sesión real hay muchas cosas así; en un benchmark, casi ninguna. De ahí la conclusión: unas cifras en verde en las pruebas no garantizan que el agente no vaya a perder requisitos en un proyecto real.

Para quienes construyen agentes, las conclusiones son prácticas. No conviene complicar la compactación: el autorresumen por defecto sigue siendo una base sólida, y ahorrar tokens con un descarte agresivo puede costar hasta 20 puntos de calidad. Las reglas y prohibiciones deben mantenerse fuera del historial del diálogo: en el prompt de sistema, en un archivo de instrucciones del repositorio o en un bloque fijado que la compresión no toque.

Tras cada compactación tiene sentido contrastar automáticamente el resumen con la lista de restricciones. Y al elegir modelo, el tamaño de la ventana de contexto importa por lo que implica: cuanto menor es, más a menudo se activa la compactación y mayor es el riesgo de perder requisitos en silencio. Por último, conviene evaluar a los agentes en escenarios en los que parte de las condiciones existe solo en el diálogo; de lo contrario, el benchmark medirá la memoria del objetivo y no la disciplina de trabajo.