El clustering de tokens de razonamiento de GPT-5.5 Codex podría causar una baja de rendimiento

• El issue #30364 de OpenAI Codex reporta que los reasoning_output_tokens en respuestas de gpt-5.5 tienden a concentrarse en valores fijos como 516, 1034 y 1552, y que este fenómeno podría estar relacionado con una degradación de calidad en tareas complejas de Codex
• El análisis abarca metadatos token_count de Codex entre el 1 de febrero y el 27 de junio de 2026 UTC; se confirmaron 390,195 registros de respuestas y 3,363 eventos exactos de 516 en 865 sesiones
• gpt-5.5 representó el 19.3% de todas las respuestas, pero concentró el 82.0% de los eventos exact-516; entre los casos con reasoning_output_tokens >= 516, la proporción exacta de 516 fue de 44.0%, muy por encima del 1.3% de los modelos que no eran GPT-5.5
• La proporción mensual de exact-516 subió de 0.11% en febrero de 2026 a 53.30% en mayo y 35.84% en junio, pero en el mismo período el promedio y el P90 de tokens de razonamiento bajaron, por lo que no parecía tratarse simplemente de un aumento en el uso de tokens de razonamiento
• En comentarios posteriores se compartieron casos similares de clustering en 516 y algunas reproducciones de respuestas incorrectas en Codex CLI, Codex Desktop y OpenCode; también se propuso como mitigación temporal un proxy local que detecta el patrón 518·n−2 y continúa el razonamiento

---

El problema central del issue

• El issue #30364 de Codex reporta un patrón de concentración excesiva en reasoning_output_tokens = 516 dentro de los metadatos token_count de respuestas de gpt-5.5
• Además, se afirma que también aparecen picos cerca de 1034 y 1552, como si fueran límites fijos
• El alcance planteado no afirma demostrar un corte del chain-of-thought oculto
  • La afirmación más acotada es que en la telemetría de Codex aparece una anomalía de clustering de tokens fijos específica de gpt-5.5
  • El planteo es que este patrón parece consistente con un comportamiento de presupuesto de razonamiento basado en umbrales
• El issue relacionado #29353 trataba una reproducción a nivel de unidad de trabajo donde una ejecución de gpt-5.5 terminaba exactamente en 516 reasoning tokens y devolvía una respuesta incorrecta; este nuevo issue agrega evidencia agregada de un período más amplio

Entorno de análisis y datos

• El producto es Codex y el modelo más relevante es gpt-5.5
• La fuente de datos son los metadatos token_count de Codex
• El período analizado es del 1 de febrero al 27 de junio de 2026 UTC
• Cifras agregadas:
  • Registros de tokens a nivel de respuesta: 390,195
  • Sesiones: 865
  • Eventos exactos de reasoning_output_tokens = 516: 3,363
  • Proporción de gpt-5.5 sobre el total de respuestas: 19.3%
  • Proporción de eventos exact-516 correspondientes a gpt-5.5: 82.0%
  • Ratio exact-516 / >=516 de gpt-5.5: 44.0%
  • Ratio exact-516 / >=516 de modelos no GPT-5.5: 1.3%

Patrones por modelo y por mes

• El ratio exact 516 / >=516 por modelo es más marcado en gpt-5.5
  • gpt-5.5: 75,401 registros, 44.0%
  • gpt-5.4: 25,214 registros, 19.8%
  • gpt-5.2: 247,575 registros, 0.34%
  • gpt-5.3-codex: 13,333 registros, 0.0%
  • gpt-5.3-codex-spark: 26,179 registros, 0.0%
• El clustering mensual en exact-516 aumentó con fuerza en mayo de 2026
  • Febrero: 0.11%
  • Marzo: 2.45%
  • Abril: 4.25%
  • Mayo: 53.30%
  • Junio: 35.84%
• En el mismo período, la intensidad total de tokens de razonamiento bajó
  • Promedio de reasoning tokens: febrero 268.1 → mayo 106.9 → junio 168.5
  • P90 de reasoning tokens: febrero 772 → mayo 344 → junio 515
