OpenAI reduce el tamaño del contexto del modelo Codex de 372k a 272k

• OpenAI hizo un backport a la rama release/0.144 de un cambio que reduce el tamaño del contexto del modelo de 372k a 272k al actualizar los metadatos del modelo empaquetado de OpenAI Codex
• El PR #33972 trasladó los cambios desde la rama agent/hotfix-0.144-model-metadata al lanzamiento Codex 0.144
• El alcance del cambio es 1 archivo JSON, y las estadísticas del diff son 64 líneas agregadas y 54 eliminadas
• Se fusionó tras pasar por 1 commit y 36 verificaciones, sin conversación ni revisión adicional
• En la página proporcionada no se carga el diff del archivo, por lo que no es posible confirmar cambios específicos en los metadatos más allá de la reducción del contexto

---

Objetivo y alcance del cambio

• El título del PR indica que el trabajo consiste en hacer backport de los metadatos actualizados del modelo empaquetado a Codex 0.144
• Según el título en Hacker News, el tamaño del contexto del modelo se redujo de 372k a 272k
• La rama de destino es openai:release/0.144 y la rama de origen es sayan-oai:agent/hotfix-0.144-model-metadata

Resultado de la fusión

• El PR #33972 está compuesto por 1 commit: b06f4fa
• El título del commit es Backport refreshed bundled model metadata
• Se fusionó el 18 de julio de 2026, y se muestran 36 verificaciones y 1 archivo modificado
• El volumen del cambio es de 64 líneas agregadas y 54 eliminadas, y el formato del archivo es JSON

Límites de lo que se puede verificar

• Las secciones de archivos y comentarios de la página muestran un error de carga, por lo que el diff JSON real no puede verificarse en el contenido proporcionado
• El contenido no incluye pasos de reproducción, motivo del cambio, impacto en la compatibilidad ni comentarios de revisión

[GN⁺]

Opiniones de Hacker News

• Muchos dicen que se soluciona con compresión, pero en mi trabajo se pierde demasiada información detallada que desaparece con la compresión.
  Si el plan es simple o no hay discusiones muy minuciosas, puede estar bien, pero por la falta de contexto largo termino siguiendo con Anthropic.
  Cuando hay que recordar por completo varios papers o materiales grandes y complejos, el contexto siempre se queda en 16%. Después de unos 5 minutos de conversación se comprime, luego hago que vuelva a leer el material hasta llegar a 16%, y el proceso se repite.
  El contexto de 372k tampoco era perfecto, pero ayudaba mucho porque aumentaba el margen que antes era de 12–20% a alrededor de 40%.

  • No se puede desactivar la compresión automática ni volver al historial de conversación previo a la compresión, así que no puedo usar Codex en codebases de más de 5 mil líneas.
    Se ejecuta al azar cuando queda 10–20% de contexto, por lo que en la práctica solo se puede usar el 80% de 272k. Después de la compresión, las alucinaciones empeoran tanto que es peor que empezar desde cero, y al volver a leer la codebase entra en un ciclo en el que se comprime otra vez.
  • Mi proceso de diseño es distinto. El plan.md que se revisa varias veces es la memoria, y reiniciar la sesión, volver a leer el plan y revisarlo ayuda a obtener una perspectiva nueva.
  • Como la compresión es malísima, hice una herramienta que permite que el LLM elimine selectivamente partes del contexto y las restaure cuando las necesita. Si a menudo llegas al límite de la compresión automática, vale la pena probar context bonsai.
    https://github.com/Vibecodelicious/context-bonsai-agents
  • Los modelos de Anthropic ofrecen contexto de 1 millón de tokens. Pensaba mudarme a OpenAI el próximo mes, pero si todavía están cerca de 300k, parece que tendré que adaptarme a la nueva realidad.
  • Normalmente recomiendan hacer que el agente cree o actualice de vez en cuando archivos .md para recordar información importante que vaya apareciendo. Pero si el agente supiera con precisión qué es realmente importante, /compact también debería funcionar bien.

