Cómo Codex resuelve el problema de compactación

Si han usado Claude Code en una sesión de trabajo seria, ya lo vieron: aparece “Compacting conversation…” en la terminal y, a partir de ahí, algo falla. El modelo empieza a olvidar cosas que discutieron diez minutos antes. La latencia sube. Preguntan sobre una función que acaban de refactorizar juntos y responde como si la escuchara por primera vez.

Esto pasa porque la ventana de contexto de 200K tokens de Claude Code se llena mucho más rápido de lo que la mayoría espera. Una sesión grande de refactorización, algunas lecturas de archivos, tool calls con output verboso, y ya están al límite. Cuando se alcanza ese umbral (aproximadamente entre el 75 y el 92% de la ventana, aunque he visto que se dispara tan temprano como al 65%), Claude Code resume la conversación, descarta los mensajes originales y continúa solo con el resumen. Lo que no quedó capturado en el resumen, desaparece.

Seguía escuchando que Codex de OpenAI maneja esto de forma diferente, así que dediqué tiempo a revisar todo el análisis público disponible. El trabajo más interesante vino de Kangwook Lee, CAIO de Krafton, quien usó prompt injection para hacer ingeniería inversa del pipeline real.

Lo que la compactación pierde y por qué importa

El problema central es directo. La summarización es compresión con pérdida. Cuando Claude Code compacta, ejecuta una summarización en segundo plano de toda la conversación, crea un bloque de compactación y descarta todo lo anterior. Los archivos CLAUDE.md sobreviven porque se vuelven a leer desde el disco, pero cualquier cosa que dijeron solo en la conversación desaparece si el summarizador no la capturó.

Los resultados de tool calls son donde esto duele más. Cuando le piden a Claude Code que lea un archivo, el contenido completo entra al contexto. Cuando ejecutan un comando, el output completo entra al contexto. Esos resultados suelen ser las partes más densas en información de la conversación, y son exactamente las que quedan aplanadas durante la summarización. Una lectura de archivo de 500 líneas se convierte en una sola oración como “se leyó el archivo de configuración y se anotaron los ajustes de la base de datos.” Los valores específicos, los casos borde que discutieron, los números de línea que referenciaron: todo desaparece.

He visto esto pasar docenas de veces. Después de la compactación, pregunto “¿cuál era el tipo de retorno de esa función auxiliar que miramos?” y recibo una respuesta incorrecta dicha con total confianza. El modelo no está alucinando en el sentido habitual. Está trabajando desde un resumen que genuinamente no contiene lo que le estoy preguntando.

Después de 9 o más compactaciones en una sesión larga, el problema se acumula. Cada resumen comprime el resumen anterior aún más. La justificación de decisiones tomadas al inicio de la sesión se erosiona por completo. A la décima hora de una sesión, el modelo no tiene memoria de por qué eligieron el enfoque A sobre el B, aunque hayan pasado veinte minutos discutiendo las diferencias.

El pipeline de compactación cifrado de Codex

El análisis de Kangwook Lee fue ingenioso. Usó dos prompt injections encadenadas para extraer el comportamiento interno del sistema de compactación de Codex.

La primera injection apuntó al LLM compactador en sí. Cuando Codex activa la compactación, no resume localmente. Envía la conversación a un LLM separado en los servidores de OpenAI, que produce un resumen. La injection de Lee engañó a ese compactador para que incluyera su propio system prompt en el output del resumen. El servidor luego cifró ese resumen (que ahora contenía el prompt filtrado) con AES y lo devolvió como un blob opaco.

La segunda injection explotó el paso de descifrado. Al pasar el blob cifrado más un mensaje de usuario diseñado de vuelta a la Responses API, el servidor descifró el blob y ensambló el contexto del modelo. Como la primera injection había embebido el system prompt del compactador dentro del resumen, el contexto descifrado reveló cómo funciona todo el pipeline.

Lo que encontró: cuando se llama la API compact() de Codex, un LLM separado resume la conversación, y el resultado vuelve cifrado con AES. En el turno siguiente, el servidor descifra ese blob, antepone un prompt de handoff (“acá hay un resumen de la conversación anterior”) y le pasa todo al modelo. La clave de cifrado vive en los servidores de OpenAI. El cliente nunca ve el resumen en texto plano.

El prompt de compactación en sí resultó ser casi idéntico al template de compactación del Codex CLI de código abierto para modelos que no son Codex. No hay ingrediente secreto en el prompt engineering. Lo interesante es la arquitectura: cifrado del lado del servidor de los resúmenes, descifrado e inyección del lado del servidor, y un blob opaco que el cliente pasa sin poder inspeccionarlo ni modificarlo.

¿Por qué cifrar? El análisis de Lee no respondió esto de forma definitiva. Una teoría es que el blob cifrado contiene más que solo un resumen de texto: datos de restauración de tool calls, marcadores de estado interno o metadata estructurada que OpenAI no quiere exponer. Otra posibilidad es simplemente que los blobs cifrados evitan que los usuarios manipulen el resumen para alterar el comportamiento del modelo. La segunda explicación me parece más probable, pero ninguna está confirmada.

OpenAI también soporta esto del lado del servidor a través de la Responses API. Configuren un valor compact_threshold y, cuando el conteo de tokens lo supere, el servidor ejecuta la compactación inline. El item de compactación se transmite dentro de la respuesta y se agrega a las solicitudes siguientes. Los items anteriores al item de compactación más reciente se pueden descartar sin problema.

