GPT-5.5 Codex y el bug que baja rendimiento

Si usas Codex o estás evaluando GPT-5.5 para tareas de programación, este tipo de incidente te debería interesar aunque nunca hayas tocado el código interno del producto. El problema no apunta solo al modelo en sí, sino a cómo se están agrupando y gestionando los reasoning tokens, y a la infraestructura que los transporta, los mide y los convierte en respuestas útiles.

En palabras simples: puedes tener un modelo muy capaz y aun así ver peor rendimiento si la capa que organiza su razonamiento se atasca, se fragmenta o se vuelve más cara de procesar. Eso cambia la conversación. Ya no basta con preguntar “¿qué tan bueno es el modelo?”, también tienes que preguntar “¿cómo se está ejecutando, cuánto cuesta cada paso y dónde se está perdiendo tiempo?”.

Qué se reportó en Codex

El hilo público del issue en GitHub apunta a una posible degradación de rendimiento asociada al clustering de reasoning tokens en Codex. La idea detrás del reporte es que no todos los tokens se comportan igual: algunos forman bloques de razonamiento que ayudan al modelo a planificar, y si esos bloques se agrupan de forma poco eficiente, el sistema puede terminar rindiendo peor. La fuente del caso está aquí: https://github.com/openai/codex/issues/30364.

No estamos hablando de una simple queja de “va lento”. El matiz es más técnico. Un sistema de coding assistant puede responder bien en prompts cortos, pero empezar a fallar cuando la tarea requiere más pasos internos, más contexto o más coordinación entre herramientas. Ahí es donde el manejo de tokens de razonamiento se vuelve parte del producto, no solo un detalle de implementación.

También hay una lección práctica para equipos de producto: el rendimiento percibido por el usuario final no depende únicamente del modelo base. Depende de cómo se empaquetan las inferencias, de la latencia de la orquestación, de la cantidad de tokens que se consumen antes de mostrar el primer resultado y de si el sistema está priorizando calidad o velocidad en el momento correcto.

Qué significa “clustering” en este contexto

Cuando hablamos de clustering de reasoning tokens, no hablamos de clustering en el sentido clásico de machine learning sobre datos estáticos. Hablamos de cómo se agrupan internamente secuencias de tokens que representan pasos de razonamiento, planificación o descomposición de tareas. Si esos grupos se compactan demasiado o se distribuyen mal, el modelo puede perder eficiencia.

Piensa en una tarea como refactorizar una función con pruebas asociadas. El sistema no solo genera texto; también organiza pasos: entender el código, identificar dependencias, proponer cambios, validar riesgos y devolver una respuesta. Si esa cadena interna se vuelve más pesada de lo necesario, el usuario ve más latencia o resultados menos consistentes.

Por qué esto importa más que un benchmark aislado

Un benchmark te puede decir que un modelo alcanza cierto puntaje en una prueba cerrada. Pero en producción tú no ejecutas una prueba cerrada, ejecutas flujos reales con contexto variable, picos de uso y herramientas alrededor. Si el problema está en la gestión de reasoning tokens, el benchmark puede verse bien y aun así el producto degradarse en tareas largas o repetitivas.

Por eso este caso importa para equipos en Latinoamérica, donde muchas veces se trabaja con presupuestos ajustados, conexiones menos estables y usuarios que no toleran esperas largas. Una diferencia de 800 ms por interacción puede parecer pequeña en papel, pero en una sesión de 20 interacciones ya son 16 segundos extra de fricción.

Por qué el modelo no es toda la historia

Cuando una herramienta de IA para programar se siente más lenta o menos precisa, la reacción típica es culpar al modelo. A veces sí es el modelo. Pero otras veces el problema está en la capa que lo rodea: routing, batching, caching, tool calls, límites de contexto y manejo de tokens internos.