• Por las ventanas de contexto grandes dejamos de seleccionar qué incluir, y la compresión aplica compresión con pérdida a todo de una vez, lo que hace que se pierdan también los detalles necesarios.
  Creo que el problema de fondo es reenviar toda la conversación cada vez. Con un plugin de memoria y contexto que hice, vacío el contexto en cada turno y reinyecto solo la información relevante; así el modelo lee apenas unos miles de tokens de estado seleccionado en vez de un historial de conversación de 200 mil tokens, y el contexto pequeño no fue un problema.
  En agentes de coding todavía no lo resolví, pero creo que la verdadera solución es una política de retención que conserve solo lo necesario para completar la tarea o para la siguiente tarea y descarte el resto, y que eso se puede implementar con un LLM dedicado.

  • Muchos especialistas en procesamiento de lenguaje natural que estudiaron LSTM, GRU y otros también veían como problema fundamental reenviar toda la conversación, pero empíricamente ganó Transformer.
    Será interesante ver si las arquitecturas futuras de modelos vuelven a considerar este problema. Si tomamos a los humanos como referencia, lo que todavía falta es la capacidad de mover información de forma eficiente de la memoria de corto plazo a la de largo plazo; el fine-tuning hace algo parecido en principio, pero no de forma eficiente.

• No sé si esta es la razón del cambio, pero en primer lugar creo que usar un contexto más grande que esto suele ser un error.
  Se subestima cuánto cae el rendimiento del modelo y cuánto aumenta el costo en tokens a medida que crece el contexto. Con Claude no uso más de 300k; en lugar de comprimir, divido el trabajo y mantengo la documentación y la codebase modular de forma concisa.
  Para tareas puntuales, un contexto grande puede ser útil, pero si superas constantemente los 300k, es muy probable que estés perdiendo muchas cosas o que el diseño de la codebase no sea bueno.

  • Yo también comprimo o reinicio en 250k. Como el tamaño de contexto necesario es proporcional al tamaño del proyecto, quienes necesitan una ventana más grande parecen simplemente estar trabajando con proyectos más grandes.
  • Mi impresión es la misma, y pondría el límite más bien en 100–150k. Aunque el modelo admita contexto largo, el rendimiento real no es bueno.
  • No coincide con mi experiencia que el modelo se vuelva notablemente más tonto cuando crece el contexto. Se vuelve más lento y más caro, pero es un costo que hay que aceptar para tareas complejas.
    Hago que el agente principal encargue a subagentes investigar lo necesario y redactar un plan, y luego que otros subagentes lo revisen de forma adversarial y lo refuercen. Al terminar, se llena 30–40% de una ventana de 1 millón de tokens, y es un flujo imposible con 272k.
    En 5.6 Sol tuve que reducir mucho ese proceso, y probablemente esa sea la razón de que los resultados sean peores.

• Cuando ocurrió este cambio, Tibo publicó una explicación junto con él: https://x.com/thsottiaux/status/2076543065045795309

  • Las respuestas se pueden ver aquí: https://xcancel.com/thsottiaux/status/2076543065045795309
    El tuit enlazado es una respuesta no oficial a la información oficial de Tibo, y Tibo corrigió el contenido en las respuestas.
  • No entiendo este gráfico. Me pregunto por qué la línea sigue subiendo aunque comprime, o si “overall trajectory size” tiene algún significado que desconozco.
  • No sé si la longitud total de la trayectoria puede ser la misma aunque la intensidad de razonamiento sea distinta. Aunque se excluyan los tokens de razonamiento de la longitud de la trayectoria, no parece posible.

• No me gusta su compresión de contexto, y creo que ahora deberían ofrecer al menos 1 millón de tokens.
  GPT 5.5 y 5.6 se traban cada vez que se comprimen hasta que recuperan el ritmo, y a veces se enfocan demasiado en mensajes de instrucciones antiguos que quedan en el contexto comprimido.

  • GPT-5.6-Sol es aproximadamente 2 veces más eficiente en tokens que Opus/Fable, así que un máximo de 258k equivale a unos 516k de Claude.
    La degradación del contexto sigue siendo un problema[1][2], y también hay evidencia de que, en trabajos con agentes, la compresión es equivalente o incluso mejor que un contexto largo[3]. Lo ideal sería que el modelo razonara en un contexto de 1 millón igual que en uno de 256k, pero todavía no es posible.
    [1] https://arxiv.org/abs/2605.12366
    [2] Comparación de GraphWalks 256K y 1M F1 en la System Card de Opus 4.8: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
    [3] https://context-folding.github.io/
  • A diferencia de otras herramientas de programación, frustra que no se pueda desactivar la compresión automática. Como se ejecuta de forma irregular cuando queda entre 10% y 20% del contexto, la capacidad garantizada es solo el 80% de 272k.
    En una base de código grande, cuando el trabajo ya está casi terminado y solo queda una respuesta de unos 2 mil tokens, si baja del 20%, procesa durante un buen rato y luego aparece Context compacted. Como no se puede volver al estado previo a la compresión, vuelve a investigar la base de código, se comprime otra vez y al final agota todos los tokens.
  • Espero que la reducción de tokens no sea un atajo para aumentar el uso, sino principalmente para reducir costos. En mi empresa, los responsables de costos también limitaron tanto el contexto que un LLM interno que al principio era usable quedó prácticamente inútil.
    Parece que hubiera reuniones entre ejecutivos para compartir las peores prácticas.
  • La memoria de trabajo puede guardarse en archivos Markdown, así que no hace falta un contexto grande. Cuando el contexto crece, la atención se dispersa y baja el rendimiento del LLM, por lo que mantenerlo pequeño favorece la calidad.

