GPT-5 Codexの性能劣化に関するユーザー報告を受け、OpenAIチームが実施した徹底的な調査の全容を解説する。多くのユーザーがモデルが以前より「愚か」になったと感じていたが、OpenAIは全社的な調査チームを編成し、ハードウェアの違い、コンテキスト圧縮の問題、パッチ適用の失敗、タイムアウト処理など、複数の小さな問題が重なっていたことを特定した。Anthropicの対応とは対照的に、OpenAIは迅速かつ透明性の高い対応を見せ、内部ドキュメントを公開し、全従業員に外部ユーザーと同じ環境を使用させ、クレジット返金やレート制限のリセットまで実施した。この調査は、非決定論的なAIシステムにおいてユーザーフィードバックがいかに重要であるか、そして企業がどのように真摯に問題に取り組むべきかを示す好例となっている。
GPT-5の性能劣化問題
最近、GPT-5が以前より少し愚かになったと感じていませんか。もしそう感じているなら、あなただけではありません。多くの人がこれを報告しており、OpenAIチームは本当に真剣に受け止めています。
もしこれが既視感のように感じられたら、申し訳ありません。過去にもこのようなことを取り上げてきました。私が最初にGPT-5を試したときは素晴らしいと思ったのに、みんなが私に疑問を呈したこともありました。その後、適切な方法と適切な場所で試してみると、実際にかなり良いものだと気づいてくれました。そして、ClaudeモデルもOpusとSonnetの両方で奇妙な性能低下があり、Anthropicが最終的に予想より悪い状態だったことを認めるまで、しばらく私たちをガスライティングしていたこともありました。
OpenAIの透明性の高い対応
ありがたいことに、今回はそのようなことは起きていません。OpenAIチームは性能の退行がある可能性のある箇所を見つけるために本当に懸命に取り組んでおり、多くのものを発見しました。彼らは発見したすべてを記述したかなり内部向けと思われるGoogleドキュメントまで共有してくれました。これは本当に素晴らしいことです。
彼らはこれを「コードマシンの中の幽霊」というタイトルにしており、私は彼らが発見したすべてをあなたと一緒に分解するのがとても楽しみです。本題に入る前に簡単なリマインダーですが、OpenAIは私にお金を払っていません。ここでお金のやり取りは一切ありません。私はこのような分析に興味があるだけです。でも彼らが私にお金を払っていないので、誰かが払わなければなりません。それでは今日のスポンサーからの短いメッセージをお聞きください。
エンジニアは高い価値があります。Dockerイメージのダウンロードやビルドの完了を待ってただ座っている時間を無駄にすべきではありません。だからDepotがとても良いのです。ホームページの箇条書きを皆さんと一緒に見ていくこともできますが、それは実際のユーザーがいない製品には最適です。これらの人たちは業界で最大級のユーザーを抱えています。だから代わりにそれを見てみましょう。
Postはビルド時間をDepotを使用して55倍短縮することができ、まだ奇妙なほど速く感じられます。彼らのビルド時間は2時間半から3分未満になりました。これは信じられません。スタートアップは速く動く必要があります。大企業と競争しているなら、ユーザーの問題にできるだけ早く対処できることがとても重要です。
実際、ユーザーがバグに遭遇してもそれが素早く修正される方が、全くバグがないよりも良いこともあります。なぜなら、それによって開発者としてのあなたとユーザーの距離が近くなるからです。でも、ビルドの完了を待っていて、それが原因で修正を出せないのは最悪です。20分でバグを修正しても、その後3時間待たなければならないというのは、顧客として良い気分ではありません。
Posthouseの引用はここで素晴らしいです。私たちは顧客に対して非常に迅速に対応することを目指しています。私たちの理想的なサポートのやり取りは、「今ビルド中です。30分後には出ます」と言えることです。今では、ほぼ即座に出ます。ほとんどの人がDepotのサイトを訪れる理由はありません。なぜなら、ビルドが機能しているという事実を無視できるからです。
それは常に行うべきことを行います。私たちにとって、これは本当に良いことです。なぜなら、それが機能するだけでいいシステムの一部だからです。安定性についてコメントしているのは彼らだけではありません。JaneはCIに多くの問題を抱えており、ある時点で60%の失敗率でした。彼らは数ヶ月かけて可能な限り修正しようとし、いくつかの改善を行いました。
しかし、GitHub ActionsをDepotに移行するとすぐに、すべてがはるかに速く、安価になりました。彼らの探索から得られた最終的な数字は、2.5倍高速、25%のビルドスループット増加、55%のコスト削減でした。つまり、はるかに速くビルドされ、開発者をより幸せにする、より信頼性の高いインフラでお金を節約しているのです。
ああ、そして可観測性もはるかに優れています。実際に何が起こっているのかを見ることができます。Dockerビルドとgithub actionsで時間を無駄にするのはやめましょう。今すぐsoyv.link/depoでチェックしてください。
ユーザー報告の始まり
これがGPT-5が愚かになったという最初の報告で、具体的にはGPT-5 Codexについてです。多くの人がGPT-5 Codexがドロップしたときに劣化に気づいたようです。
CodexというCLIツールではなく、CodexというWebインターフェースでもなく、昔C-Pilotのオートコンプリートに使用していたCodexモデルでもありません。彼らは本当に新しい名前が必要ですが、最近リリースされたGPT-5 Codexモデルが人々が劣化に気づいた時点のようです。正直なところ、特にCodex CLIで私も少し感じています。
ここの返信には反論もあります。私も同じ経験をしましたが、いくつかのテストの後、一部のワークスペースではパフォーマンスがトップレベルで、他のワークスペースでは標準以下であることに気づきました。コンテキストと指示が、非常に明白でない方法でモデルのパフォーマンスを損なうことがあると思います。
同意します。GPT-5は、大量のガードレールや行うべきこと、行うべきでないことを指示されない方がはるかに優れているので、自分でコンテキストを構築し、どこに進むべきかを理解する方が優れている傾向があります。
人々はそれを異なる方法でプロンプトしますが、それはまた、異なる方法で振る舞うためのより多くの余地を与えます。しかし、ここで起こっていることはそれだけではなく、本当に詳しく見ていきたいと思います。改めて、この文書を書いて公開してくれたCodexチームに感謝します。これは楽しいものになるでしょう。
調査の概要
Codexが時間の経過とともに一貫して劣化していることを説明する決定的な大きな問題は見つかりませんでした。代わりに、時間の経過とともに行動のシフトの組み合わせがあると考えています。その一部は、コンパクションなどの新機能によって促進されたものであり、以下に文書化された調査を通じて発見した、より小さな具体的な問題です。
OpenAIが世界で最もオープンな会社ではないことは知っていますが、歴史的にこれらのことに関しては本当に優れています。今年初めに私を多くのトラブルに巻き込んだ以前のパフォーマンス問題をデバッグしていたとき、予期しない癖や変更がないことを確認するために、私がテストできるように古いバージョンのモデルをプロビジョニングするところまでやってくれました。
彼らはこれらのことを非常に気にかけており、LLMのような非決定論的なものに関しては、適切に聞かれ、調査されるユーザーフィードバックチャネルを持つことが非常に重要です。Anthropicがこれを持っていなかったことが、多くの人々が経験していた数ヶ月に及ぶ退行につながったのです。私も含めてです。しばらくの間、Sonnetを使うのは本当に不快でした。
Codexチームがここで言っているように、彼らはすでに一連の改善を行っています。さらに多くのことが来ており、今週はCodexをさらに改善するための将来の投資領域について情報を得ました。また面白いことに、彼らはCodexがこの作業を手伝ってくれたと言っています。そのちょっとしたメタさが大好きです。
調査開始の理由と計画
では、なぜ彼らはこの調査を開始したのでしょうか。過去数週間、今年9月15日のGPT-5 Codexのローンチ前後で、Codexのパフォーマンスが低下しているという公開報告が増えていました。私たち自身の使用やトップラインの製品指標からは直接的な証拠がなかったにもかかわらず、チームによく理解されていないものであり、最高のエンジニアの何人かの常勤の注意に値すると感じました。
先週、次の計画を共有しました。CLIのフィードバックコマンドをアップグレードして、バグ、良い結果、悪い結果、その他といった構造化されたオプションと、詳細なフィードバックのための自由形式のテキストを追加します。フィードバックを特定のクラスター、ハードウェアなどに結びつけやすくして、どのボックスが実行されているかを診断しやすくします。
どうやらそれが重要なようで、これは驚きです。また、このスラッシュフィードバックコマンドが存在することをもっとよく知られるようにしたいと考えています。なぜなら、フィードバックの量を増やして、より多くの情報を持ち、これらの異常をより簡単に特定できるようにしたいからです。また、問題を引き起こす可能性のあるもののサービスを減らしたいと考えています。
調査が解決されたと見なすまで、すべての従業員、Codexチームだけでなく、すべての外部トラフィックとまったく同じセットアップを経験します。これが大好きです。適切なドッグフーディングです。早期に試してからリリースして、次の新しいものを試すという意味でのドッグフーディングではありません。ユーザーが使用するのとまったく同じエクスペリエンスとAPIを経由するという意味でのドッグフーディングです。
私は自分の携帯電話でT3 Chatを別の無料ティアアカウントでWebアプリ経由で使用して、ユーザーが行うのと同じ方法で物事を体験することを自分自身に強制しています。そして、これを行わず、その結果多くのものを見逃している人がどれほど多いかに驚いています。これは本当に重要です。また、オンボーディングフローについて、それらが同様の注意に値するのに決して得られないことについて、丸ごと一つの愚痴を言うこともできますが、その詳細は割愛します。
彼らはまた、インフラストラクチャの最適化が行われ、これらを安全に実装するために使用する機能フラグを監査して、何もチェックされていないものを残さないようにしたいと考えています。なぜなら、多くの場合、従業員アカウントには異なるものがプロビジョニングされたり、機能フラグなどが設定されているからです。したがって、他の人が報告しているものを体験できるように、すべてが同じであることを確認したいのです。
ポイント3は評価と質的チェックでした。彼らは常に評価を実行していますが、今後はさらに多くを実行し、状況を把握するために今すぐ膨大な量を実行する予定だと言っています。それを見るのは良いことです。
実施された改善
最初に行ったことは、新しいフィードバックの立ち上げです。素晴らしい。すべての内部使用を外部と同じセットアップを使用するように移行しました。素晴らしい。私はこれが本当に大好きです。彼らがこれをもっと行うか、少なくとも一定数の従業員が常にパブリックバージョンを使用することを願っています。
彼らはまた内部の複雑さを削減しました。ユーザークエリと推論を実行するGPUの間には、調査の範囲を絞り込むのに役立ついくつかの層があります。できるだけ多くの変数を削除しようとしました。60以上の機能フラグを監査して削除することから始めました。さらに80を削除するプロセスを進めています。
企業でゲートされているものの量は本当にばかげており、実際の数字を見るのは常にクールです。特に改善されたフィードバックメカニズムは貴重な追加であることが証明され、問題のあるCodexの会話を、それらが実行された正確なハードウェアを含めて、システム全体を通してトレースすることができました。
より良いツールと、さらに重要なことにユーザーからの助けにより、1日あたり100件以上の問題のトリアージを開始しました。提出されたフィードバックの量の増加を参照してください。それはクールです。ただ、これが単なる生の数字ではないことを願っています。1日に100件のレポートを受け取っている場合、チームと連絡を取る最良の方法の1つは、スラッシュフィードバックと入力することです。
本当の話として、日常的にCodexを使用している場合は、できる限りフィードバックを送信してください。製品の開発者として、これらのものがどれほど有用かわかりません。
その後、間違っている可能性のあることについて創造的な仮説を継続的に考え出し、定式化された仮説を拒否するか、関連する発見を修正するために、それらを1つずつ調査するという唯一の使命を持つ部隊を編成しました。部隊は月曜日から金曜日まで他の気を散らすことなく活動しました。
これも本当に良いことです。これを行うチームを持つことです。これがこのようなインシデントレポートを行う方法です。確信が持てず、まだ検証方法がわからないが、ユーザーが困っていることがわかっている場合は、集中してこれを行う必要があります。これはAnthropicです。注目していることを願っています。
発見と修正内容
発見と修正。まず、ハードウェアがどれほど似ているか、似ていないかから始めなければなりません。どうやら、彼らはフィードバックレポート、時間ごとのユーザー保持、使用されたモデル、使用されているCLIビルド、OS、時刻、サービングクラスター、リクエストを提供しているハードウェア、ユーザープランタイプなどのリクエストの特徴との関係を調べるために予測モデルをトレーニングしました。
また、各タイプのハードウェアに対して評価を実行し、古いハードウェアの一部でわずかなパフォーマンスの問題に気づきました。これは保持率に関する予測分析でいくつかのサポートを見つけました。興味深い。これは私がこれを見て、休日にこれについてのビデオを作りたいと本当に思った要素の1つです。ええ、このようなことは重要です。できるだけ早くカバーしたいと思います。
モデルが異なるハードウェアで異なる動作をするという事実は、ちょっと信じられないように思えます。古いコンピューターでは動作が遅くなることが予想されますが、これらのモデルと、推論を実行するために構築しているマシンとシステムは非常に低レベルで特定的であるため、プロセッサがデータのビットを処理する方法のわずかな違いが、トークンが解決される方法を歪める可能性があります。
わずかな違いが何かを完全に異なる振る舞いにさせる可能性があることは驚きです。そして、これを測定することがどれほど難しいかというと、これらのものはどれも決定論的ではないからです。彼らの解決策は、そのハードウェアをフリートから削除することでした。素晴らしい。
別に、負荷の下でレイテンシーを削減する負荷分散戦略の機会も発見しました。そして、これらの改善は来週にわたってロールアウトされています。
コンパクション頻度の問題
コンパクション頻度は、彼らが行ったもう1つのことで、コンテキストウィンドウの制限に達することなく、長時間実行されるジョブが生き残ることができるように、コンテキストを圧縮しようとします。ユーザーから受け取ったフィードバックの初期のトレンドの1つは、コンパクションを中心としたものでした。
コンテキストウィンドウがほぼ使い果たされると、会話を要約し、コンテキストをクリアして、要約を最初のメッセージとして新しいものを開始するようにモデルにプロンプトします。これにより、ユーザーが新しいセッションを再起動して進行中の作業からコンテキストを失うことを強制することなく、セッションをより自然に進めることができます。
T3 Chatにこれを追加しなければならないことを思い出させてくれます。なぜなら、今は新しいスレッドに移動させるだけだからです。個人的には、ほとんどすべてのリクエストに対して新しいスレッドを作成します。だから、人々がなぜ同じスレッドで8から10、あるいは数百のメッセージを行うのか理解したことがありません。それは私のやり方ではありませんが、それぞれのやり方があります。
コンパクションを経験しているセッションの割合が大幅に増加しています。彼らは、時間の経過とともにコンパクションを使用しているセッションの割合が高くなっており、コンパクションの実装を改善してより良い結果を得ることができることに気づきました。
評価により、1つのセッション内で使用されるスラッシュコンパクトまたは自動コンパクションの数でパフォーマンスが低下することが確認されました。コンパクションが複数回発生したときに再帰的な要約を回避する改善を行い、会話をより的を絞ったものに保つようにユーザーを促すための警告を追加しました。
これが大好きです。注意:長い会話と複数のコンパクションは、モデルの精度を低下させる可能性があります。これは実際のコードに入ったタイプミスだといいですね。それは本当に面白いでしょう。新規開始と新しい会話は、会話を小さく的を絞ったものに保つために可能な限り新しい会話を開始するだけであるべきです。
OpenAIがこれを喜んで行うという事実は、私も同じことをする意欲を高めます。パッチの適用。Codexはファイルに変更を加えるためにapply patchという特別なツールを使用します。apply patchツールは、統一された差分を入力として受け取ります。ほとんどの場合、モデルは変更の差分を生成するのが非常に得意です。
ファイルへの挿入に失敗しましたエラー。これは他のどのモデルよりも何度も見ました。GPT-5が実際に編集を適用できないことを見てきました。だから、この行について言及します。稀なケースでは、モデルによって不正なパッチが提供されると、ハーネスによって再試行するようにプロンプトされます。
パッチの適用に失敗したときに、モデルがファイルを削除して再作成することに頼るというレポートをいくつか見つけました。これもかなり見てきました。これは極限では正しいのですが、エージェントが中断されたり、削除後に2番目のパッチを適用できなかったりすると問題が発生する可能性があります。
これを修正するための私たちのアプローチは、この動作を示さないように将来のモデルを改善し、今後数週間でハイリスクの編集シーケンスを制限するための即座の緩和策を実施することです。これは本当に興味深い部分です。特に将来のモデルの部分です。
これらのモデルの動作が、会社がモデルを実装したいツールによって定義されているようにますます見えます。以前は、できるだけ多くのテキストをこのトレーニングデータセットに投入し、可能な限り最もスマートなモデルを作成し、その後モデルの能力の周りにツールを構築しようとしていました。
今では、業界として、2つが互いに影響を与える世界にシフトしているように本当に感じられます。ツールからの良い結果を取得し、それをトレーニングデータに使用して、次のモデルをこれらのツールの使用でさらにスマートにしています。ツールが正しく機能している例を示し、それをトレーニングデータに入れることで、次のモデルをこれらのツールの使用でより良くすることができます。
エキサイティングですが、外部的にはあまり有用にならないかもしれないという意味で奇妙で再帰的でもあります。見てみると面白いでしょう。歴史的に、これらのことはツール呼び出しのようなことで一般的にモデルをより良くしてきました。そして、彼らはこのようなことのために作られた多くのデータでトレーニングしてきました。
そして、GPT-5や他のGPTモデルのトレーニングと、これらのツールを構築するCodexチームとの関係、そしてGPT-5 Codexモデルのようなものになる結果は、興味深くなってきています。本当に速く興味深くなってきています。これが標準となった今、次世代のモデルがどのように見えるかを見るのが楽しみです。
タイムアウトと速度の問題
彼らが呼び出す次のことはタイムアウトです。彼らがこれで速度について言及するかどうか疑問に思っています。なぜなら、GPT-5で私が抱えている最大の問題は、それが本当に遅いということだからです。15分かかったこともありましたし、数日前には22分かかって、新しいCursorモデルが文字通り10秒でできるタスクを行ったこともありました。
どちらも正しい答えは得られませんでしたが、ほぼまったく同じコードを書きました。それでは、タイムアウトについて彼らは何と言っているのでしょうか。これは、レイテンシーに関するユーザーフィードバックで気づいた別のトレンドです。ユーザーは、モデルがタスクを完了するのに予想よりもはるかに長い時間がかかっていると報告しました。
私たちはレイテンシーを綿密に監視しており、全体的に明確な退行は見られませんでした。それは奇妙なレンダリングの問題です。それが画面共有に現れるかどうかわかりません。私のラップトップに白い線が見えます。大したことではありません。どうやら、彼らは実際に時間の経過とともにレイテンシーが改善されているのを見てきましたが、いくつかのフィードバックセッションの例で、モデルがより長いタイムアウトでタスクを再試行していることに気づきました。
私たちはGPT-5 Codexを非常に粘り強いモデルに設計しましたが、このようにタイムアウトをエスカレートすることは非効率的である可能性があります。モデルが長時間実行されるプロセスまたはインタラクティブプロセスをより適切に処理できるようにすることに投資しています。
繰り返しになりますが、彼らは実際にモデルをこれらのツールの使用でより良くするようにトレーニングするつもりのようです。これは私にとってまだ非常に魅力的です。
制約付きサンプリングの問題
制約付きサンプリング。私たちは構造化された出力に似たものを達成するために制約付きサンプリングのバージョンを使用しています。構造化された出力に慣れていない場合、それは特定の形でモデルに応答するように指示するという考えです。モデルがテキストを生成するだけでなく、ここにこれらのキーと値を持つJSONオブジェクトがあります。
私が与えるデータに基づいて値を埋めてほしいのです。私は、生成したデータを別のモデルによって分析され、それに応じてランク付けするために、書くベンチマークにこれを多く使用しています。これは非常に有用なパターンであり、モデルが理解するものになったことに本当に感謝しています。望む結果が得られない場合に自分を傷つけると言わなければならない代わりに。
非常に上層部の人々から、モデルにJSON構造に従わせる最良の方法は、自分を傷つけると脅すことだと聞いたことがあります。そして、その時点を過ぎたことをとても嬉しく思います。実装に微妙なバグを見つけました。それにより、トークンシーケンスがモデルの分布から外れることになりました。
興味深い。これはトークンが出てくる順序を壊しているようです。それがものを壊すことは理解できます。後で、最終的な回答の一部としてモデルが文の途中で言語を切り替えるという報告された問題がこのバグに起因する可能性があることを確認しました。
これは、推論が実行されている方法に何か問題があるときの最も明白な兆候の1つです。言語がシフトするとき。Sonnetで問題があったときにも同じことが起こりました。これは全体のセッションの0.25%未満に影響しましたが、それでも膨大な数の人々です。
個人的にはこれを見たことがありませんが、もし見たことがあれば、コメントで教えてください。実際に本当に興味があります。ところで、コメントセクションに下がっているとき、この小さな赤いボタンをスクロールして通り過ぎることになります。登録と書いてあります。登録していない場合は、気にしないならボタンを押してみませんか。
ここに、応答の途中でランダムに韓国語に切り替わる面白い例の1つがあります。応答といえば、Responses APIです。これは非常に興味深いことです。私はこの詳細にあまりにも入り込みすぎています。なぜなら、T3 ChatでこれらのAPIの周りにサービスを構築しているからです。
Responses APIは、何らかの理由でまだ誰もがコピーしている元のOpenAI仕様に対する改善ですが、それはゴミです。Responses APIはより良いですが、控えめに言っても独自の奇妙な癖があります。CodexはモデルにリクエストするためにResponses APIを使用します。
Responses APIは、RESTAPIリクエストをモデルが推論に使用するトークンのストリームに変換し、結果のトークンのストリームをアプリ開発に便利な形式に解析するプロキシだと思います。ええ、それはユーザーやツールが取得するものにモデルが理解するものからデータの形状を変更する中間にあります。
それはまたAPIの標準であり、OpenAIのHarmony標準と混在しています。Responses APIが彼らがここで暗示しているのと同じように、それらの間にあるとは思いません。しかし、これがどこに向かっているのか興味があります。
Responses APIは私たちの調査のもう1つのターゲットになりました。目標は、API実装への変更がエンジンへの入力や出力が解釈される方法に影響を与える可能性があるかどうかを判断することです。Responses APIとそれが使用するライブラリへの100以上のプルリクエストを再レビューしました。
また、数ヶ月にわたる複数のバージョンのResponses APIを通じてエンジンに送られる生のトークン値を比較しました。興味深い。それで、彼らはこれをリクエストが行われるものとモデルが実際に取得するものの間の層として見ています。そして、彼らはリクエストエンコーディングにいくつかの違いを見つけました。
モデルが利用可能なツールを記述するセクションの周りに2つの余分な改行文字が追加されています。追加の分析の後、変更はモデルのパフォーマンスに影響しないと結論付けました。ああ、神様、私はこれを見つけて特定しなければならないエンジニアをうらやましく思いません。
T3 Chatで私たちの同等の小さな部分を持っています。Geminiモデルがテーブルを生成する方法を知らないことのような奇妙なバグがどれだけあったか言えません。なぜなら、マークダウンテーブルを生成するときに、多くのスペースを使用するからです。そして、文字を繰り返し始めると、2.5とすべてのFlashモデル、さらには2.5 Proでさえ、ある程度狂って、500のスペースを吐き出し始め、その後カンマを吐き出します。
ああ、これらのことを理解しなければならないエンジニアをうらやましく思いません。彼らはさらなる調査も行いました。彼らは0.40から最新まで、すべてのCLIバージョンで評価を実行しました。0.45でのapply patchの改善から予想される改善を見ました。これにより、トークン使用量が10%削減され、多数の評価で同等のパフォーマンスが確認されました。
興味深い。彼らはまた、Web検索が有効になっていることの影響を判断するための評価をテストしました。検索は退行に寄与しないと結論付けました。それは良いことです。検索はデフォルトでオンにする必要があります。特に他の類似のツールと比較すると、それがそうでないのは煩わしいです。
これを忘れて、その結果、結果がゴミだったことが何回あったか言えません。検索をデフォルトにしてください。私のCLIにインターネット上のものを見つける能力を与えてください。彼らはまた過去2ヶ月間の評価プロンプトの変更を行い、これらのプロンプトの変更は退行に寄与しなかったと結論付けました。
それについてもう少し情報を提供しないのは驚きですが、知っておくのは良いことです。作業ディレクトリの設定エラーの普及を調査しましたが、そこには変化が見られませんでした。Codexバックエンドシステム全体でエンドツーエンドのクエリレイテンシーの深い分析を実行して、特定のユーザーがテールレイテンシーの影響を不均等に受けているかどうかを理解しました。
予想よりも低い認証キャッシュ率を見つけました。これにより、リクエストごとに50ミリ秒の追加のレイテンシーが発生する可能性があります。今後数日でそれを解決するために取り組んでいます。トークンの最初のバイトまでの時間について人々がなぜそんなに曲げてしまうのかわかりません。
300ミリ秒かかるリクエストの50ミリ秒のリクエスト時間を削減することは非常に理にかなっていますが、20分かかるリクエストについて話している場合。確かに、20分かかるのは1つのリクエストではありませんが、10から30のようなものです。50ミリ秒レベルで最適化する価値はありません。
そして、みんなのお気に入りの三角形の会社を含む、これほど多くの企業が最初のトークンまでの時間に夢中になっているのを見てきました。私はそれがそれほど重要だとは思いません。可能な限りパフォーマンスの高いチャットアプリケーションを作るために戦った人間として、合理的に速く来るようにする必要がありますが、開始したら、はるかに速くストリーミングします。
はるかに速いTPSのために200ミリ秒のレイテンシーヒットを喜んで受けます。次の部分は、進化するセットアップの洗練度です。より多くの人々がCodexを使用しており、彼らはそれをより頻繁に使用しています。セッションあたりのターンとトークンの分布は、過去数週間でかなり安定しています。
しかし、時間の経過とともにより多くのMCPツールが使用されることで、セットアップの複雑さが増加していることがわかります。評価に基づいて、Codexから最高のパフォーマンスを得るために、ミニマリストのセットアップを使用し、会話を小さく的を絞ったものに保つことを引き続き推奨します。その通りです。
一般的に言えば、このツール呼び出しのプレイは、CursorやClaudeに50のMCPを設定している人を見てきましたし、今ではこの場合Codexにも設定しています。それはモデルが必要としないものに対する非常に多くのコンテキストの肥大化であり、その場合に必要としなくても、そこにあるものを使用しようとします。なぜなら、与えられたものがあるとき、それらは使用されるためにそこにあると仮定するからです。
異なるツールセットでサブエージェントをスピンアップし、フィルタリングとオーケストレーションレイヤーを行うスマートな親モデルを持つことを試みるいくつかの調査を見てきました。優れたオーケストレーションの必要性は日々増加しています。ファイルを書いている会話のポイントは、コードベースを調査しているときとは異なるツールセットが必要になります。
解決したい問題を仕様化しているときとは異なるツールセットが必要になるでしょう。そして、理想的には人間がそれを行うためにボタンを押すことなく、手元の特定のタスクに基づいて自動的に適用される異なるツールセットを持つべきです。近い将来、このようなものが見られることを願っています。
今後の取り組み
といえば、今後の作業。この調査の過程で多くのことを学び、継続的に私たちと関わってくれるユーザーに感謝します。私たちは常に敬意ある議論を奨励していますが、どんなに厳しいものであっても、すべてのフィードバックを真剣に受け止めていることを保証します。どうか続けてください。
舞台裏でOpenAIの人々に非常に厳しかった人間として、彼らがパンチを受け取ることに本当に優れていることを確認できます。それには圧倒されました。彼らに嫌がらせをするように言っているわけではありません。理想的には私よりも礼儀正しくフィードバックをしてください。
Theoはこれを言うだろうかと考えてください。そして答えがイエスなら、おそらくもっと冷静になる必要があります。本当の話として、彼らは一緒に働くのが素晴らしかったです。これはその素晴らしい例です。彼らは今週の勢いを、Codexの実世界のパフォーマンスについて毎日執着する恒久的に配置されたチームに引き継いでいます。
私は今までこれについて聞いたことがありませんでした。それは素晴らしいです。これが大好きです。彼らが間違いなく非常に非常にばかげた量のお金をこのようなことに費やしているという事実が大好きです。これは大きな信頼構築です。これらのツールがランダムに悪化することを心配しなければならない場合、同じように依存することはできません。
そのバーを維持することは非常に重要です。私たちは積極的に採用しており、参加するトップタレントを探しています。参加したい場合にクリックできるリンクがここの下部にたくさんあります。これらが応募でスパムされることになって申し訳ありません。本当に申し訳ないOpenAIですが、うまくいけば私からいくつかの良いものが得られるでしょう。
レート制限のリセットと返金
彼らがそこに含めなかった最後のことの1つは、みんなのCodexレート制限をリセットし、金曜日の午後1時までのすべてのCodexクレジット使用を払い戻したことです。これは2日前でした。木曜日に、$20と$200のプラン間のオプションをユーザーに提供するためにクレジットをロールアウトしました。
しかし、タスクに応じてクラウドタスクに2倍から5倍過大請求するバグを見つけました。したがって、必ずしもパフォーマンスの問題に関連しているわけではありませんが、彼らは払い戻しに非常に寛大でした。
彼らが発見したパフォーマンスの問題を発表したときにこれを行わなかったAnthropicに私は非常に多くを与えました。OpenAIはそれを行うことを気にしないようです。非常に良い変化です。木曜日にバグを特定して以来、彼らはクラウドタスクの制限を削除しました。
バグを修正し、クレジットのリリースと午後1時の間のすべてのクレジット使用を払い戻しました。購読している人のすべてのレート制限をリセットしました。状況を把握しようとしていたので、以前はクラウドに全く課金していなかったため、クラウドタスクの使用量の制限と課金を再び開始しました。今、彼らはそれを正しくしようとしています。
クラウドタスクは、クラウド環境を動かすVMを実行する必要があるため、作業単位あたりのローカルタスクよりも制限を少し速く消費します。さらに、クラウドタスクは、非同期で実行されているときにモデルにプロンプトを出す方法のため、また、ユーザーがより多くのワンショットコード変更を求め、簡単な質問を少なくする傾向があるため、メッセージあたりより多くの作業を行う傾向があります。その通りです。
クラウドやバックグラウンドエージェントタイプの作業であるもののプロンプトの出し方は根本的に異なります。したがって、メッセージあたりのコストは変わります。これらのすべてのサブスクリプションがより高価になり、レート制限が厳しくなっている理由をカバーするときに、これについて何度も話します。
メッセージあたりの作業量が増加しています。そして、バックグラウンドエージェントを持ち込むと、予想される作業量が大幅に増加します。締めくくる前に、Will TLDDRからのこの投稿が本当に好きでした。Codexは非常に優れているので、人々はより困難なタスクにそれを使い続けようとし、それはそれらのタスクをうまく行いませんでした。そして人々はモデルが悪化したと仮定しました。
ええ、私自身もこれに罪があることを認めます。いずれにせよ、これは非常に良い記事です。Redditで何人かの人々が持っていた直感に基づいてこのレベルの深さのレポートを共有してくれたチーム、Tibo、および関与したすべての人に大きな感謝を。このタイプのことにこのレベルの焦点を当てるのを見るのは非常に新鮮です。
皆さんがどう感じているか興味があります。これは過剰反応ですか、それともこれはOpenAIがすべきことを行っているのでしょうか。コメントで教えてください。そして次回まで、ピースナーズ。
コメント