GPT-5.5 Codexの推論トークンのクラスタリングが性能低下につながる可能性

 (github.com/openai)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • OpenAI Codex issue #30364 は、gpt-5.5 の応答における reasoning_output_tokens が 516、1034、1552 といった固定値に偏る現象が、複雑な Codex タスクの品質低下に関連している可能性があると報告している
  • 分析対象は 2026年2月1日〜6月27日 UTC の Codex token_count メタデータで、390,195件の応答レコードと 865 セッションから exact 516 イベント 3,363件が確認された
  • gpt-5.5 は全応答の 19.3% だったが、exact-516 イベントの 82.0% を占め、reasoning_output_tokens >= 516 のうち exact 516 の比率は 44.0% で、non-GPT-5.5 の 1.3% を大きく上回った
  • 月別の exact-516 比率は 2026年2月の 0.11% から、5月 53.30%、6月 35.84% へ増加したが、同期間の平均および P90 の推論トークン数は低下しており、単純に推論トークン使用量が増えた現象ではなかった
  • その後のコメントでは、Codex CLI、Codex Desktop、OpenCode でも類似の 516 クラスタリングと一部の誤答再現が共有され、暫定対応として 518·n−2 パターンを検知して推論を継続させるローカルプロキシも提案された

問題の核心

  • Codex issue #30364 は、gpt-5.5 応答の token_count メタデータにおいて reasoning_output_tokens = 516 に過度に集中するパターンを報告している
  • さらに 1034、1552 付近でも固定境界のように見えるスパイクが現れるという
  • 提起されている範囲は、隠れた chain-of-thought の切断を証明するという主張ではない
    • より限定的な主張は、Codex テレメトリにおいて gpt-5.5 に特有の固定トークンクラスタリング異常が見られるということ
    • このパターンが、しきい値ベースの推論予算の動作と整合的に見える、というレベルの問題提起である
  • 関連 issue #29353 では、gpt-5.5 の実行が正確に 516 reasoning tokens で終了し誤答を返したタスク単位の再現が扱われており、今回の issue はより長い期間の集計証拠を追加している

分析環境とデータ

  • 製品は Codex、最も関連するモデルは gpt-5.5
  • データソースは Codex token_count メタデータ
  • 分析期間は 2026年2月1日〜6月27日 UTC
  • 集計値:
    • 応答レベルのトークンレコード: 390,195件
    • セッション: 865件
    • exact reasoning_output_tokens = 516 イベント: 3,363件
    • gpt-5.5 の全応答に占める比率: 19.3%
    • gpt-5.5 の exact-516 イベント比率: 82.0%
    • gpt-5.5 exact-516 / >=516 比率: 44.0%
    • non-GPT-5.5 exact-516 / >=516 比率: 1.3%

モデル別・月別パターン

  • モデル別の exact 516 / >=516 比率は gpt-5.5 で最も顕著だった
    • gpt-5.5: 75,401件のレコード、44.0%
    • gpt-5.4: 25,214件のレコード、19.8%
    • gpt-5.2: 247,575件のレコード、0.34%
    • gpt-5.3-codex: 13,333件のレコード、0.0%
    • gpt-5.3-codex-spark: 26,179件のレコード、0.0%
  • 月別の exact-516 クラスタリングは 2026年5月に急増した
    • 2月: 0.11%
    • 3月: 2.45%
    • 4月: 4.25%
    • 5月: 53.30%
    • 6月: 35.84%
  • 同期間に全体の推論トークン強度は低下していた
    • 平均 reasoning tokens: 2月 268.1 → 5月 106.9 → 6月 168.5
    • P90 reasoning tokens: 2月 772 → 5月 344 → 6月 515
  • この組み合わせにより、exact-516 の増加は単純な推論トークン使用量の増加では説明しにくい、という問題提起がなされている

要請された内部検証項目

  • Codex チームに対し、gpt-5.5 の推論予算、ルーティング、切断、fallback、scheduler の挙動が 516/1034/1552 付近での終了を引き起こしているのか調査してほしいと求めている
  • その挙動が意図されたものなら、exact 516 が正常終了点なのか、予算上限なのか、degraded tier なのか、別の内部しきい値なのかを明らかにしてほしいという要望も含まれる
  • 提案された検証手順:
    • モデル別に reasoning_output_tokens を含む token_count イベントを照会
    • 0、516、1034、1552 の exact-value カウントを比較
    • モデル・日付別に count(reasoning_output_tokens = 516) / count(reasoning_output_tokens >= 516) を計算
    • gpt-5.5 と gpt-5.2、gpt-5.4、Codex 専用バリアントを比較
    • GPT-5.2 と GPT-5.5 で複雑なタスクを再実行し、exact-516 応答とより長い reasoning 応答を分けて品質評価を行う