• Debido a esta combinación, se plantea que el aumento de exact-516 es difícil de explicar como un simple incremento en el uso de tokens de razonamiento

Elementos de verificación interna solicitados

• Se solicita al equipo de Codex investigar si el presupuesto de razonamiento, el routing, los cortes, el fallback o el comportamiento del scheduler de gpt-5.5 pueden provocar terminaciones cerca de 516/1034/1552
• Si ese comportamiento es intencional, también se pide aclarar si exact 516 es un punto normal de finalización, un límite de presupuesto, un tier degradado u otro umbral interno
• Procedimiento de verificación propuesto:
  • Consultar eventos token_count que incluyan reasoning_output_tokens por modelo
  • Comparar conteos de valores exactos 0, 516, 1034, 1552
  • Calcular por modelo y fecha count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516)
  • Comparar gpt-5.5 con gpt-5.2, gpt-5.4 y variantes dedicadas de Codex
  • Reejecutar tareas complejas en GPT-5.2 y GPT-5.5, y evaluar calidad separando respuestas exact-516 y respuestas con razonamiento más largo

Reproducciones adicionales y datos cruzados en los comentarios

• GitHub Actions marcó #29353 como posible duplicado relacionado
• Varios usuarios comentaron que habían experimentado el mismo problema, y uno evaluó este issue como un reporte más basado en datos que el issue anterior
• sinnet3000 presentó datos cruzados de clientes desde almacenes locales de sesiones de Codex CLI y OpenCode
  • En unos 22.7k eventos token_count de Codex ~/.codex/sessions y archived_sessions, gpt-5.5 tuvo 4,300 records, 156 >=516, 88 exact 516, ratio 56.4%
  • En unos 32.1k assistant messages de OpenCode opencode.db, gpt-5.5 tuvo 6,977 records, 126 >=516, 90 exact 516, ratio 71.4%
  • En cerca de 24k records agregados de modelos no OpenAI con volumen, incluidos Kimi, DeepSeek, MiMo, MiniMax, Gemini, Qwen y GLM, hubo 0 casos exact 516
  • Estos datos incluyen la salvedad de que no se evaluó si las respuestas eran correctas o incorrectas; solo se verificó la existencia del clustering exacto en 516
• kyleboddy reportó diferencias de comportamiento relacionadas en Codex Desktop sobre Windows 11
  • Ejecutó el mismo prompt de candy en 5 threads frescos de Codex Desktop sin proyecto
  • Las ejecuciones rápidas con direct-final_answer devolvieron 29, una respuesta incorrecta
  • Las ejecuciones más lentas que primero emitían commentary devolvieron 21, la respuesta correcta
  • Indicó que en threads frescos de Desktop en Windows no pudo extraer reasoning_output_tokens exactos, por lo que no puede afirmar que la ejecución incorrecta haya sido exactamente de 516
• El mismo usuario también agregó el clustering de valores fijos de gpt-5.5 / xhigh en metadatos de sesiones locales
  • records 16,141, sessions 51, razonamiento promedio 149.7, P90 429
  • =516 438 casos, >=516 1,298 casos, ratio 33.74%
  • =1034 52 casos, =1552 14 casos, =2070 16 casos, =2588 12 casos, =3106 5 casos

Resultado de la reproducción en Codex Linux CLI

• kyleboddy dijo haberlo reproducido también en Codex Linux CLI usando el mismo prompt de candy
• Entorno:
  • Producto: Codex CLI
  • Versión: codex-cli 0.142.5
  • Plataforma: Ubuntu Linux 6.8.0-111-generic, x86_64
  • Node: v24.14.0
  • Modo de autenticación: ChatGPT
  • Modelo probado: gpt-5.5
  • reasoning efforts: xhigh, high
  • Modelo de control: gpt-5.4 xhigh
