Tres pull requests ya fusionados en la rama principal del repositorio openai/codex dejan ver hacia dónde va la reforma en la gestión de la ventana de contexto de Codex: cuando una sesión supera el límite de la ventana, el sistema deja de generar un resumen para comprimir el historial y en su lugar activa directamente una ventana completamente nueva para continuar el trabajo. Las capacidades relacionadas están todas detrás de la feature flag `Feature::TokenBudget`, que aún no se ha lanzado oficialmente.
El enfoque actual es la compresión por resumen. Cuando la ventana está a punto de llenarse, el sistema pide al servidor que condense la conversación anterior en un resumen y lo use en lugar del historial original. Este método tiene dos costos fijos: generar el resumen consume tokens de por sí, y la compresión tiene pérdidas — convenciones de interfaz, nombres de rutas, decisiones cerradas varias rondas antes pueden borrarse en el proceso de condensación. Quien haya corrido tareas largas con Codex conoce bien este segundo tipo de fallo: el modelo olvida una regla acordada dos horas antes y aun así responde con total seguridad.
El modelo puede pedir una hoja nueva por su cuenta
El primer paso es el PR #27488, fusionado el 11 de junio, titulado "Add new context window tool". Añade al modelo la herramienta `new_context`, disponible únicamente para el propio modelo, que el autor describe en la descripción como una "escape hatch" para cuando la ventana actual se vuelve inmanejable.
La solicitud queda registrada en `AutoCompactWindow` y se consume justo después del muestreo; la siguiente solicitud dentro de la misma ronda cae ya en la ventana nueva. El punto de partida de la ventana nueva es un checkpoint de compresión sin resumen, que solo conserva el contexto inicial — el historial de conversación anterior no se lleva consigo.
La limpieza manual también pasa por el mismo camino
El segundo paso es el PR #29743, fusionado el 23 de junio. Unifica la compresión manual y la automática en un único ciclo de vida, `compact_token_budget`: con el token budget activado, la compresión deja de pedir un resumen al servidor y en su lugar carga localmente un contexto inicial completamente nuevo.
En los detalles técnicos de este paso hay cierta contención: el comportamiento visible desde fuera se mantiene, los hooks de compact se siguen disparando con normalidad, el evento de ciclo de vida `ContextCompaction` se sigue emitiendo. Es decir, los clientes que dependen de esos eventos no necesitan cambiar nada — lo que cambia es la implementación por debajo.
La parte recuperada queda a cargo del historial y las notas
Los dos primeros pasos solo resuelven el "descartar"; el PR #39827, fusionado el 21 de agosto, es el que completa el "recuperar". La descripción de este PR lo dice sin rodeos: las sesiones con token budget necesitan una forma de restaurar el contexto de conversación anterior y conservar el estado de trabajo entre cambios de ventana.
Añade dos grupos de herramientas. Las herramientas de historial se encargan de listar ventanas y entradas, leer una entrada concreta y buscar en el contenido de la sesión; las herramientas de notas se encargan de listar, leer, buscar, añadir y escribir notas persistentes. Las llamadas pasan por el backend de Codex, requieren el proveedor OpenAI y autenticación de backend, y también están detrás de la feature flag `features.token_budget.use_history_notes_history`.
A nivel técnico se añadieron varios límites: la salida se procesa de forma consciente del truncamiento, y los parámetros de las solicitudes tienen topes definidos. Los comentarios de la revisión automática se centran en el límite de 10.000 tokens para resultados en texto plano, los límites de parámetros para las operaciones con notas y la sugerencia de un despliegue por fases.
Qué es lo que realmente se está sustituyendo
La compresión por resumen y el cambio de ventana con recuperación son, en el fondo, dos estrategias de memoria distintas. La primera es una compresión implícita y con pérdidas: el modelo no sabe qué perdió ni tiene forma de recuperarlo. La segunda es un reinicio explícito y sin estado: el modelo sabe con certeza que el contenido anterior sigue existiendo en algún lugar y va a buscarlo cuando lo necesita.
El costo también cambia de lugar. El fallo de la compresión con pérdidas ocurre en silencio; el fallo del cambio de ventana se convierte en "debía haber buscado y no buscó" o "buscó, pero no encontró lo correcto". El primero es difícil de depurar, el segundo al menos se puede ver en el registro. Para los agentes que ejecutan tareas largas, un fallo observable es mucho más manejable que uno silencioso.
El ahorro es la ganancia del otro lado. Un resumen requiere una llamada extra al modelo, un costo que se repite una y otra vez en sesiones largas; el cambio de ventana no genera esa llamada, y la recuperación solo ocurre cuando hace falta, entrada por entrada. Para los usuarios intensivos que agotan su cuota a diario, es un ahorro real.
Conviene dejar claro el ritmo: que un PR esté fusionado no significa que la función ya esté activa. Los tres cambios siguen detrás de feature flags, y la revisión automática sigue sugiriendo un despliegue por fases. Desde la primera versión de la herramienta en junio hasta el complemento de historial y notas en agosto, OpenAI lleva más de dos meses puliendo este camino — cuándo se activará el interruptor y para quién, los registros del repositorio todavía no lo dicen.
Fuentes: tres pull requests ya fusionados en el repositorio openai/codex, CocoLoop, comentarios de revisión automática en GitHub; los nombres de las herramientas, los nombres de las feature flags y el estado de fusión se han verificado uno por uno con los registros del repositorio.