OpenAI recorta el contexto de Codex

OpenAI movió una pieza que, a primera vista, parece menor: redujo el tamaño de contexto de Codex de 372k a 272k tokens. No es el tipo de cambio que te obliga a reescribir todo tu stack, pero sí es una señal clara de que el producto se está ajustando para operar mejor en la práctica. Cuando un proveedor recorta contexto, normalmente lo hace porque está afinando costos, latencia, estabilidad o una mezcla de las tres.

Si tú ya estás usando agentes de código para revisar PRs, generar cambios en varios archivos o iterar sobre repos grandes, este tipo de ajuste importa. No porque 100k tokens menos sean un drama por sí solos, sino porque te obligan a pensar mejor cómo alimentas el modelo, qué guardas en memoria y qué parte del trabajo conviene delegar a herramientas externas en lugar de meterlo todo en una sola conversación.

Qué cambió exactamente en Codex

La referencia viene del propio repositorio de OpenAI Codex, donde en un pull request se observa el cambio de 372k a 272k tokens como tamaño de contexto del modelo. La cifra es concreta y el recorte también: son 100k tokens menos, que en términos prácticos es bastante espacio para código, logs, instrucciones y resultados intermedios. Fuente: OpenAI Codex PR 33972.

No estamos hablando de una caída de rendimiento confirmada ni de una limitación pública explicada línea por línea por OpenAI. Lo que sí se puede leer entre líneas es que el equipo está optimizando el comportamiento del producto. En modelos y agentes, el contexto no es solo una “capacidad”; también es una variable de costo. Más contexto suele implicar más carga de inferencia, más tiempo de procesamiento y más riesgo de que el modelo se distraiga con ruido si tú no ordenas bien la entrada.

Por qué 100k tokens sí te deberían importar

Para ponerlo en números simples, 100k tokens equivalen a bastante material de trabajo. Dependiendo del lenguaje y del tipo de contenido, puedes estar hablando de decenas de miles de líneas de código, documentación interna o una mezcla de instrucciones y diffs. Si tú usas Codex como agente para tareas largas, ese recorte puede cambiar cómo diseñas el flujo.

En la práctica, el impacto no es igual para todos. Si tu agente solo hace tareas acotadas, como corregir una función o redactar tests para un módulo pequeño, probablemente no notes nada. Si en cambio le pasas un monorepo parcial, múltiples archivos de contexto y un historial largo de instrucciones, sí vas a sentir la diferencia en cómo prioriza información y en cuánta basura puedes dejarle pasar.

Lo que no sabemos todavía

No hay, al menos en este cambio puntual, una explicación pública detallada que diga “bajamos el contexto porque X”. Así que no conviene inventar una causa única. Podría ser una decisión de infraestructura, una forma de reducir costo por request, una medida para bajar latencia o un ajuste para mejorar la calidad efectiva al limitar entradas demasiado largas.

También puede haber un componente de producto: a veces más contexto no significa mejor resultado. En agentes de código, demasiada información puede hacer que el modelo mezcle versiones viejas, arrastre instrucciones contradictorias o se pierda en archivos que no aportan. Menos contexto, bien usado, puede obligarte a construir sistemas más limpios.

Qué puede estar optimizando OpenAI

Cuando un proveedor de IA reduce contexto, normalmente hay cuatro sospechosos principales: costo, latencia, calidad y estabilidad operativa. No siempre se trata de uno solo. En productos que atienden muchas solicitudes de desarrollo, la combinación importa más que el número aislado.

Si OpenAI ajustó Codex hacia 272k, una lectura razonable es que quiere un punto más equilibrado entre capacidad y eficiencia. Eso tiene sentido si el producto está orientado a tareas de programación reales, donde el valor no está en aceptar cadenas gigantes, sino en responder bien con suficiente información relevante.

Costo y latencia: la parte que más duele en producción

