OpenAI、Codexモデルのコンテキストサイズを372kから272kに縮小

 (github.com/openai)
1 ポイント 投稿者 GN⁺ 1 일 전 | 1件のコメント | WhatsAppで共有
  • OpenAI Codexのバンドルされたモデルメタデータを更新し、モデルのコンテキストサイズを372kから272kに縮小する変更をrelease/0.144ブランチへバックポート
  • PR #33972はagent/hotfix-0.144-model-metadataブランチからCodex 0.144リリースへ変更を移送
  • 変更範囲はJSONファイル1件で、diff統計は64行追加・54行削除
  • 別途の議論やレビュー内容はなく、1件のコミットと36件のチェックを経てマージ
  • 提供されたページではファイルdiffが読み込まれておらず、コンテキスト縮小以外の具体的なメタデータ変更内容は確認できない

変更の目的と範囲

  • PRタイトルは更新されたバンドルモデルメタデータをCodex 0.144にバックポートする作業
  • Hacker Newsのタイトルによれば、モデルのコンテキストサイズは372kから272kに縮小
  • 対象ブランチはopenai:release/0.144、ソースブランチはsayan-oai:agent/hotfix-0.144-model-metadata

マージ結果

  • PR #33972は1件のコミットb06f4faで構成
  • コミットタイトルはBackport refreshed bundled model metadata
  • 2026年7月18日にマージされ、36件のチェックとファイル1件の変更が表示
  • 変更量は64行追加と54行削除で、ファイル形式はJSON

確認できる限界

  • ページのファイルおよびコメント領域で読み込みエラーが表示され、実際のJSON diffは提供された本文では確認できない
  • 再現手順、変更理由、互換性への影響、レビューのフィードバックなどは本文に含まれていない

関連記事