Esto es especialmente visible en sistemas tipo agentic coding, donde el modelo no solo responde una vez. Tiene que leer archivos, razonar sobre cambios, pedir herramientas, reintentar y consolidar resultados. Cada una de esas etapas añade carga. Si el pipeline se diseña mal, el costo crece aunque el modelo central siga siendo el mismo.

OpenAI documenta varias piezas de este ecosistema en su documentación de API y en guías de uso del modelo. Si quieres revisar la referencia oficial de codificación y uso de modelos, puedes partir de la documentación general de OpenAI: https://platform.openai.com/docs. Para entender mejor la lógica de tokens y contexto, también conviene revisar la guía de tokenización y límites de contexto en la documentación correspondiente.

Tokens de razonamiento vs tokens visibles

No todos los tokens que procesa un sistema se muestran al usuario. Algunos forman parte del razonamiento interno, otros de la respuesta final y otros de la coordinación con herramientas. Esa separación importa porque el usuario juzga la experiencia por una sola cosa: si obtuvo una respuesta útil en un tiempo razonable.

Si el sistema consume demasiados recursos en la parte invisible, puedes terminar con una respuesta final correcta pero tardía. Y en una herramienta de desarrollo, una respuesta tardía muchas veces equivale a una respuesta mala, porque interrumpe el flujo de trabajo.

Infraestructura: la parte que nadie mira hasta que falla

La infraestructura también puede amplificar un problema pequeño. Un clustering menos eficiente puede aumentar la presión sobre colas, memoria, serialización y enrutamiento interno. Si además el sistema está sirviendo múltiples usuarios al mismo tiempo, el impacto se multiplica.

En términos prácticos, eso significa que una degradación no siempre se ve como un error visible. A veces se ve como respuestas más largas, más reintentos, más variación entre una ejecución y otra y una sensación general de inconsistencia. Para un equipo de ingeniería, esa variación ya es una señal de alerta.

Cómo detectar si te está afectando

Si trabajas con Codex o con cualquier asistente de código basado en LLM, lo primero es dejar de mirar solo la respuesta final. Necesitas medir el recorrido completo: tiempo al primer token, tiempo total, cantidad de tool calls, tokens consumidos y tasa de reintentos. Sin eso, cualquier diagnóstico es intuición.

Una forma útil de empezar es comparar sesiones parecidas. No necesitas un laboratorio sofisticado para ver patrones. Con 20 a 30 ejecuciones de la misma tarea, ya puedes detectar si el sistema se volvió más errático. Por ejemplo, si antes una refactorización tardaba 12 segundos y ahora tarda 19 con la misma entrada, algo cambió.

Aquí tienes una tabla simple para ordenar señales y posibles causas:

Métricas mínimas que sí deberías guardar

Si tienes acceso a observabilidad, guarda estas métricas por request:

1. Tiempo hasta el primer token.
2. Tiempo total de respuesta.
3. Número de tokens de entrada y salida.
4. Número de llamadas a herramientas.
5. Número de reintentos o fallos parciales.
6. Tamaño del contexto efectivo usado en la tarea.

Con esos seis datos ya puedes construir una línea base. No hace falta que adivines si el modelo “se puso peor”; puedes comparar semanas, versiones o incluso configuraciones distintas del mismo prompt.

Un ejemplo realista de diagnóstico

Supón que tu equipo usa un asistente para revisar PRs. Durante dos semanas, el tiempo medio por revisión era de 9.8 segundos. Luego sube a 14.1 segundos sin cambiar el tamaño promedio del diff. Si además notas que el número de tool calls pasa de 2.1 a 3.7 por tarea, el problema no parece ser solo “el modelo escribe más”. Parece más bien una degradación en la coordinación interna.

En ese caso, cambiar de prompt puede ayudar, pero no basta. También deberías revisar si el sistema está agregando demasiado contexto, si el parser de archivos está enviando ruido, o si el backend está reintentando pasos que antes resolvía a la primera.

Qué puedes hacer mientras se corrige