• El prompt pedía no usar herramientas externas y preguntaba por la cantidad mínima de extracciones en un problema de una bolsa de caramelos donde la forma puede distinguirse al tacto
• La respuesta esperada se confirmó de forma independiente mediante enumeración brute-force como 21
  • Se incluye la explicación de que, dado que la forma puede distinguirse al tacto, es posible planificar 9 caramelos redondos + 12 caramelos estrella
• Resultados:
  • Las 4 ejecuciones completadas de gpt-5.5 xhigh tuvieron todas reasoning_output_tokens = 516, con respuestas finales 23, 26, 28, 15, todas incorrectas
  • Las 3 ejecuciones de gpt-5.5 high también fueron todas de 516, con respuestas 22, 21, 27, solo una correcta
  • Las 3 ejecuciones de gpt-5.4 xhigh usaron 6211, 12274 y 10876 reasoning tokens, y todas respondieron 21, correctamente
• Este resultado refuerza la afirmación acotada de que gpt-5.5 puede entrar en Codex en una ruta fija de 516 tokens y que esa ruta puede correlacionarse con una degradación de calidad en la tarea

Propuesta de workaround temporal

• dzshzx propuso codexcomp, un proxy local de Responses para poner delante de Codex mientras se espera un fix upstream
• Su funcionamiento considera el patrón 518·n−2 como corte y continúa el razonamiento
  • Los rounds que terminan con reasoning_tokens == 518·n − 2, es decir 516, 1034, 1552, etc., se tratan como truncated
  • Descarta el tentative output y reproduce los reasoning items y encrypted_content de ese round como la siguiente entrada
  • Incluye phase:"commentary" y el mensaje "Continue thinking..."
  • Pliega todos los rounds en una única respuesta downstream para que Codex la vea como una respuesta completa
• La configuración usa la clave oficial top-level openai_base_url
  • Ejemplo: openai_base_url = "http://127.0.0.1:8787/v1";
  • Se afirma que se mantiene el provider built-in openai, por lo que session grouping, remote compaction y remote-control siguen funcionando
• Un ejemplo de logs reales muestra un caso en el que, tras dos 516 consecutivos, el tercer round termina limpiamente y la respuesta final es correcta
  • round 1: reason=516 → continue
  • round 2: reason=516 → continue
  • round 3: reason=291 → clean
• Salvedades:
  • Es un workaround no oficial y depende de comportamiento no contractual del upstream
  • Los continuation rounds usan tokens reales adicionales
  • Está limitado por una ventana n y un tope de 3 continuations
  • Es solo loopback, con auth passthrough, y afirma no leer ni guardar credenciales

[GN⁺]

Comentarios de Hacker News

• Esto parece bastante serio, y también se reproduce fácilmente con codex cli
  Si le das un prompt tipo acertijo que requiere razonamiento, a veces de pronto se corta y usa exactamente 516 tokens de pensamiento, dando una respuesta incorrecta
  Cuando usa entre 6000 y 8000 tokens de pensamiento, da la respuesta correcta
  Podría ser un problema del lado del pensamiento adaptativo (adaptive thinking), y esto también suma otro punto a favor de los modelos locales, ya que no tienes que preocuparte por cambios silenciosos del lado del servidor
  Corrí el mismo prompt 10 veces y en 4 apareció este problema de los 516 tokens; las 4 veces dio una respuesta incorrecta. La muestra es pequeña, pero parece que 5.5 xhigh puede truncarse con casi un 50% de probabilidad y perder rendimiento

  • Creo que también hay un problema filosófico con el pensamiento adaptativo. Es un enfoque en el que se “adivina” cuánto presupuesto de razonamiento asignar antes de empezar a pensar, pero en el contexto de un LLM parece que casi no hay forma de saber de antemano cuánto razonamiento hace falta, es decir, cuántos tokens habrá que generar
    El espacio de problemas es infinitamente amplio, y solo por la similitud entre prompts es difícil juzgar cuánto hay que pensar. El modelo ya deja de pensar incluso antes de llegar a su presupuesto de razonamiento
    No entiendo por qué se invierte tanto esfuerzo en implementar pensamiento adaptativo; más bien parecería que deberían entrenar mejor al modelo para emitir un token de fin de pensamiento
    Se siente como un parche. Al modelo deberían entrenarlo para hacer una cantidad adecuada de razonamiento: razonar → estimar la incertidumbre restante → decidir si continuar → razonar más → repetir
  • Con los modelos locales también hay que preocuparse por errores de configuración. Incluso los expertos se equivocan, así que el rendimiento de los modelos locales varía mucho según el proveedor
  • Me da curiosidad si se ve algún patrón al probar por franja horaria o por día de la semana. Por ejemplo, podría verse si los cortes ocurren más seguido en las horas pico de trabajo
  • Si el costo de esos tokens desperdiciados también lo paga el usuario, podría convenir pedir un reembolso