コメントで出た追加再現とクロスデータ

  • GitHub Actions は関連する重複候補として #29353 を表示した
  • 複数のユーザーが同じ問題を経験したとコメントしており、あるユーザーは前回の issue より今回の issue の方がよりデータに基づく報告だと評価した
  • sinnet3000 は Codex CLI と OpenCode のローカルセッション保存領域からクロスクライアントデータを提示した
    • Codex ~/.codex/sessions と archived_sessions の約 22.7k 件の token_count イベントでは、gpt-5.5 は records 4,300、>=516 が 156、exact 516 が 88、比率 56.4%
    • OpenCode opencode.db の約 32.1k 件の assistant messages では、gpt-5.5 は records 6,977、>=516 が 126、exact 516 が 90、比率 71.4%
    • Kimi、DeepSeek、MiMo、MiniMax、Gemini、Qwen、GLM など、一定量のデータがある non-OpenAI モデル合計約 24k records では exact 516 は 0件
    • ただしこのデータは回答の正誤は評価しておらず、exact 516 クラスタリングの存在だけを確認したという caveat が付いている
  • kyleboddy は Windows 11 の Codex Desktop で関連する挙動差を報告した
    • fresh な projectless Codex Desktop threads 5件で、同じ candy prompt を実行
    • 高速な direct-final_answer 実行は 29 を返し誤答
    • より遅く commentary が先に出た実行では 21 を返し正答
    • fresh Windows-host Desktop threads では exact reasoning_output_tokens を抽出できなかったため、その誤答実行が正確に 516 だったとは言えないと明記している
  • 同じユーザーはローカルセッションメタデータから gpt-5.5 / xhigh の固定値クラスタリングも集計した
    • records 16,141、sessions 51、平均 reasoning 149.7、P90 429
    • =516 が 438件、>=516 が 1,298件、比率 33.74%
    • =1034 が 52件、=1552 が 14件、=2070 が 16件、=2588 が 12件、=3106 が 5件

Codex Linux CLI の再現結果

  • kyleboddy は Codex Linux CLI でも同じ candy prompt を使って再現したという
  • 環境:
    • 製品: Codex CLI
    • バージョン: codex-cli 0.142.5
    • プラットフォーム: Ubuntu Linux 6.8.0-111-generic, x86_64
    • Node: v24.14.0
    • 認証モード: ChatGPT
    • テストモデル: gpt-5.5
    • reasoning efforts: xhigh, high
    • 比較対象モデル: gpt-5.4 xhigh
  • prompt は外部ツールを使わず、触覚で shape を区別できる candy bag 問題における最小 draw 数を問う内容
  • 期待される答えは brute-force enumeration により 21 であると独立に確認された
    • shape を触覚で区別できるため、9 round + 12 star candies を計画できるという説明が含まれる
  • 結果:
    • gpt-5.5 xhigh の完了した 4回の実行はすべて reasoning_output_tokens = 516 で、最終回答 23、26、28、15 とすべて誤答
    • gpt-5.5 high の 3回の実行もすべて 516 で、回答は 22、21、27 となり、正答は 1回のみ
    • gpt-5.4 xhigh の 3回の実行は 6211、12274、10876 reasoning tokens を使用し、いずれも 21 で正答
  • この結果は、gpt-5.5 が Codex において固定 516-token パスに入る可能性があり、そのパスがタスク品質の低下と相関しているかもしれない、という限定的な主張を補強している

