Clusterização de tokens de raciocínio do GPT-5.5 Codex pode levar à queda de desempenho

• A issue #30364 do OpenAI Codex relata que a concentração dos reasoning_output_tokens das respostas do gpt-5.5 em valores fixos como 516, 1034 e 1552 pode estar relacionada à queda de qualidade em tarefas complexas do Codex
• A análise cobre metadados token_count do Codex de 1º de fevereiro a 27 de junho de 2026 UTC, com 390.195 registros de respostas e 3.363 eventos exact 516 identificados em 865 sessões
• O gpt-5.5 representou 19,3% de todas as respostas, mas respondeu por 82,0% dos eventos exact-516; entre reasoning_output_tokens >= 516, a proporção de exact 516 foi de 44,0%, muito acima dos 1,3% dos modelos non-GPT-5.5
• A proporção mensal de exact-516 subiu de 0,11% em fevereiro de 2026 para 53,30% em maio e 35,84% em junho, enquanto a média e o P90 de tokens de raciocínio caíram no mesmo período, indicando que não se tratava simplesmente de aumento no uso de tokens de raciocínio
• Comentários posteriores compartilharam clusterização semelhante em 516 e algumas reproduções de respostas incorretas no Codex CLI, Codex Desktop e OpenCode; como mitigação temporária, também foi proposto um proxy local que detecta o padrão 518·n−2 e continua o raciocínio

---

Problema central da issue

• A issue #30364 do Codex relata um padrão de concentração excessiva em reasoning_output_tokens = 516 nos metadados token_count das respostas do gpt-5.5
• Além disso, afirma que também aparecem picos perto de 1034 e 1552, como se fossem limites fixos
• O escopo levantado não é uma alegação de que isso prove truncamento de chain-of-thought oculto
  • A afirmação mais restrita é que a telemetria do Codex mostra uma anomalia de clusterização em tokens fixos específica do gpt-5.5
  • A questão é apresentada no sentido de que esse padrão parece consistente com um comportamento de orçamento de raciocínio baseado em limiares
• A issue relacionada #29353 tratou de uma reprodução em unidade de tarefa na qual uma execução do gpt-5.5 terminava exatamente em 516 reasoning tokens e retornava uma resposta errada; esta issue acrescenta evidências agregadas de um período maior

Ambiente de análise e dados

• O produto é o Codex, e o modelo mais relevante é gpt-5.5
• A fonte de dados são os metadados token_count do Codex
• O período de análise é de 1º de fevereiro a 27 de junho de 2026 UTC
• Números agregados:
  • Registros de tokens em nível de resposta: 390.195
  • Sessões: 865
  • Eventos exact reasoning_output_tokens = 516: 3.363
  • Participação do gpt-5.5 no total de respostas: 19,3%
  • Participação do gpt-5.5 nos eventos exact-516: 82,0%
  • Proporção exact-516 / >=516 do gpt-5.5: 44,0%
  • Proporção exact-516 / >=516 dos non-GPT-5.5: 1,3%

Padrões por modelo e por mês

• A proporção exact 516 / >=516 por modelo é mais evidente no 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%
• A clusterização mensal de exact-516 disparou em maio de 2026
  • Fevereiro: 0,11%
  • Março: 2,45%
  • Abril: 4,25%
  • Maio: 53,30%
  • Junho: 35,84%
• No mesmo período, a intensidade geral de tokens de raciocínio caiu
  • Média de reasoning tokens: fevereiro 268,1 → maio 106,9 → junho 168,5
  • P90 de reasoning tokens: fevereiro 772 → maio 344 → junho 515
• Por causa dessa combinação, foi levantado o problema de que o aumento de exact-516 é difícil de explicar como simples aumento no uso de tokens de raciocínio

Itens solicitados para verificação interna

• Foi solicitado à equipe do Codex que investigue se o orçamento de raciocínio, roteamento, truncamento, fallback ou comportamento do scheduler do gpt-5.5 pode causar encerramentos perto de 516/1034/1552
• Caso esse comportamento seja intencional, o pedido inclui esclarecer se exact 516 é um ponto normal de término, um limite de orçamento, um degraded tier ou outro limiar interno
• Procedimento de verificação proposto:
  • Consultar eventos token_count que incluam reasoning_output_tokens por modelo
  • Comparar contagens de valores exatos 0, 516, 1034, 1552
  • Calcular count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516) por modelo e data
  • Comparar gpt-5.5 com gpt-5.2, gpt-5.4 e variantes específicas do Codex
  • Reexecutar tarefas complexas no GPT-5.2 e no GPT-5.5, separando respostas exact-516 de respostas com raciocínio mais longo para avaliar a qualidade

