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

Artículo original ↗ Discusión en Hacker News ↗

OpenAI ha reducido temporalmente la ventana de contexto de su agente de programación Codex de 372k a 272k tokens, lo que ha generado debate sobre el ahorro de costos frente a la capacidad para proyectos de software grandes y de larga duración. Muchos usuarios informan que la compactación agresiva y opaca del historial de conversación y del contexto de código puede desbaratar flujos de trabajo complejos, especialmente al trabajar en bases de código grandes, múltiples repositorios o archivos de reglas extensos, mientras que otros sostienen que una buena planificación, subagentes y “memoria” externa en markdown compensan en gran medida ventanas más pequeñas y evitan pérdidas de calidad con contextos muy largos. Las comparaciones con los modelos de un millón de tokens de Anthropic y el caching al estilo DeepSeek resaltan una tensión más amplia: si las herramientas punteras deben priorizar un contexto bruto masivo o una gestión de contexto más inteligente y controlable, junto con un mejor diseño del harness.

Reducción del tamaño de contexto y motivo

  • La ventana de contexto de Codex se redujo de 372k a 272k tokens; el commit y los tuits sugieren que es una medida temporal de control de costos/uso, no un cambio de capacidades.
  • Algunos señalan que esto evita activar niveles de contexto largo más caros que antes impactaban a los usuarios de forma inesperada.
  • Un comentario señala que los modelos subyacentes pueden manejar hasta 1M de contexto, pero los límites del cliente de Codex son más bajos para mantener el total (entrada + salida máxima) por debajo de un umbral de facturación.

Entendiendo el gráfico de costos y trayectoria

  • Varios lectores encontraron confuso el gráfico de costos publicado; otros lo explicaron como un costo acumulativo que aumenta aproximadamente de forma cuadrática con el número de turnos hasta la compactación, con un contexto menor (p. ej., 200k) dando una trayectoria consistentemente más barata que uno mayor (300k).
  • Hay desacuerdo sobre si la curva refleja atención cuadrática o solo costos lineales acumulativos.

Impacto en cargas de trabajo reales

  • Un grupo considerable dice que 272k es demasiado pequeño para grandes bases de código, ingeniería inversa o flujos de trabajo con muchos planes, revisiones y agentes de larga duración; a menudo se sitúan cerca del límite y sufren compactaciones frecuentes.
  • Otros sostienen que la mayoría de los problemas pueden y deben descomponerse en fragmentos por debajo de ~200–300k, y que contextos más pequeños ofrecen mejor calidad y menor costo.

Compactación: calidad, control y soluciones

  • Muchos se quejan de la compactación automática de Codex:
    • Se activa alrededor del 10–20% de contexto restante sin forma de desactivarla o revertirla.
    • A veces hace que el modelo “olvide” tareas recientes o código leído previamente, obligando a volver a escanear y gastando tokens.
  • Otros informan que la compactación de Codex ha mejorado significativamente desde versiones anteriores y les funciona bien.
  • Estrategias comunes para mitigar:
    • Usar archivos markdown de “plan”/“rules”/“report” como memoria duradera en lugar de depender del historial del chat.
    • Usar de forma agresiva subagentes, planificación jerárquica y herramientas externas que guarden y reinyecten contexto previo.
    • Reiniciar manualmente sesiones o limpiar contexto alrededor de 200–300k.

Comparaciones con otros modelos y harnesses

  • Varios usuarios dicen que se quedarán con o migrarán a modelos con ~1M de contexto (p. ej., Anthropic, DeepSeek, otros), pese a una degradación similar después de unos pocos cientos de miles de tokens.
  • Otros afirman que el marketing de contexto largo exagera el contexto realmente utilizable; ven una “zona tonta” a partir de 120–300k en muchos modelos.
  • Algunos prefieren alternativas de código abierto o de terceros con compactación ajustable, árboles de historial y mayor control del usuario.

Seguridad y diseño del harness

  • El mismo commit añade una guía más estricta en el system prompt antes de acciones destructivas (p. ej., no borrar recursivamente directorios home o root), en respuesta a casos reales de borrado masivo accidental.
  • Hay apoyo para más aislamiento (contenedores, wrappers protegidos para rm) y escepticismo sobre permitir que los agentes ejecuten comandos destructivos en absoluto.