1件のコメント

 
GN⁺ 1 일 전
Hacker Newsの意見

  • 圧縮すれば解決すると言われがちだが、自分の作業では圧縮で失われる細部が多すぎる。
    計画が単純だったり、かなり細かい議論をしないのであれば問題ないかもしれないが、長いコンテキストが足りないせいで結局Anthropicを使い続けることになる。
    複数の論文や大きく複雑な資料を丸ごと記憶しておく必要があるときは、コンテキストは常に16%にとどまる。5分ほど会話すると圧縮され、また資料を読ませて16%に到達する、という過程が繰り返される。
    372kコンテキストも完璧ではなかったが、12〜20%だった余裕を約40%まで増やしてくれたので大いに助かった。

    • 自動圧縮をオフにできず、圧縮前の会話履歴にも戻れないため、5千行を超えるコードベースではCodexを使えない。
      残りコンテキストが10〜20%のときにランダムに実行されるので、272kの80%しか実質的に使えない。圧縮後は幻覚がひどくなり、最初から始めるより悪く、コードベースを再び読ませているうちにまた圧縮される循環に陥る。
    • 自分の設計プロセスは違う。何度も修正するplan.mdこそがメモリであり、セッションを再開して計画を読み直し、検討すると新しい視点が得られやすい。
    • 圧縮がひどいので、LLMがコンテキストの一部を選択的に削除し、必要なときに復元できるツールを作った。自動圧縮の限界に頻繁に達するなら、context bonsaiを試す価値がある。
      https://github.com/Vibecodelicious/context-bonsai-agents
    • Anthropicのモデルは100万トークンのコンテキストを提供している。来月OpenAIへ移るつもりだったが、まだ約300kにとどまっているとなると、新しい現実に適応する必要がありそうだ。
    • 通常は、エージェントにときどき.mdファイルを作成または更新させ、新たに現れた重要情報を記憶させるよう勧める。しかし何が本当に重要かをエージェントが正確に分かっているなら、/compactもうまく動くはずだ。

  • 大きなコンテキストウィンドウのせいで何を入れるか選別しなくなり、圧縮は全体に非可逆圧縮を一括適用して、必要な細部まで失わせてしまう。
    毎回会話全体を再送信すること自体が根本的な問題だと思う。自分が作ったメモリ／コンテキストプラグインで毎回コンテキストを空にし、関連情報だけを再注入するようにしたところ、モデルは20万トークンの会話履歴ではなく、選別された数千トークンの状態だけを読むようになり、小さいコンテキストは問題にならなかった。
    コーディングエージェントではまだ解決できていないが、作業完了や次の作業に必要なものだけを残し、残りを捨てる保持ポリシーこそが本当の解決策であり、専用LLMで実装できると思う。

    • LSTMやGRUなどを研究してきた多くの自然言語処理の専門家も、会話全体の再送信を根本的な問題と見ていたが、実証的にはTransformerが勝利した。
      将来のモデル構造がこの問題を再び考慮するのか興味深い。人間を基準にすれば、まだ足りないのは短期記憶から長期記憶へ情報を効率的に移す能力であり、ファインチューニングは原理的には似たことをするが効率的ではない。

  • これが今回の変更理由なのかは分からないが、そもそもこれより大きなコンテキストを使うのは概して間違いだと思う。
    コンテキストが大きくなるほどモデルの性能がどれだけ落ち、トークンコストがどれだけ増えるかを過小評価している。Claudeでは300k以上を使わず、圧縮する代わりに作業を分割し、ドキュメントとモジュール式コードベースを簡潔に保っている。
    その場限りの作業では大きなコンテキストが有用なこともあるが、300kを常時超えるなら、多くを失っているか、コードベース設計が良くない可能性が高い。

    • 自分も250kで圧縮するか再開する。必要なコンテキストサイズはプロジェクト規模に比例するので、より大きなウィンドウが必要な人たちは、単により大きなプロジェクトを扱っているのだと思う。
    • 自分の体感も同じで、境界はむしろ100〜150kに置く。モデルが長いコンテキストをサポートしていても、実際の性能は良くない。
    • コンテキストが大きくなるとモデルが目に見えて鈍くなるという点は、自分の体感とは違う。遅くなり高くはなるが、複雑な作業には受け入れるべきコストだ。
      メインエージェントがサブエージェントに必要事項を調査させて計画を作成し、その後、別のサブエージェントに敵対的にレビューさせて補強する。終わると**100万トークンウィンドウの30〜40%**が埋まり、272kでは不可能な流れだ。
      5.6 Solではこのプロセスを大幅に縮小せざるを得ず、結果が悪くなる理由もおそらくそこにある。

  • この変更が起きたとき、Tiboが説明をあわせて投稿していた: https://x.com/thsottiaux/status/2076543065045795309

    • 返信はこちらで見られる: https://xcancel.com/thsottiaux/status/2076543065045795309
      リンク先のツイートはTiboの公式情報に対する非公式の返信であり、Tiboが返信で内容を訂正している。
    • このチャートが理解できない。圧縮しているのに線が上がり続ける理由は何なのか、それとも「overall trajectory size」に自分の知らない意味が隠れているのか気になる。
    • 推論の強度が違うのに全体の軌跡長が同じになり得るのか分からない。推論トークンを軌跡長から除外したとしても、可能には見えない。

  • 彼らのコンテキスト圧縮は好みではなく、今では最低100万トークンを提供すべきだと思う
    GPT 5.5と5.6は圧縮されるたび、本来の速度に戻るまでぎこちなくなり、圧縮されたコンテキストに残った古い指示メッセージに過度に集中することもある

    • GPT-5.6-SolはOpus/Fableよりトークン効率がおよそ2倍なので、最大258kがClaudeの約516kに相当する
      コンテキスト劣化は依然として問題で[1][2]、エージェント作業では圧縮が長いコンテキストと同等、またはそれ以上だという根拠もある[3]。モデルが256kと同じように100万コンテキストでも推論できれば最善だが、まだ不可能だ
      [1] https://arxiv.org/abs/2605.12366
      [2] Opus 4.8 System CardのGraphWalks 256Kと1M F1の比較: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
      [3] https://context-folding.github.io/
    • 他のコーディングツールと違い、自動圧縮を無効化できないのがもどかしい。残りコンテキストが10〜20%のときに不規則に実行されるため、保証される容量は272kの80%だけだ
      大きなコードベースで作業がほぼ終わり、残りは2千トークン程度の応答だけという段階でも、20%を下回るとしばらく処理した後にContext compactedが表示される。圧縮前に戻れないため、コードベースを再調査しているうちにまた圧縮され、結局トークンをすべて使い切る
    • トークン削減が利用量を増やすための迂回策ではなく、主にコスト削減のためであってほしい。会社でもコスト担当者がコンテキストを極端に制限し、最初は使えた社内LLMをほとんど役に立たないものにしてしまった
      経営陣同士で最悪の慣行を共有する集まりでもあるかのようだ
    • 作業メモリはMarkdownファイルに保存すればよく、大きなコンテキストは必要ない。コンテキストが増えるとアテンションが分散してLLMの性能が落ちるため、小さく保つほうが品質に有利だ

  • 日常的にOpusを使っており、/clearをよく実行する。100万コンテキストでも50%に近づくと急速に性能が低下するので、通常は30〜40%で初期化するとずっと良い結果が得られる
    圧縮よりも新しく始めて、必要なコンテキストを最初から入れるほうがうまく機能する。機能別のMarkdownドキュメントを複数の技術コレクションとして整理しておき、初回ロード時に作業関連情報をどこで探せばよいか伝える方法が効果的だ

  • Codexではコンテキストサイズが問題だと感じたことがない。圧縮方式は分からないが、制限がないかのように進み続ける

    • Codexを最近使い始めたようだ。初期には、圧縮でも回復できない**model context size exceededエラー**がひどく、ほんの数か月前から消えた
      今はかなり良くなったが、圧縮後のconcise summaryに何が入ったのか見せてくれないため、重要な内容が保持されたか分かりにくい
      Codexはユーザーからできるだけ隠す方向に進んでいるようで、最近エージェントとサブエージェント間のプロンプトを暗号化したように、セッションログ全体も暗号化できそうに見える。残念ではあるが、これまで使った中では依然として最高のツール・モデルの組み合わせだ
    • Codexは圧縮が発生すると、最後の作業を完了することをよく忘れる。特に圧縮直前にメッセージを送ったときにひどい
    • ほとんどの問題は分割統治できるので、300kと400kの差が問題になることはほとんどない。コーディングエージェントは無限の会話ではない

  • 圧縮がどれだけ優れていても、大規模プロジェクトでは多くのファイルを読む必要がある。最初の20万トークンは非常に速く消費されるが、その後は速度が落ちる
    Fableのセッションはほとんどが50万トークンを超えず圧縮は不要だが、Codexでは1つのセッションで圧縮を繰り返す必要がある

    • 多くのファイルを読む必要があるのは、agents.mdが不十分だからだと思う。実際の作業ファイルといくつかの関連ファイルだけを読めばよく、残りはドキュメントに整理されているべきだ

  • 自分の作業にはかなり小さいサイズだ。200k未満に抑えようとしているが、DeepSeekとMiMoのセッションで最後の反復作業を押し切ると、350kトークンまで増えてから圧縮することもある
    OpenAIが公開論文に出ているDeepSeekのK/Vキャッシュ技術を導入して、コストを大幅に下げられないのか気になる

    • DeepSeekほどキャッシュがうまいところはないので、実装の差が大きく、まねるのは難しそうだ
      DeepSeekをReasonixと一緒に使うと、キャッシュ構造に合わせた追加の専用方式になっており、長いセッションではトークンの97〜98%がキャッシュされる。すでに安いモデルがさらに安くなる
    • llamacppベースのローカル公開モデルでは、エージェントが指示して55k〜85kの間で圧縮し、複雑なログ追跡のように大きなコンテキストが必須でなければ、120kまで行くことはまれだ
      llamacppの推論予算とメッセージに合わせて、エージェントがサブエージェントを生成した後に内容を圧縮するよう、システムプロンプトも調整した。opencodeの動的コンテキスト枝刈りを使い、ボリュームを増やさず方向性だけを維持しながら、複数のサブコンポーネントを反復開発するのにおおむねうまく機能している

  • この2か月、自分の用途ではずっと良かったので、ClaudeからOpenAIへ移行した。今回の変更で出力品質の差が体感できるか気になる