Reproduções adicionais e dados cruzados nos comentários

• O GitHub Actions marcou #29353 como possível duplicata relacionada
• Vários usuários comentaram que passaram pelo mesmo problema, e um deles avaliou que esta issue é um relato mais orientado por dados do que a issue anterior
• sinnet3000 apresentou dados cruzados entre clientes a partir de armazenamentos locais de sessões do Codex CLI e do OpenCode
  • Em cerca de 22,7 mil eventos token_count do Codex em ~/.codex/sessions e archived_sessions, o gpt-5.5 teve 4.300 records, 156 >=516, 88 exact 516, proporção de 56,4%
  • Em cerca de 32,1 mil assistant messages do opencode.db do OpenCode, o gpt-5.5 teve 6.977 records, 126 >=516, 90 exact 516, proporção de 71,4%
  • Em cerca de 24 mil records somados de modelos non-OpenAI com volume, como Kimi, DeepSeek, MiMo, MiniMax, Gemini, Qwen e GLM, houve 0 caso de exact 516
  • Esses dados vieram com a ressalva de que não avaliavam se as respostas estavam certas ou erradas, apenas confirmavam a existência da clusterização exact 516
• kyleboddy relatou uma diferença de comportamento relacionada no Codex Desktop no Windows 11
  • Executou o mesmo candy prompt em 5 threads fresh projectless do Codex Desktop
  • Execuções rápidas direct-final_answer retornaram 29, uma resposta errada
  • Execuções mais lentas em que commentary apareceu primeiro retornaram 21, a resposta correta
  • Ele afirmou que, em threads fresh do Desktop hospedadas no Windows, não foi possível extrair o valor exato de reasoning_output_tokens, portanto não dá para dizer que a execução errada foi exatamente 516
• O mesmo usuário também agregou a clusterização de valores fixos de gpt-5.5 / xhigh nos metadados de sessões locais
  • records 16.141, sessions 51, média de reasoning 149,7, P90 429
  • =516 438 casos, >=516 1.298 casos, proporção de 33,74%
  • =1034 52 casos, =1552 14 casos, =2070 16 casos, =2588 12 casos, =3106 5 casos

Resultados de reprodução no Codex Linux CLI

• kyleboddy disse ter reproduzido também no Codex Linux CLI usando o mesmo candy prompt
• Ambiente:
  • Produto: Codex CLI
  • Versão: codex-cli 0.142.5
  • Plataforma: Ubuntu Linux 6.8.0-111-generic, x86_64
  • Node: v24.14.0
  • Modo de autenticação: ChatGPT
  • Modelo testado: gpt-5.5
  • reasoning efforts: xhigh, high
  • Modelo de controle: gpt-5.4 xhigh
• O prompt perguntava o número mínimo de retiradas em um problema de saco de doces em que é possível distinguir shapes pelo tato, sem usar ferramentas externas
• A resposta esperada foi confirmada de forma independente por enumeração brute-force como 21
  • A explicação incluía que, como é possível distinguir shapes pelo tato, é possível planejar 9 doces round + 12 star
• Resultados:
  • As 4 execuções concluídas de gpt-5.5 xhigh foram todas com reasoning_output_tokens = 516, e as respostas finais 23, 26, 28, 15 foram todas erradas
  • As 3 execuções de gpt-5.5 high também foram todas 516, com respostas 22, 21, 27, ou seja, apenas 1 correta
  • As 3 execuções de gpt-5.4 xhigh usaram 6211, 12274 e 10876 reasoning tokens e todas responderam 21, corretamente
• Esse resultado reforça a afirmação restrita de que o gpt-5.5 pode entrar em um caminho fixo de 516 tokens no Codex e que esse caminho pode estar correlacionado a queda de qualidade na tarefa

Proposta de workaround temporário

• dzshzx propôs o proxy local Responses codexcomp, colocado na frente do Codex enquanto se aguarda uma correção upstream
• O funcionamento considera o padrão 518·n−2 como truncamento e continua o raciocínio
  • Rounds terminados com reasoning_tokens == 518·n − 2, ou seja, 516, 1034, 1552 etc., são tratados como truncated
  • O tentative output é descartado, e os reasoning items e o encrypted_content daquele round são reproduzidos como próxima entrada
  • Uma mensagem com phase:"commentary" e "Continue thinking..." é incluída junto
  • Todos os rounds são dobrados em uma única downstream response, para que ao Codex pareça uma resposta concluída
• A configuração usa a chave oficial top-level openai_base_url
  • Exemplo: openai_base_url = "http://127.0.0.1:8787/v1";
  • O provider built-in openai é mantido, então session grouping, remote compaction e remote-control continuam funcionando, segundo o relato