Más contexto suele significar más trabajo para el modelo. Aunque el costo exacto depende de la arquitectura y del proveedor, tú ya sabes cómo se traduce eso en producto: respuestas más lentas, mayor gasto por interacción y menos margen para escalar agentes que se ejecutan muchas veces al día.

Si tu equipo corre 500, 5,000 o 50,000 interacciones semanales, una mejora pequeña en latencia o costo por request se nota rápido. Un agente que tarda 12 segundos en vez de 8 segundos cambia la percepción del usuario. Y si cada consulta consume menos recursos, puedes permitir más iteraciones sin disparar la factura.

Calidad: menos ruido, más señal

Hay otro punto menos obvio: el contexto largo no siempre mejora la calidad. En tareas de código, el modelo puede verse afectado por archivos irrelevantes, conversaciones viejas o instrucciones duplicadas. Cuando le das demasiado, a veces baja la precisión porque el sistema de atención tiene que repartir foco entre demasiadas cosas.

Por eso, recortar contexto puede ser una forma de empujar a los equipos a usar mejores estrategias de selección. En vez de mandar todo, mandas lo necesario. En vez de confiar en memoria infinita, haces retrieval, resumidos y ventanas de trabajo más pequeñas.

Qué cambia para tus flujos de trabajo con agentes de código

Si tú construyes o usas agentes de programación, este cambio te deja una lección bastante clara: no diseñes tu flujo asumiendo que siempre tendrás un contexto enorme. Diseña para contexto limitado, aunque el modelo soporte bastante. Eso te da más control, menos costo y menos dependencia de una sola llamada gigante.

OpenAI no publicó aquí una guía de migración específica, así que no hay que dramatizar. Pero sí puedes aprovechar el momento para revisar cómo estás armando tus prompts, qué archivos seleccionas y qué estado guardas fuera del modelo. En agentes, el contexto es como la memoria RAM: útil, pero no infinita ni barata.

Señales de que tu agente está mal alimentado

Hay síntomas muy concretos de que estás metiendo demasiado ruido al modelo:

1. El agente repite instrucciones que ya le diste varias veces.
2. Empieza a tocar archivos que no tienen relación con la tarea.
3. Genera cambios inconsistentes entre un archivo y otro.
4. Tarda demasiado en responder para tareas simples.
5. Pierde el hilo cuando el historial supera varias iteraciones.

Si ves dos o más de esas señales de forma frecuente, no necesitas más contexto. Necesitas mejor selección de contexto.

Qué conviene mover fuera del prompt

No todo tiene que vivir dentro de la ventana de contexto. De hecho, cuanto más trabajo de ingeniería hagas alrededor del modelo, mejor suele salir el resultado. Una arquitectura razonable para agentes de código separa claramente memoria, recuperación y ejecución.

Puedes pensar en esto así:

• Resúmenes de estado en lugar de historial completo.
• Recuperación por archivos relevantes, no por carpeta completa.
• Herramientas para leer el repo en tiempo real, en vez de volcar todo el contenido.
• Validación automática con tests, linters y type checks fuera del modelo.
• Instrucciones estables en un system prompt corto y preciso.

La idea no es limitar por capricho. La idea es que el modelo vea lo que necesita para tomar una buena decisión y nada más.

Cómo adaptar tu arquitectura si usas Codex o agentes similares

Aquí es donde el cambio deja de ser noticia y se vuelve trabajo real. Si tu producto depende de Codex o de un agente parecido, te conviene revisar el pipeline completo, no solo el prompt. La reducción de contexto te obliga a ser más intencional con cada token que envías.

Un flujo bien armado no intenta “meter todo”. Un flujo bien armado decide qué entra, qué se resume, qué se consulta bajo demanda y qué se verifica con herramientas. Eso vale tanto si trabajas en Quito como si estás en Medellín, Buenos Aires o Ciudad de México.

Patrón práctico para tareas de código

Un esquema útil para no depender de contexto gigante puede verse así:

const workflow = [
  "Detectar archivos relevantes",
  "Leer solo el diff y dependencias directas",
  "Resumir estado anterior en 10-15 líneas",
  "Enviar instrucciones concretas al agente",
  "Ejecutar tests y recopilar errores",
  "Iterar solo con la información nueva"
]

Ese tipo de flujo reduce el ruido desde el inicio. No necesitas que el modelo vea el repo entero si la tarea afecta tres archivos y dos tests. Tampoco necesitas arrastrar conversaciones antiguas si ya tienes un resumen confiable del estado actual.

Tabla práctica de decisiones

Si tú trabajas con agentes en producción, esta tabla te sirve como regla operativa. El objetivo es que el modelo reciba información útil, no una avalancha de texto que le quite foco.

Qué deberían mirar equipos en LatAm y Ecuador

Para equipos de Latinoamérica, el tema tiene una lectura muy concreta: costo y latencia pesan más cuando operas con presupuestos ajustados o con usuarios que esperan respuestas rápidas. No siempre puedes absorber una arquitectura que dependa de contextos gigantes y llamadas largas.

En Ecuador, por ejemplo, muchas startups y equipos internos trabajan con recursos limitados y con stacks que necesitan ser simples de mantener. Un ajuste como este te recuerda que el valor no está en usar el modelo más grande posible, sino en construir un flujo que sea predecible, medible y barato de operar.

Tres decisiones que puedes tomar ya

1. Audita cuántos tokens usas por interacción y dónde se van.
2. Separa instrucciones estables, memoria temporal y datos recuperados.
3. Mide latencia por tipo de tarea, no solo el promedio general.

Si haces eso, vas a detectar rápido si tu agente depende demasiado de contexto largo. Y si descubres que sí, todavía mejor: puedes corregir antes de que el problema te pegue en costos o en calidad.

Métricas que sí valen la pena seguir

No hace falta una observabilidad sofisticada para empezar. Con cinco métricas ya puedes tomar decisiones mejores:

• Tokens de entrada por tarea.
• Tokens de salida por tarea.
• Latencia p50 y p95.
• Tasa de reintento del agente.
• Número de archivos tocados por cambio.

Si esas métricas suben al mismo tiempo, tu flujo probablemente está demasiado cargado. En ese punto, recortar contexto no es una pérdida; es una oportunidad para rediseñar.

Lo que esta señal dice sobre el futuro de los agentes

La reducción de contexto en Codex no significa que los agentes van a ser menos útiles. Significa que el mercado está entrando en una etapa más madura, donde la eficiencia pesa tanto como la capacidad bruta. Ya no basta con que el modelo “aguante mucho texto”. Tiene que hacerlo bien, rápido y sin disparar costos.

Para quienes construyen sobre estos sistemas, la señal es sana. Te empuja a separar problemas, usar mejor la recuperación, escribir prompts más cortos y dejar que las herramientas hagan parte del trabajo que antes intentabas resolver solo con contexto. Eso suele producir mejores sistemas.

El cambio de mentalidad que conviene adoptar

En vez de pensar “¿cuánto contexto me deja el modelo?”, piensa “¿cuál es el mínimo contexto necesario para resolver esta tarea con precisión?”. Esa pregunta cambia la arquitectura completa. También te ayuda a detectar cuándo estás usando IA como pegamento para un diseño flojo.

Si tu agente necesita ver 200 archivos para arreglar un bug, probablemente el problema no es el límite del modelo. El problema es cómo estás representando el estado del sistema. Ahí es donde conviene invertir tiempo.

Tabla resumen

La lectura útil no es “OpenAI quitó contexto y ya”. La lectura útil es que los agentes de código están entrando en una fase donde la ingeniería alrededor del modelo importa tanto como el modelo mismo. Si tú trabajas con Codex o con herramientas parecidas, este cambio te conviene como recordatorio: menos ruido, más estructura.