暫定的な回避策の提案

  • dzshzx は upstream fix を待つ間、Codex の前段に置くローカル Responses プロキシ codexcomp を提案している
  • 動作方式は 518·n−2 パターンを切断とみなし、推論を継続させる構造
    • reasoning_tokens == 518·n − 2、すなわち 516、1034、1552 などで終わった round を truncated として扱う
    • tentative output を破棄し、その round の reasoning items と encrypted_content を次の入力として再生する
    • phase:"commentary" と "Continue thinking..." メッセージを一緒に入れる
    • すべての round を 1つの downstream response に畳み込み、Codex には完成した回答のように見せる
  • 設定には公式の top-level openai_base_url キーを使う
    • 例: openai_base_url = "http://127.0.0.1:8787/v1";
    • built-in openai provider は維持されるため、session grouping、remote compaction、remote-control は引き続き動作するとしている
  • 実際のログ例では、2回連続で 516 の後、3回目の round で clean 終了して最終回答が正しかったケースが示されている
    • round 1: reason=516 → continue
    • round 2: reason=516 → continue
    • round 3: reason=291 → clean
  • caveat:
    • 非公式の回避策であり、upstream の非契約的な挙動に依存する
    • continuation round では追加の実トークンを消費する
    • n window と 3-continuation cap で制限される
    • loopback-only、auth passthrough であり、credentials を読み取ったり保存したりはしないとしている

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker News のコメント

  • これはかなり深刻に見えるし、codex cli でも簡単に再現できる
    推論が必要なパズルのプロンプトを与えると、時々突然打ち切られたように、正確に 516 個の思考トークンだけを使って間違った答えを出す
    6000〜8000 個の思考トークンを使う場合は正解を出す
    adaptive thinking 側の問題かもしれないし、ローカルモデルならサーバー側の密かな変更を心配しなくてよいという点で、またローカルに一票入れたくなる
    同じプロンプトを 10 回回したところ、4 回がこの 516 トークン問題で、その 4 回はすべて不正解だった。標本は小さいが、5.5 xhigh はほぼ半分の確率で短絡して性能が落ちる可能性があるように見える

    • adaptive thinking には哲学的にも問題があると思う。考える前に思考予算をどれだけ割り当てるかを当てる方式だが、LLM の文脈では必要な思考量、つまり生成トークン数を事前に知る方法はほとんどなさそう
      問題空間は無限に広く、プロンプト間の類似性だけでどれだけ考えるべきかを判断するのは難しい。モデルはすでに思考予算に達する前にも考えるのをやめる
      なぜ adaptive thinking の実装にここまで多くの労力を使うのか分からないし、むしろモデルが思考終了トークンをよりうまく出すよう訓練すべきではないかと思う
      その場しのぎに感じる。モデルは適切な量の推論をするよう訓練されるべきだ: 推論 → 残る不確実性の推定 → 続けるか判断 → さらに推論 → 繰り返し
    • ローカルモデルでも設定ミスは心配すべき。専門家でも間違えるので、提供者ごとにローカルモデルの性能はばらつく
    • 時間帯や曜日別のテストでパターンが見えるのか気になる。たとえば業務時間のピーク時に短絡現象がより頻繁に起きるかを見られそう
    • その無駄になったトークンの費用もユーザーが払っているなら、返金リクエストをするのがよいかもしれない

  • ほぼ毎日、品質が階段状に落ちるのを経験していて、普段は xhigh を使っていた
    今年初めに Codex の非常に綿密なコーディングに頼っていた体験は消え、断続的に信じられないほど間抜けな実装が出てくるようになったので、OpenAI がこの問題を真剣に扱うまで Claude に乗り換えた
    個人的には数か月前から見ているが、OpenAI が深刻に受け止めているようには見えなかった

    • 3か月前には Claude があまりに愚かになったので Codex に移り、6か月前にはその逆だった。Codex でも Claude でも、いつかはどちらにも痛い目に遭わされる。それでも Codex の方がおそらくまし
    • 6月初めから、5.5 の信頼性が自分の経験では Claude 並みに落ちたと感じた
      それで 5.5 high → 5.5 xhigh → 5.4 high と移ってきた
      5.4 high はこの 3 週間完全に安定していて、今はそれで満足している
      時々 5.5 xhigh で作業を走らせ、100% 安定した状態に戻ったか確認しているが、今はこの信頼性問題を直すより 5.6 のリリースを待つ方向なのだろうと思っている
    • こういう問題を技術的問題だとは思わない。直すには金がかかるが、ユーザーが十分多く払っていないので、性能を下げるビジネス上の判断だと思う

  • デジャヴみたいだ。4月の Claude Code の性能リグレッションとまったく同じに見える。その時 Claude のサブスクを解約して Codex に移った
    今は両方ともトークン単位課金で使ってみて、ほとんどの作業は Fireworks の GLM 5.2 を使い、必要な時だけ大型モデルに金を払うことを考えている。ただ、損益分岐点が合うかどうかは確信がない

    • トークン単位課金について自分も同じ反応だったが、両方の研究所にとって顧客をトークン単位の消費へ移す方が経済的に有利だという点から、原則として避けたくなった
      意図的でないとしても、品質が低下した製品から利益を得る構造を受け入れたり可能にしたりしたくない
      正直、ChatGPT のリリース以降のどの時点よりも、オープンソースモデルやオープンな実行環境、たとえば Pi のようなものがずっと魅力的に見える
    • その通り。自分もその件で Claude Code をやめて Codex に変えた
      今は、こういう馬鹿げたことを二度と心配しなくて済むように、65,000 ドルをどう追加で稼ぐか考えている。OpenRouter のようなものの経済性は分かっている
      2008年ごろ「クラウド」がマーケティング用語として浮上していた時期を思い出す。リッチクライアントへの期待値を下げ、ローカル所有権を削るサブスクリプションモデルで企業のマージンを増やすための包装のように見えた
      その後、「真の自由・オープンソースソフトウェア」への熱狂と絶対主義にうんざりして、自分が若かったのだと思って流した
      実際、多くのサブスクリプションモデルはある程度理解できるし、我慢もできる。ソフトウェアを作るには金がかかるし、2026年に Photoshop の年次アップグレードの価値を 200 ドルと見るのは公平でないかもしれない。ただ、20年間うまくいっていた UI を気まぐれに変え、クラシックな色見本のようなものを完全になくすのは愚かだ
      そうなれば、月 200 ドル払っている業務必須ツールである Codex で、クラシック色見本プラグインを作ることはできる
      自分のトークン使用量に対して月 200 ドルは公平か？ かなり多く使った月には 10 億トークンくらい使ったかもしれない
      だがまさにそれが問題だ。彼らは具体的にどの収益性が合っているのか分からないまま、際限なくレバーを引き続けるだろうし、債務満期のような茶葉占いを見る限り、少なくとも 2030年か 2032年まではそうなりそうだ
      そんなことは一切考えたくない。モデルの好みや性能低下を評価し、自分が実際に報酬を得て作り保守している成果物に使う出力に、どんな謎のバックエンド実験が走っているのかに合わせて、AI への言い方のニュアンスを更新し続けたくない
      AI は道具と共同作業者の間のどこかにあるが、推論段階でよく理解されていないノブやレバーをいじることで生じる気まぐれな「性格」変化には気が狂いそうになる。だから隅に置いた箱を指さして、自分以外は誰も変えない出力品質を正確に把握していたい
    • Fireworks？
    • 「雰囲気ベース」の Claude Code 性能リグレッションというやつだね。非決定的システムに一貫した性能を期待すべきではない。性能低下を裏付ける実証データはまったくない
      最近階段状に変わったのはモデル性能ではなく、コーダーたちの泣き言と不満の量だ

  • Codexがオープンソースなので、こうした問題が公開の場で明らかになり、扱われ得る点は良い

    • ただ、これはモデルの挙動であり、公開のイシュートラッカーがあるという点は、コードがないだけでClaude Codeと同じではないかと思う。こういう問題では https://github.com/anthropics/claude-code と何が違うのか分からない
      Codexがオープンソースであることには全般的に感謝しているが、この種の問題ではモデルが依然としてクローズドなので、大きな意味はなさそうに見える
    • OpenAIは全般的にAnthropicよりはるかにオープンで、実際の企業らしいと感じる。Anthropicは単なるブラックボックスだ

  • 記憶違いかもしれないが、トークン使用量とコード品質の基準では5.3が最高だったように思う。5.5のほうがうまく動きはするが、トークンを完全に食い尽くす

    • 自分だけではない。5.3-codexは出力品質とコストのバランスという点で優れたモデルだったと思う
      5.5やOpusと違い、ほぼあらゆる作業に使えるほど安く効率的で、それでいてかなり良く、Sonnetより好んでいた
    • 数週間前、5.3は自分の基準では使えない状態になった。ただ止まるか、ひどい答えを出すだけだった

  • 数日前、OpenAIが画期的な最適化で計算コストを半分に減らしたと、ここで誰かが言っていた気がするが、それがこれなのか？

    • それはThe Informationの記事だったが、よく書かれた記事には見えなかった。執筆者がLLMの動作の仕組みを十分に知っている技術専門家で、内部の噂を信頼性をもって評価できる、という感じは受けなかった: https://www.theinformation.com/newsletters/ai-agenda/openai-...
      「OpenAIのエンジニアたちは今月初め、一部の同僚に対し、新たに発見した最適化のおかげで既存モデルの実行、つまり推論コストを半分以上削減する方法を見つけたと語った」と、その議論を知る人物が伝えた、という内容だった
    • その噂はOpenAI自身ではなく、一連の出来事の後にOpenAIから分かれたグループの一つ、おそらくThinking Machinesがブレークスルーを生み出し、OpenAIに提案中だという話だと理解していた。OpenAIがまだ実際に実装したわけではないと思う

  • 自分の場合、暗号化された推論内容をbase64文字列の長さで見ると、この効果が現れる。しかし、サーバーが報告する推論トークンには現れない
    そのため、純粋に暗号化や難読化の一部だと思っており、実際の問題ではないと見ている
    GPTの最大の欠点は、思考過程が暗号化されているため、Kimi、GLM、DeepSeekよりもさらにブラックボックスである点だ。それでも思考の要約は受け取れるので、ぎこちないが使うことはできる

  • まれに言われる「モデルをバカにした」という話が、いつものユーザーの妄想ではなく、実際にモデルをバカにしたケースなのか？

    • これはむしろ、推論エンジンやエージェント実行環境の欠陥、または設定ミスのように見える
      イシューの詳細は意図的なこっそり弱体化の証拠ではなく、むしろその逆に近い。根本原因は雑で、一般ユーザーが独立検証可能な正確な詳細として報告できるほど、特に隠密でもない
      「いつものユーザーの妄想」という表現は、公正でも好みに合うものでもない。コンテキストウィンドウを飲み込んで続きの出力を吐き出す魔法の流し台のようなAPIエンドポイントしか持っていなければ、残るのは主観的判断と推測、疑念だけだ
      標準化されたモデルテストスイートがあっても、こっそり弱体化だと主張することは、結局その会社の人々の意図を読む行為になる。明示的な意図や基盤インフラのダウングレードがなくても、モデル品質は低下し得る
      冗談めいた陰謀論や実際の弱体化の可能性を検討すること自体は、精神病ではない。心理診断用語をこのように乱用する流れは好きではない
      もちろん、こうした判断に過度に確信を持つ人もいるだろうし、その人たちには当てはまるかもしれないが、それは少数だ。結局は誇張にすぎず、誰の役にも立たない

  • フロンティアモデルのサブスクリプションを売っておいて、時間が経つにつれて素早くナーフしているのに、誰も話題にしないのはおかしい
    サーバー側でこっそり推論強度を下げるなら、割引くらいしてほしい
    一方で私は5.5-highを毎日、並列のマルチタスクフローで使っているが、週間上限をかろうじて使い切る程度だ。計画と実装をすべて追って読むには、自分がHuman-as-a-Serviceとして十分に速くない。そういう面もある

  • スループット最適化のために、推論の推論を512トークンの倍数単位にまとめてバッチ処理しているのは明らかに見える

    • 最初に思ったのは、llama.cppを基準にすると、推論予算パラメータの調整がこのような結果を生んだ可能性があるということだった。しかしOpenAIの発表がない限り、正確に知る方法はない
      ピーク時間帯の需要に合わせてスケールする、非常に不誠実なやり方かもしれない。この話題ですでに、モデル性能の体感の主観性を笑う人たちがいるのは分かっているが、少なくとも5月の1か月間の自分のテストでは、米国がオンラインになる時間帯にモデルがあまり賢くないように見えた
      数週間前の会社ブログ記事でも、重なる時間帯により一貫したパターンとして体感されたので、この点を指摘すべきだと感じた。追加分析のためにセッションログを保存しておくべきだった https://webesque.agency/blog/2026-06-19-llms.html
    • 標準は連続バッチ処理を使うものではないのか？ 連続バッチ処理を使うなら、生成トークン長がなぜ重要で、なぜ長さ別にまとめるのか気になる。そうでないなら、なぜ使わないのか、そのトレードオフが気になる