• O exemplo de logs reais mostra um caso em que, após dois 516 consecutivos, o terceiro round terminou de forma clean e a resposta final estava correta
  • round 1: reason=516 → continue
  • round 2: reason=516 → continue
  • round 3: reason=291 → clean
• Ressalvas:
  • É um workaround não oficial e depende de comportamento não contratual do upstream
  • Rounds de continuação usam tokens reais adicionais
  • É limitado por uma janela n e por um teto de 3 continuações
  • É loopback-only, com auth passthrough, e afirma não ler nem armazenar credentials

[GN⁺]

Opiniões no Hacker News

• Isso parece bem sério e também é fácil de reproduzir com o codex cli
  Se você der um prompt de puzzle que exige raciocínio, às vezes ele parece ser interrompido de repente, usa exatamente 516 tokens de pensamento e dá uma resposta errada
  Quando usa 6.000 a 8.000 tokens de pensamento, ele chega à resposta correta
  Pode ser um problema na parte de pensamento adaptativo (adaptive thinking), e é mais um ponto a favor de modelos locais, já que eles não exigem preocupação com mudanças silenciosas do lado do servidor
  Rodei o mesmo prompt 10 vezes e 4 deram esse problema dos 516 tokens; todas essas 4 respostas estavam erradas. A amostra é pequena, mas parece que o 5.5 xhigh pode ser encurtado em quase metade das vezes, degradando o desempenho

  • Vejo também um problema filosófico no pensamento adaptativo. É uma abordagem em que se tenta adivinhar, antes de pensar, quanto orçamento de raciocínio deve ser alocado; no contexto de LLMs, parece haver pouquíssima forma de saber de antemão a quantidade de raciocínio necessária, ou seja, a quantidade de tokens a gerar
    O espaço de problemas é infinitamente amplo, e é difícil julgar quanto é preciso pensar apenas pela similaridade entre prompts. O modelo já para de pensar mesmo antes de atingir o orçamento de raciocínio
    Não sei por que gastam tanto esforço implementando pensamento adaptativo; talvez fosse melhor treinar o modelo para emitir melhor um token de encerramento de pensamento
    Parece um remendo. O modelo deveria ser treinado para fazer uma quantidade adequada de raciocínio: raciocinar → estimar a incerteza restante → decidir se continua → raciocinar mais → repetir
  • Modelos locais também exigem preocupação com erros de configuração. Como até especialistas erram, o desempenho de modelos locais varia bastante de provedor para provedor
  • Fico curioso se apareceriam padrões em testes por horário ou dia da semana. Por exemplo, daria para ver se o encurtamento acontece com mais frequência nos picos do horário comercial
  • Se o usuário também paga por esses tokens desperdiçados, talvez seja uma boa fazer um pedido de reembolso

• Quase todo dia passei por quedas de qualidade em degraus, e normalmente usava xhigh
  A experiência que eu tinha no começo do ano, de depender da codificação excepcionalmente cuidadosa do Codex, desapareceu; começaram a aparecer, de vez em quando, implementações absurdamente burras, então mudei para o Claude até a OpenAI tratar esse problema com seriedade
  Pessoalmente, venho observando isso há meses, e não parecia que a OpenAI estivesse levando a sério

  • Há 3 meses, o Claude tinha ficado burro demais e eu migrei para o Codex; 6 meses antes tinha sido o contrário. Seja Codex ou Claude, em algum momento os dois acabam te passando a perna. Ainda assim, o Codex provavelmente é menos ruim
  • Desde o começo de junho, senti que a confiabilidade do 5.5 caiu, na minha experiência, para o nível do Claude
    Por isso fui migrando de 5.5 high → 5.5 xhigh → 5.4 high
    O 5.4 high ficou totalmente estável nas últimas 3 semanas, e por enquanto estou satisfeito com ele
    Às vezes ainda rodo tarefas no 5.5 xhigh para ver se ele voltou a ficar 100% estável, mas neste momento acho que eles estão mais esperando lançar o 5.6 do que corrigir esse problema de confiabilidade
  • Não acredito que esse tipo de problema seja técnico. Corrigir custaria caro e os usuários não pagam o suficiente, então vejo isso como uma decisão de negócio de reduzir desempenho