Esto contrasta con el enfoque de Claude Code: el bloque de compactación es legible. Pueden inspeccionarlo y pueden personalizar el comportamiento a través del parámetro instructions o agregando directivas de compactación a CLAUDE.md. Más transparente, pero la misma pérdida fundamental de información aplica.

El patrón de session handover

Dejando de lado la mecánica de compactación, el problema más interesante es qué pasa cuando necesitan empezar una nueva sesión sin perder el contexto. Acá fue donde vi la automatización de un desarrollador que cambió cómo pienso en el problema.

El patrón funciona así. Justo antes de que se active la compactación, un hook pre-compact bloquea todas las write tools. Esto evita que el modelo haga cambios en el código mientras está en un estado de conciencia parcial, que es un modo de falla en el que he caído varias veces: la compactación se dispara en medio de una refactorización, el modelo pierde el hilo de qué archivos ya modificó y escribe ediciones conflictivas.

Con las escrituras bloqueadas, el sistema extrae solo los mensajes del usuario y los thinking blocks del log JSONL de la sesión. Todo lo demás (tool calls, contenidos de archivos, respuestas del asistente) se descarta. Esto reduce el log a aproximadamente el 2% de su tamaño original.

Luego tres sub-agentes corren en paralelo, cada uno buscando en los logs JSONL originales sin comprimir la información que la extracción omitió. Buscan brechas: decisiones de arquitectura que se discutieron pero no quedaron capturadas en los mensajes del usuario, patrones de error que solo aparecieron en el output de tool calls, justificaciones de enfoques que se descartaron. Estos agentes compilan sus hallazgos en un archivo resume-prompt.md que contiene el resumen de la sesión, los resultados del análisis de brechas y una lista de archivos modificados.

Un file watcher de VS Code detecta el nuevo resume-prompt.md y abre una sesión nueva que lo carga como contexto inicial. La nueva sesión empieza con un panorama claro y completo de dónde quedó la sesión anterior.

La mejora reportada fue de 10x en eficiencia de build. Ese número es difícil de verificar de forma independiente, pero la arquitectura tiene sentido. En lugar de un resumen cada vez más degradado, obtienen una ventana de contexto fresca con un documento de handover curado y con análisis de brechas.

Intenté implementar una versión más simple por mi cuenta. El paso de análisis de brechas es donde se concentra el valor. Sin él, solo están haciendo lo que la compactación ya hace pero en un formato diferente. Con él, están recuperando activamente información que la summarización perdió. Mi versión usa un solo sub-agente en lugar de tres, y los resultados son notablemente mejores que la compactación pura, aunque probablemente no tan exhaustivos como el enfoque completo de tres agentes.

El KV cache como palanca de costos oculta

Hay una dimensión de performance en esto que la mayoría de las discusiones pasan por alto por completo. El KV cache (los pares clave-valor computados durante la atención) puede reutilizarse entre solicitudes cuando el prefijo del prompt es idéntico. Dos solicitudes que comparten los mismos tokens iniciales omiten la recomputación de esos tokens.

Los números son significativos. En una prueba controlada comparando system prompts estables versus perturbados, los prefijos estables lograron tasas de acierto del 85% con un tiempo hasta el primer token (TTFT) mediano de 953ms. Los prefijos perturbados: 0% de aciertos en cache, 2727ms de TTFT. El costo por solicitud cayó de $0.033 a $0.009. Eso es una reducción del 65% en latencia y del 71% en costo solo por mantener el prefijo del prompt consistente.

Esto tiene implicaciones directas para el patrón de session handover. Si su resume-prompt.md siempre empieza con el mismo prefijo estructural (system prompt, instrucciones de handoff, luego contenido variable), la parte fija queda cacheada. Cada solicitud siguiente en la nueva sesión se beneficia de ese cache. Si aleatorizan la estructura del prefijo o inyectan contenido variable temprano, cada solicitud recomputa desde cero.

Diseñé mi propia estructura de carpetas de sesión alrededor de este insight. El archivado basado en session-id mantiene los documentos de handover organizados, y la convención de prefijo fijo para los resume prompts hace que los primeros 40 a 50K tokens de cada sesión nueva lleguen al KV cache. Pre-indexar los archivos de sesión con QMD (una herramienta que cubrí por separado) hace que el paso de recuperación sea más rápido cuando los sub-agentes necesitan buscar en sesiones históricas.

Lo que realmente importa

La conclusión real no es que el enfoque de Codex sea mejor o peor que el de Claude Code. Ambos pierden información durante la compactación. Ambos tienen dificultades con sesiones largas. La diferencia arquitectónica (blob opaco cifrado versus bloque de compactación legible) refleja filosofías de diseño distintas, pero la limitación fundamental es la misma: las ventanas de contexto son finitas y la summarización es con pérdida.

Lo que importa es lo que construyen alrededor de esa limitación. El patrón de session handover, el análisis de brechas, la recuperación basada en JSONL, la optimización del KV cache: estas son soluciones de ingeniería a un problema que ninguna mejora de modelo va a resolver por completo. Una ventana de contexto de 500K o 1M tokens pospone el problema pero no lo elimina.

El cuello de botella en las herramientas de desarrollo con IA no es la inteligencia del modelo. Es el manejo del contexto. Lo he visto de primera mano: un resumen mediocre con buena recuperación supera a un resumen excelente sin recuperación en cada ocasión. Construir sistemas que recuperen información olvidada de forma confiable importa más que construir sistemas que resuman con mayor precisión.

Detalles técnicos obtenidos del análisis de Kangwook Lee y la documentación pública de las APIs de OpenAI y Anthropic.