OpenAI、巨大なChatGPTおよびCodexスレッドの読み込み時間を16倍短縮とベンチマーク

Why it matters

Agent products increasingly live inside long, tool-heavy threads. OpenAI's test suggests the desktop client can keep those histories usable without loading every transcript item at once.

Andrew Ambrosino (@ajambrosino), who leads OpenAI's Codex desktop app, has benchmarked a new approach to loading extremely large ChatGPT and Codex conversations, cutting the test thread's load time from 27.62 seconds to 1.66 seconds.

テストでは741ターン、231 MBの会話を使用しました。According to Ambrosino's post on X, the revised implementation also produced 87.8% less JavaScript heap growth in the conversation renderer and 41.2% less memory growth across the application.

The benchmark's "94% faster" label describes a roughly 94% reduction in elapsed time. Measured as a speed multiplier, the conversation loaded about 16.6 times as fast.

Dan (@DanDr1s) circulated the results on August 15th as an upgrade for long ChatGPT and Codex conversations. The numbers describe client-side conversation loading and rendering, rather than model inference speed, answer quality or the time required for Codex to complete a task.

トランスクリプトの読み込みを減らす

他の2つの測定が、利得の発生源と考えられるものを示しています。リクエスト数は894から16に減少し、98.2%の削減となり、最初に読み込まれたトランスクリプト項目の数は15,529から64に減少し、99.6%の削減となりました。

これらの数字は、改良されたクライアントが従来の「巨大なスレッドを一度にアプリケーションに読み込む」パターンを回避していることを示しています。制限された数のトランスクリプト項目を読み込むことで、ユーザーが会話とやり取りできるようになる前に、ネットワーク層、JavaScriptランタイム、レンダラーが行う作業を削減できます。ベンチマークはユーザーがスクロールして過去のメッセージを取得する仕組みを示していないため、スムーズなページネーションと安定したスクロール位置の保持が体験の中心となります。

The distinction matters because a long conversation can fail at several separate layers. A model may still have enough usable context to continue the task while the desktop interface stalls under the weight of rendering the stored transcript. Reducing the number of items hydrated into the client attacks that interface bottleneck without changing the model or shrinking the underlying conversation.

長いスレッドは製品上の制約になっている

このベンチマークは、OpenAIのデスクトップソフトウェアにおける文書化された痛点に対処しています。7月、あるユーザーがOpenAIのCodexリポジトリで報告しましたが、フルヒストリーがローカルに保存されたままでアプリサーバーが引き続きトランスクリプトページを返しているにもかかわらず、アップデート後に古いターンにアクセスできなくなったという問題がありました。報告は、ページネーションされた履歴を可視化された仮想トランスクリプトにマージする際の問題を指摘していました。

別の長時間セッションの失敗を集めたCodexのイシューは、会話状態が蓄積するにつれてフリーズ、メモリ増加、アクティブなターンの制御喪失を記述していました。これらはユーザーからの報告ですが、トランスクリプトの読み込みが見た目の最適化ではなく、エージェントソフトウェアにとって核心的な製品上の問題になっている理由を示しています。

OpenAI自身の利用データも重要性を高めています。OpenAIは2026年6月の研究投稿で、5月におけるCodexユーザーの70%以上が人間であれば1時間以上かかる作業をエージェントに依頼したと述べました。より長いタスクはツールの出力、中間的な推論記録、ファイルの変更、繰り返されるフォローアップのターンを生み、典型的なチャットボットのやり取りよりもはるかに大きな履歴を生成します。

Ambrosinoのベンチマークはその利用パターンの累積コストをターゲットにしています。231 MBのテスト会話での16.6倍の改善は、ハードウェア、OS、通常の本番スレッド全体で結果が保持されるならば、大規模プロジェクトの再開や継続をかなり妨げにくくするでしょう。OpenAIがこの作業を公開ビルドに組み込むまでは、これらの数値は現在のChatGPTおよびCodexユーザーに対する性能保証ではなく、ベンチマーク結果にとどまります。