• Parece déjà vu. É exatamente igual à regressão de desempenho do Claude Code em abril. Na época, cancelei a assinatura do Claude e migrei para o Codex
  Agora estou pensando em usar ambos com cobrança por token e, para a maioria das tarefas, usar o GLM 5.2 da Fireworks, pagando pelos modelos grandes só quando necessário. Mas não tenho certeza se o ponto de equilíbrio fecha

  • Tive a mesma reação em relação à cobrança por token, mas, como é economicamente vantajoso para os dois laboratórios empurrar os clientes para consumo por token, passei a querer evitar isso por princípio
    Mesmo que não seja intencional, não quero aceitar nem viabilizar uma estrutura que lucra com um produto de qualidade degradada
    Desde o lançamento do ChatGPT, modelos open source e ambientes de execução abertos, como coisas do tipo Pi, nunca pareceram tão atraentes
  • Exato. Também cancelei o Claude Code por causa disso e mudei para o Codex
    Agora estou pensando em como ganhar US$ 65.000 a mais para não ter que me preocupar de novo com esse tipo de besteira. Conheço a economia de algo como o OpenRouter
    Isso me lembra a época por volta de 2008, quando “cloud” começou a virar termo de marketing. Parecia uma embalagem para reduzir as expectativas em relação a clientes ricos e aumentar as margens das empresas com modelos de assinatura que corroíam a propriedade local
    Depois fiquei cansado do entusiasmo e do absolutismo em torno de “software realmente livre e open source” e deixei para lá, achando que eu era jovem demais
    Na verdade, consigo entender ou tolerar muitos modelos de assinatura até certo ponto. Criar software custa caro, e talvez não seja justo enxergar o valor de um upgrade anual do Photoshop em 2026 como US$ 200. Mas mudar caprichosamente uma UI que funcionava bem havia 20 anos e remover completamente coisas como as amostras de cores clássicas é burrice
    Aí dá para usar o Codex, uma ferramenta essencial de trabalho que custa US$ 200 por mês, para criar um plugin de amostras clássicas
    US$ 200 por mês é justo para o meu uso de tokens? Em meses de uso muito intenso, talvez eu tenha usado algo como 1 bilhão de tokens
    Mas esse é justamente o problema. Eles vão continuar puxando alavancas sem parar, sem que saibamos qual rentabilidade específica faz sentido para eles, e, olhando sinais como vencimentos de dívida, parece que isso vai continuar pelo menos até 2030 ou 2032
    Não quero pensar em nada disso. Não quero avaliar preferências de modelo e degradação de desempenho, nem ficar atualizando continuamente as nuances de como falo com a IA de acordo com experimentos misteriosos de backend que podem estar rodando sobre as saídas que uso em entregáveis pelos quais sou pago para criar e manter
    A IA fica em algum ponto entre ferramenta e colaborador, e mudanças temperamentais de “personalidade” causadas por mexerem, na etapa de raciocínio, em botões e alavancas mal compreendidos me deixam louco. Por isso quero apontar para uma caixa no canto e saber exatamente qual qualidade de saída vou obter, sem que ninguém além de mim a altere
  • Fireworks?
  • É isso mesmo, uma regressão de desempenho “baseada em sensação” do Claude Code. Não se deve esperar desempenho consistente de um sistema não determinístico. Não há nenhum dado empírico que sustente a degradação de desempenho
    O que mudou recentemente em degraus não foi o desempenho do modelo, mas a quantidade de choradeira e reclamação dos programadores

• É bom que, por o Codex ser open source, esse tipo de problema possa aparecer e ser tratado publicamente

  • Mas isso é comportamento do modelo, e o fato de haver um rastreador público de issues me parece igual ao Claude Code, só sem o código. Nesse tipo de problema, não sei o que há de diferente em relação a https://github.com/anthropics/claude-code
    No geral, sou grato por o Codex ser open source, mas, nessa categoria de problema, como o modelo continua fechado, isso não parece ter grande significado
  • No geral, sinto que a OpenAI é muito mais aberta e se comporta muito mais como uma empresa de verdade do que a Anthropic. A Anthropic é simplesmente uma caixa-preta

• Talvez minha memória esteja ruim, mas, pelo uso de tokens e pela qualidade do código, acho que a 5.3 foi a melhor. A 5.5 funciona melhor, mas devora tokens completamente

  • Não sou só eu. Acho que o 5.3-codex era um modelo excelente em termos de equilíbrio entre qualidade de saída e custo
    Ao contrário do 5.5 ou do Opus, era barato e eficiente o bastante para usar em praticamente qualquer tarefa, ainda assim bastante bom, e eu o preferia ao Sonnet
  • Algumas semanas atrás, o 5.3 ficou inutilizável para mim. Ele simplesmente travava ou dava respostas péssimas