• Casi todos los días he visto caídas de calidad en escalones, y normalmente usaba xhigh
  La experiencia de depender de la programación excepcionalmente meticulosa de Codex que tenía a principios de este año ya desapareció, y como empezaron a salir implementaciones intermitentemente absurdamente tontas, me cambié a Claude hasta que OpenAI se tome este problema en serio
  En lo personal, lo vengo viendo desde hace meses y no parecía que OpenAI se lo estuviera tomando con la seriedad debida

  • Hace 3 meses Claude se había vuelto demasiado tonto y me cambié a Codex; hace 6 meses fue al revés. Sea Codex o Claude, tarde o temprano ambos te terminan fastidiando. Aun así, probablemente Codex es el menos malo
  • Desde principios de junio sentí que la confiabilidad de 5.5 había caído hasta el nivel de Claude, al menos en mi experiencia
    Por eso fui pasando de 5.5 high → 5.5 xhigh → 5.4 high
    5.4 high ha sido completamente estable durante las últimas 3 semanas y por ahora estoy conforme con eso
    De vez en cuando corro trabajos con 5.5 xhigh para ver si ya volvió a estar 100% estable, pero me parece que ahora mismo están esperando el lanzamiento de 5.6 en vez de arreglar este problema de confiabilidad
  • No creo que esto sea un problema técnico. Cuesta mucho dinero arreglarlo y, como los usuarios no pagan lo suficiente, lo veo como una decisión de negocio de bajar el rendimiento