Si sospechas que tu flujo está sufriendo por este tipo de degradación, no te quedes esperando un parche. Hay varias medidas prácticas que puedes aplicar desde ya para reducir el impacto en tu equipo.

Lo primero es acotar el contexto. Si estás enviando archivos completos cuando solo necesitas una función, reduce el input. Menos contexto no siempre significa peor respuesta; muchas veces significa menos ruido y menos latencia. En asistentes de código, el exceso de contexto suele castigar más que ayudar.

Lo segundo es separar tareas. No le pidas al modelo que haga análisis, refactor, pruebas y documentación en una sola pasada si no es necesario. Divide el trabajo en pasos más pequeños y mide cuál tramo introduce más demora o más errores.

Acciones concretas para equipos de producto e ingeniería

• Limita el tamaño de los archivos o fragmentos enviados cuando la tarea lo permita.
• Registra latencia por tipo de tarea, no solo un promedio global.
• Compara prompts cortos y prompts largos con la misma tarea.
• Revisa si las herramientas externas están agregando cuello de botella.
• Define una versión de referencia del flujo para detectar regresiones.

Si trabajas con usuarios en Ecuador, México, Colombia o Argentina, piensa también en el costo de la espera en conexiones variables. Un sistema que tarda 2 segundos más en una oficina con buena red puede tardar mucho más en un entorno con jitter o pérdida de paquetes. La experiencia final no se mide solo en el servidor.

Cuándo vale la pena escalar el incidente

Escala el problema si ves una caída sostenida de rendimiento en tareas equivalentes, no solo un pico aislado. También si el aumento de latencia viene acompañado de más reintentos, más errores de herramienta o resultados menos consistentes. En ese punto ya no estás frente a una simple variación normal.

Si tienes acceso a soporte del proveedor, reporta ejemplos concretos. Incluye timestamps, tipo de tarea, longitud del prompt, número de tokens aproximados, latencia y cualquier cambio de versión o configuración. Un reporte con datos se atiende mejor que una descripción genérica de “está peor”.

Lo que este caso dice sobre el futuro de Codex

Este incidente deja una idea clara: los asistentes de programación ya no se evalúan solo por su inteligencia aparente. También se evalúan por su economía interna, por cómo administran el razonamiento y por qué tan bien se integran con la infraestructura que los hace útiles en producción.

Eso cambia la forma en que deberías comprar, integrar o auditar estas herramientas. Si tu equipo depende de IA para acelerar PRs, generar tests o explorar código legado, necesitas observabilidad del mismo nivel que usarías para una API crítica. El modelo importa, sí, pero la capa operativa puede arruinar la experiencia incluso con un modelo fuerte.

Para seguir el estado oficial del producto y revisar documentación de OpenAI sobre modelos, contextos y uso de la API, la referencia más segura sigue siendo la documentación oficial: https://platform.openai.com/docs. Y para el caso puntual de este bug, el hilo público en GitHub es la fuente primaria del reporte.

La lección para equipos en LatAm

En Latinoamérica solemos operar con más fricción que en otros mercados: menos margen para sobrecostos, más presión por entregar rápido y menos tolerancia a herramientas que prometen más de lo que cumplen. Por eso estos detalles técnicos sí importan. No son discusiones de laboratorio, son diferencias que terminan afectando productividad y presupuesto.

Si una herramienta te ahorra 30 minutos al día pero introduce inestabilidad, igual tienes que medir el costo real. A veces el problema no está en la capacidad del modelo, sino en que el sistema alrededor no está diseñado para sostener esa capacidad a escala.

Tabla resumen

Si quieres sacar una conclusión útil de este caso, quédate con esta: en herramientas de IA para desarrollo, el rendimiento no depende solo del modelo que está en la portada. Depende de cómo se manejan sus tokens internos, de cómo se orquesta cada paso y de si la infraestructura está preparada para sostener ese flujo sin degradarse.