• Alguns dias atrás, acho que alguém aqui disse que a OpenAI tinha reduzido o custo computacional pela metade com uma otimização revolucionária; seria isso?

  • Aquilo era um artigo do The Information, mas não parecia muito bem escrito. Não tive a impressão de que o autor fosse um especialista técnico que entendesse suficientemente como LLMs funcionam para avaliar rumores internos com credibilidade: https://www.theinformation.com/newsletters/ai-agenda/openai-...
    O texto dizia, segundo uma pessoa familiarizada com a discussão, que “engenheiros da OpenAI disseram a alguns colegas no início deste mês que haviam encontrado uma forma de reduzir em mais da metade o custo de executar modelos existentes, isto é, de inferência, graças a uma otimização recém-descoberta”
  • Entendi esse rumor como não sendo da própria OpenAI, mas de um dos grupos que se separaram da OpenAI depois dos acontecimentos, talvez a Thinking Machines, que teria feito o avanço e estaria propondo isso à OpenAI. Acho que a OpenAI ainda não implementou de fato

• No meu caso, esse efeito aparece quando olho para o conteúdo de raciocínio criptografado pelo tamanho da string em base64. Mas não aparece nos tokens de raciocínio informados pelo servidor
  Por isso achei que fosse puramente parte da criptografia ou da ofuscação, e não um problema real
  A maior desvantagem do GPT é que o processo de pensamento é criptografado, então ele é mais caixa-preta do que Kimi, GLM e DeepSeek. Ainda assim, dá para receber um resumo do raciocínio, então, embora seja estranho, é utilizável

• Será que este é um caso raro em que “deixaram o modelo burro” não é a paranoia habitual dos usuários, mas realmente deixaram o modelo burro?

  • Isso parece mais uma falha ou configuração incorreta no motor de inferência ou no ambiente de execução do agente
    Os detalhes da issue não são evidência de um enfraquecimento deliberado às escondidas; na verdade, são quase o oposto. A causa raiz é tosca e nem é particularmente discreta, a ponto de um usuário comum conseguir relatar detalhes precisos e verificáveis de forma independente
    A expressão “paranoia habitual dos usuários” não é justa nem do meu gosto. Quando tudo o que se tem é um endpoint de API que parece uma pia mágica, engolindo a janela de contexto e cuspindo a saída seguinte, só restam julgamentos subjetivos, suposições e desconfiança
    Mesmo que exista uma suíte padronizada de testes de modelo, alegar enfraquecimento às escondidas acaba sendo uma tentativa de ler as intenções das pessoas da empresa. A qualidade do modelo pode cair mesmo sem intenção explícita ou downgrade da infraestrutura subjacente
    Fazer teorias da conspiração em tom de brincadeira ou considerar a possibilidade de um enfraquecimento real não é, por si só, doença mental. Não gosto dessa tendência de abusar de termos de diagnóstico psicológico dessa forma
    Claro, pode haver pessoas excessivamente convictas nesse julgamento, e isso pode se aplicar a elas, mas são uma minoria. No fim, é apenas exagero, e não ajuda ninguém

• É engraçado venderem assinaturas de modelos de fronteira e depois nerfarem rapidamente com o tempo sem ninguém falar disso
  Se reduzem silenciosamente a intensidade de inferência no lado do servidor, deveriam pelo menos dar um desconto
  Por outro lado, eu uso o 5.5-high todos os dias em fluxos paralelos com várias tarefas, e mal consigo esgotar o limite semanal. Não sou rápido o suficiente como Human-as-a-Service para acompanhar e ler todo o planejamento e a implementação. Também existe esse lado

• Parece claro que, para otimizar throughput, estão agrupando a inferência de raciocínio em múltiplos de 512 tokens para processar em batch

  • Meu primeiro pensamento, tomando o llama.cpp como referência, foi que um ajuste no parâmetro de orçamento de inferência poderia ter produzido esse resultado. Mas, sem um anúncio da OpenAI, não há como saber ao certo
    Também poderia ser uma forma muito desonesta de escalar para atender à demanda nos horários de pico. Sei que neste tópico já há pessoas ridicularizando a subjetividade da percepção de desempenho dos modelos, mas, pelo menos nos meus testes ao longo de maio, o modelo parecia menos inteligente nos horários em que os EUA ficavam online
    Algumas semanas atrás, em um post no blog da empresa, percebi um padrão mais consistente nesses horários sobrepostos e senti que precisava apontar isso. Eu deveria ter salvado os logs das sessões para uma análise adicional https://webesque.agency/blog/2026-06-19-llms.html
  • O padrão não é usar batching contínuo? Se usam batching contínuo, fico curioso por que o comprimento dos tokens gerados importa e por que agrupar por tamanho. Se não usam, fico curioso por que não e quais são os trade-offs