• Uso Opus a diario y ejecuto /clear con frecuencia. Incluso con un contexto de 1 millón, cuando se acerca al 50% el rendimiento se degrada rápido, así que normalmente obtengo resultados mucho mejores si reinicio entre el 30% y el 40%.
  Funciona mejor empezar de nuevo e incluir desde el principio el contexto necesario que comprimir. Es efectivo organizar documentos Markdown por función en varias colecciones técnicas y, en la carga inicial, indicar dónde encontrar la información relacionada con la tarea.

• En Codex nunca sentí que el tamaño del contexto fuera un problema. No sé cómo comprime, pero sigue avanzando como si no hubiera límite.

  • Parece que empezaste a usar Codex hace poco. Al principio eran graves los errores model context size exceeded que ni siquiera la compresión podía recuperar, y desaparecieron apenas hace unos meses.
    Ahora está mucho mejor, pero después de comprimir no muestra qué entró en el concise summary, así que es difícil saber si se conservó lo importante.
    Codex parece ir en la dirección de ocultarle todo lo posible al usuario; así como recientemente cifró los prompts entre el agente y los subagentes, parece que también podría cifrar todo el log de la sesión. Es una lástima, pero de todo lo que he probado hasta ahora sigue siendo la mejor combinación de herramienta y modelo.
  • Cuando ocurre una compresión, Codex suele olvidar completar la última tarea, especialmente si enviaste un mensaje justo antes de la compresión.
  • La mayoría de los problemas se pueden dividir y conquistar, así que la diferencia entre 300k y 400k casi no importa. Un agente de programación no es una conversación infinita.

• Por muy buena que sea la compresión, en proyectos grandes hay que leer muchos archivos. Los primeros 200 mil tokens se consumen muy rápido, pero después la velocidad baja.
  La mayoría de las sesiones de Fable no superan los 500 mil tokens, así que no necesitan compresión, pero en Codex hay que comprimir una y otra vez dentro de una misma sesión.

  • Creo que la razón por la que hay que leer tantos archivos es que agents.md está mal hecho. Solo debería hacer falta leer el archivo real de trabajo y algunos archivos relacionados; el resto debería estar resumido en la documentación.

• Para mi trabajo es un tamaño bastante pequeño. Intento mantenerme por debajo de 200k, pero cuando fuerzo la última iteración en sesiones de DeepSeek y MiMo, a veces llegan a 350k tokens antes de comprimir.
  Me pregunto si OpenAI no podría adoptar la tecnología de caché K/V de DeepSeek, publicada en papers, para reducir mucho los costos.

  • Como nadie cachea tan bien como DeepSeek, parece que la diferencia de implementación es grande y difícil de imitar.
    Si usas DeepSeek con Reasonix, tiene un método adicional dedicado y adaptado a la estructura de caché, por lo que en sesiones largas se cachea entre el 97% y el 98% de los tokens. Un modelo que ya era barato se vuelve todavía más barato.
  • En modelos abiertos locales basados en llamacpp, el agente comprime por instrucción entre 55k y 85k, y salvo que se necesite sí o sí un contexto grande, como para rastrear logs complejos, rara vez llega a 120k.
    También ajusté el prompt del sistema para que, según el presupuesto de inferencia y los mensajes de llamacpp, el agente cree subagentes y luego comprima el contenido. Uso la poda dinámica de contexto de opencode para mantener la dirección sin inflar el volumen, y en general funciona bien para desarrollar iterativamente varios subcomponentes.

• Durante los últimos dos meses me fue mucho mejor para mi uso, así que pasé de Claude a OpenAI. Me da curiosidad si con este cambio se va a notar una diferencia en la calidad de salida.