• Me da una sensación de déjà vu. Se ve exactamente igual que la regresión de rendimiento de Claude Code de abril. En ese momento cancelé mi suscripción a Claude y me pasé a Codex
  Ahora estoy pensando en usar ambos con cobro por token y usar Fireworks con GLM 5.2 para la mayoría de las tareas, gastando en modelos grandes solo cuando haga falta. Igual no estoy seguro de que cierre económicamente

  • A mí también me pasó eso con el cobro por token, pero por principio quiero evitarlo porque a ambos laboratorios les conviene económicamente mover a los clientes a un esquema de consumo por token
    Aunque no sea intencional, no quiero aceptar ni habilitar una estructura en la que se gane dinero con un producto cuya calidad empeora
    Más que en cualquier otro momento desde el lanzamiento de ChatGPT, los modelos open source y los entornos de ejecución abiertos, como Pi, ahora me resultan mucho más atractivos
  • Sí. Yo también cancelé Claude Code por eso y me cambié a Codex
    Ahora estoy pensando cómo ganar 65.000 dólares extra para no tener que volver a preocuparme por esta tontería. Entiendo la lógica económica de cosas como OpenRouter
    Me recuerda a cuando por ahí de 2008 “la nube” empezó a ponerse de moda como término de marketing. Parecía una forma de bajar las expectativas sobre los clientes ricos y de aumentar los márgenes de las empresas con modelos de suscripción que devaluaban la propiedad local
    Después me cansé del entusiasmo y del absolutismo alrededor del “software realmente libre y open source”, y lo dejé pasar pensando que yo era joven
    En realidad puedo entender o tolerar muchos modelos de suscripción hasta cierto punto. Hacer software cuesta mucho dinero, y quizá no sea justo valorar una actualización anual de Photoshop en 200 dólares en 2026. Pero cambiar caprichosamente una UI que funcionó bien durante 20 años y hasta eliminar por completo cosas como las muestras clásicas de color es una tontería
    Entonces, con Codex, que es una herramienta esencial de trabajo por la que pago 200 dólares al mes, sí podría hacer un plugin para restaurar las muestras clásicas
    ¿Es justo pagar 200 dólares al mes por mi uso de tokens? En los meses de uso muy intenso, quizá haya usado cerca de mil millones de tokens
    Pero ese es justamente el problema. Estas empresas van a seguir moviendo palancas sin parar sin saber con precisión qué rentabilidad les cuadra, y si uno lee entre líneas cosas como los vencimientos de deuda, parece que eso seguirá por lo menos hasta 2030 o 2032
    No quiero pensar en eso para nada. No quiero tener que estar reevaluando preferencias de modelos y degradación de rendimiento, ni actualizando constantemente los matices de cómo le hablo a la IA según qué experimento misterioso de backend esté corriendo sobre la salida que uso para producir y mantener cosas por las que realmente me pagan
    La IA está en algún punto entre herramienta y colaborador, y me vuelve loco ese cambio caprichoso de “personalidad” que sale de manosear perillas y palancas poco comprendidas en la etapa de razonamiento. Por eso quiero señalar una caja en la esquina y saber exactamente qué calidad de salida da, una que nadie salvo yo cambie
  • ¿Fireworks?
  • Sí, eso de la regresión de rendimiento de Claude Code es pura “sensación”. En un sistema no determinista no deberías esperar un rendimiento consistente. No hay absolutamente ningún dato empírico que respalde una degradación del rendimiento
    Lo que sí cambió recientemente en escalones no fue el rendimiento del modelo, sino la cantidad de quejas y lloriqueos de los programadores

• Es bueno que Codex sea de código abierto, porque así este tipo de problemas puede salir a la luz y discutirse públicamente

  • Pero esto es comportamiento del modelo, y el hecho de que haya un rastreador público de issues me hace pensar que, salvo por el código, no es tan distinto de Claude Code. No entiendo en qué se diferencia esto de https://github.com/anthropics/claude-code
    Agradezco en general que Codex sea open source, pero en esta clase de problemas no parece significar mucho, porque el modelo sigue siendo cerrado
  • En general siento que OpenAI es mucho más abierto que Anthropic y se comporta más como una empresa de verdad. Anthropic es simplemente una caja negra

• Puede que mi memoria falle, pero por uso de tokens y calidad de código, creo que 5.3 era lo mejor. 5.5 funciona mejor, pero devora tokens por completo

  • No soy el único. Creo que 5.3-codex era un modelo excelente en equilibrio entre calidad de salida y costo
    A diferencia de 5.5 o Opus, era lo bastante barato y eficiente como para usarlo en casi cualquier tarea, y aun así bastante bueno; lo prefería sobre Sonnet
  • Hace unas semanas, 5.3 se volvió inutilizable para mí. Simplemente se detenía o daba respuestas pésimas

• Hace unos días, me parece que alguien aquí dijo que OpenAI había reducido el costo computacional a la mitad con una optimización revolucionaria. ¿Será esto?

  • Eso venía de un artículo de The Information, pero no me pareció un texto especialmente bien hecho. No me dio la impresión de que el autor fuera un especialista técnico que entendiera lo suficiente del funcionamiento de los LLM como para evaluar con fiabilidad rumores internos: https://www.theinformation.com/newsletters/ai-agenda/openai-...
    Decía que “ingenieros de OpenAI les dijeron a algunos colegas a principios de este mes que habían encontrado una forma de reducir en más de la mitad el costo de ejecutar modelos existentes, es decir, el costo de inferencia, gracias a una optimización recién descubierta”, según una persona al tanto de esa conversación
  • Yo entendí ese rumor no como algo de OpenAI en sí, sino como que uno de los grupos que salió de OpenAI después del caos, probablemente Thinking Machines, había logrado un avance y se lo estaba proponiendo a OpenAI. No creo que OpenAI lo haya implementado realmente todavía

