Cómo Codex resuelve el problema de compactación

Si has usado Claude Code en alguna sesión seria de programación, ya lo has visto: “Compacting conversation…” aparece en el terminal, y a partir de ese momento algo no cuadra. El modelo empieza a olvidar cosas que comentaste diez minutos antes. La latencia sube. Preguntas por una función que acabáis de refactorizar juntos y te responde como si la oyera por primera vez.

Esto ocurre 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 refactorización grande, varias lecturas de ficheros, algunas llamadas a herramientas con salida verbosa, y ya estás 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 pronto como al 65%), Claude Code resume la conversación, descarta los mensajes originales y continúa solo con el resumen. La información que no quedó recogida en el resumen desaparece.

Seguía oyendo que el Codex de OpenAI resuelve esto de forma distinta, así que me puse a diseccionar todos los análisis públicos que encontré. El trabajo más interesante es el de Kangwook Lee, CAIO en Krafton, que usó inyección de prompt para hacer ingeniería inversa del pipeline real.

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

El problema de fondo es sencillo. La summarización es compresión con pérdida. Cuando Claude Code compacta, ejecuta una summarización en segundo plano de la conversación completa, crea un bloque de compactación y descarta todo lo anterior. Los ficheros CLAUDE.md sobreviven porque se vuelven a leer desde disco, pero cualquier cosa que dijiste solo en la conversación desaparece salvo que el summarizador lo haya capturado.

Los resultados de llamadas a herramientas son donde más duele. Cuando le pides a Claude Code que lea un fichero, el contenido completo entra en el contexto. Cuando ejecutas un comando, la salida completa entra en el contexto. Estos resultados de herramientas 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 fichero de 500 líneas se convierte en una sola frase del tipo “leyó el fichero de configuración y anotó la configuración de base de datos.” Los valores concretos, los casos extremos que discutiste, los números de línea que referenciaste: todo ha desaparecido.

He visto pasar esto decenas de veces. Después de una compactación, pregunto “¿cuál era el tipo de retorno de esa función auxiliar que miramos?” y obtengo una respuesta equivocada dicha con total seguridad. El modelo no está alucinando en el sentido habitual. Trabaja a partir de un resumen que genuinamente no contiene lo que le pregunto.

Tras 9 o más compactaciones en una sesión larga, el problema se acumula. Cada resumen comprime el resumen anterior un poco más. La justificación de decisiones tomadas al inicio de la sesión se erosiona por completo. A la décima hora de sesión, el modelo no recuerda por qué elegiste el enfoque A sobre el B, aunque pasarais veinte minutos discutiendo los compromisos.

Por dentro del pipeline de compactación cifrado de Codex

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

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

La segunda inyección aprovechó el paso de descifrado. Al devolver el blob cifrado junto con un mensaje de usuario manipulado a la Responses API, el servidor descifró el blob y ensambló el contexto del modelo. Como la primera inyección había incrustado el system prompt del compactador dentro del resumen, el contexto descifrado reveló cómo funciona todo el pipeline.

Esto es lo que encontró: cuando llamas a la API compact() de Codex, un LLM separado resume la conversación, y el resultado vuelve cifrado con AES. En el siguiente turno, el servidor descifra ese blob, antepone un prompt de traspaso (“aquí tienes un resumen de la conversación anterior”) y le pasa todo al modelo. La clave de cifrado reside en los servidores de OpenAI. El cliente nunca ve el resumen en texto plano.

El propio prompt de compactación resultó ser prácticamente idéntico a la plantilla de compactación del Codex CLI de código abierto para modelos que no son Codex. Nada especial en el prompt engineering. Lo interesante es la arquitectura: cifrado en el lado del servidor, descifrado e inyección en el 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 responde a esto de forma definitiva. Una teoría es que el blob cifrado contiene más que un simple resumen de texto: datos de restauración de llamadas a herramientas, marcadores de estado interno o metadatos estructurados que OpenAI no quiere exponer. Otra posibilidad es simplemente que los blobs cifrados impiden que los usuarios manipulen el resumen para influir en el comportamiento del modelo. Me parece más probable la segunda explicación, pero ninguna está confirmada.

OpenAI también lo soporta en el lado del servidor a través de la Responses API. Establece un valor compact_threshold y, cuando el recuento de tokens lo supera, el servidor ejecuta la compactación de forma inline. El item de compactación se transmite en streaming dentro de la respuesta, y lo añades a las solicitudes posteriores. Los items anteriores al item de compactación más reciente se pueden descartar sin problema.