• En mi caso, este efecto aparece si miro el contenido de razonamiento cifrado por la longitud de la cadena en base64. Pero no aparece en los tokens de razonamiento que reporta el servidor
  Por eso pensé que era simplemente parte del cifrado o de la ofuscación, y no un problema real
  La mayor desventaja de GPT es que su proceso de pensamiento está cifrado, así que es más caja negra que Kimi, GLM o DeepSeek. Aun así, como al menos da un resumen del razonamiento, se puede usar, aunque resulte raro

• ¿Será uno de esos raros casos en que cuando dicen que “hicieron más tonto al modelo” no es la paranoia habitual de los usuarios, sino que de verdad hicieron más tonto al modelo?

  • Esto más bien parece un fallo o una mala configuración del motor de razonamiento o del entorno de ejecución del agente
    Los detalles del issue no son evidencia de un debilitamiento intencional y encubierto; si acaso, apuntan más bien a lo contrario. La causa raíz parece burda, y tampoco suena a algo especialmente oculto si un usuario común puede reportarlo con detalles tan precisos y verificables de forma independiente
    La expresión “paranoia habitual de los usuarios” no me parece justa ni de buen gusto. Si todo lo que tienes es un endpoint de API tipo fregadero mágico que se traga una ventana de contexto y escupe salida, lo único que queda es juicio subjetivo, especulación y sospecha
    Incluso si hubiera una suite estandarizada de pruebas de modelos, afirmar que hubo un debilitamiento encubierto al final implicaría leer las intenciones de la gente de esa empresa. La calidad del modelo puede caer incluso sin intención explícita ni degradación de la infraestructura subyacente
    Considerar teorías de conspiración en broma o la posibilidad real de un debilitamiento no es una enfermedad mental. No me gusta esta tendencia a abusar así de términos de diagnóstico psicológico
    Claro que habrá personas demasiado seguras de ese tipo de juicios, y tal vez aplique a ellas, pero son una minoría. Al final no deja de ser una exageración y no ayuda a nadie

• Da risa que te vendan suscripciones a modelos frontier y luego los nerfeen rápido con el paso del tiempo sin que nadie diga nada
  Si del lado del servidor bajan silenciosamente la intensidad de razonamiento, por lo menos deberían hacer un descuento
  En cambio, yo uso 5.5-high todos los días en un flujo de trabajo paralelo con múltiples tareas, y apenas logro consumir el límite semanal. No soy lo bastante rápido como Human-as-a-Service para leer siguiendo toda la planificación y la implementación. Ese también es un factor

• Parece bastante claro que, para optimizar el throughput, están agrupando y procesando por lotes el razonamiento de inferencia en múltiplos de 512 tokens

  • Mi primera idea, pensando en llama.cpp, fue que ajustar el parámetro de presupuesto de razonamiento podría haber producido este resultado. Pero sin un anuncio de OpenAI no hay forma de saberlo con precisión
    También podría ser una forma muy poco honesta de escalar según la demanda en horas pico. Ya sé que en este tema hay gente que se burla de la subjetividad al percibir cambios en el rendimiento del modelo, pero al menos en mis pruebas durante todo mayo, el modelo se veía menos inteligente en los horarios en que Estados Unidos se conectaba
    Hace unas semanas, en una entrada del blog de la empresa, también sentí que esto se notaba con un patrón más consistente en esas franjas superpuestas, así que pensé que valía la pena señalarlo. Debí haber guardado los logs de las sesiones para hacer más análisis https://webesque.agency/blog/2026-06-19-llms.html
  • ¿No se supone que el estándar es usar continuous batching? Si usan continuous batching, me pregunto por qué importaría la longitud de los tokens generados y por qué los agruparían por longitud. Y si no lo usan, me gustaría saber por qué no y cuáles son las compensaciones