En contraste, el enfoque de Claude Code: el bloque de compactación es legible por humanos. Puedes inspeccionarlo, y puedes personalizar el comportamiento de compactación a través del parámetro instructions o añadiendo directivas de compactación personalizadas en CLAUDE.md. Más transparente, pero la misma pérdida de información fundamental aplica.

El patrón de traspaso de sesión

Dejando de lado la mecánica de compactación, el problema más interesante es qué ocurre cuando necesitas iniciar una nueva sesión sin perder el contexto. Aquí fue donde vi la automatización de un desarrollador que cambió mi forma de entender el problema.

El patrón funciona así. Justo antes de que se active la compactación, un hook pre-compact bloquea todas las herramientas de escritura. Esto evita que el modelo realice cambios en el código mientras está en un estado de conocimiento parcial, un fallo que he sufrido varias veces: la compactación se dispara en mitad de una refactorización, el modelo pierde la pista de qué ficheros ya había cambiado, y escribe ediciones contradictorias.

Con las escrituras bloqueadas, el sistema extrae únicamente los mensajes del usuario y los bloques de thinking del log de sesión en JSONL. Todo lo demás (llamadas a herramientas, contenidos de ficheros, respuestas del asistente) se descarta. Esto reduce el log a aproximadamente el 2% de su tamaño original.

Después, tres sub-agentes se ejecutan en paralelo, cada uno buscando en los logs JSONL originales sin comprimir la información que la extracción pasó por alto. Buscan huecos: decisiones arquitectónicas que se discutieron pero no quedaron capturadas en los mensajes del usuario, patrones de error que solo aparecieron en la salida de herramientas, justificación de enfoques que fueron rechazados. Estos agentes compilan sus hallazgos en un fichero resume-prompt.md que contiene el resumen de la sesión, los resultados del análisis de huecos y una lista de ficheros 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 una imagen clara y completa de dónde se quedó la sesión anterior.

La mejora reportada fue de 10x en eficiencia de compilación. 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, obtienes una ventana de contexto fresca con un documento de traspaso curado y revisado por huecos.

Intenté implementar una versión más sencilla yo mismo. El paso de análisis de huecos es donde se concentra el valor. Sin él, simplemente estás haciendo lo que ya hace la compactación pero en otro formato. Con él, estás recuperando activamente información que la summarización perdió. Mi versión usa un único 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 con tres agentes.

La KV cache como palanca oculta de costes

Hay una dimensión de rendimiento en todo esto que la mayoría de los análisis ignoran por completo. La KV cache (los pares clave-valor calculados durante la atención) puede reutilizarse entre solicitudes cuando el prefijo del prompt es idéntico. Dos solicitudes que comparten los mismos tokens iniciales se saltan la recomputación de esos tokens.

Los números son significativos. En una prueba controlada comparando system prompts estables frente a perturbados, los prefijos estables alcanzaron tasas de acierto de caché del 85% con un tiempo hasta el primer token mediano de 953ms. Con prefijos perturbados: 0% de aciertos de caché, 2.727ms de TTFT. El coste por solicitud bajó de 0,033 a 0,009 dólares. Eso es una reducción del 65% en latencia y del 71% en costes solo por mantener el prefijo del prompt consistente.

Esto tiene implicaciones directas para el patrón de traspaso de sesión. Si tu resume-prompt.md siempre empieza con el mismo prefijo estructural (system prompt, instrucciones de traspaso, y luego el contenido variable), la parte fija queda en caché. Cada solicitud posterior en la nueva sesión se beneficia de esa caché. Si aleatorizas la estructura del prefijo o inyectas contenido variable al principio, cada solicitud recomputa desde cero.

Diseñé mi estructura de carpetas de sesión en torno a esta idea. El archivado basado en session-id mantiene los documentos de traspaso organizados, y la convención de prefijo fijo para los prompts de reanudación hace que los primeros 40-50K tokens de cada sesión nueva golpeen la KV cache. La preindexación de archivos de sesión con QMD (una herramienta que traté por separado) acelera el paso de recuperación cuando los sub-agentes necesitan buscar en sesiones históricas.

Lo que realmente importa aquí

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 frente a bloque de compactación legible por humanos) 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 tiene pérdida.

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

El cuello de botella en las herramientas de programación con IA no es la inteligencia del modelo. Es la gestión del contexto. Lo he comprobado en primera persona: un resumen mediocre con buena recuperación supera a un resumen excelente sin recuperación en todo momento. Construir sistemas que recuperen información olvidada de forma fiable importa más que construir sistemas que summaricen con más precisión.

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