Codexの週間上限が「溶ける」のはなぜか——6月の障害と7月の仕様変更を一次情報で分ける¶

7月24日時点の判定

対象: Codexの有料プランを継続利用し、週間上限の減り方に変化を認識している開発者

主張と判定	一次情報で確認できる範囲
週間枠の意図的削減：裏付けなし	OpenAI担当者はnerfを否定。週間枠の引き下げ値は公表されていない
未要求処理のusage消費：確認済み	6月にauto-review、subagent、background suggestionsの過剰動作を修正
5時間枠撤廃による急減：構造上あり得る	7月12日に短期枠を一時撤廃し、週間枠の前にあったブレーキが外れた
7月22日以降も同じ障害が継続：未確認	新しい報告はあるが、対応する公式事後報告は確認できない

Codexの週間上限が速く減るという体感には、公式に確認された原因がある。ただし、SNSで拡散した時系列には混同がある。 auto-review、subagent、background suggestionsの問題を説明した公式投稿は7月下旬ではなく、 6月29日の障害対応である。¹²

7月には別に、GPT-5.6の公開、5時間枠の一時撤廃、コンテキスト設定のロールバック、推論量とマルチエージェント利用の調整が続いた。³⁴⁵ したがって、6月の修正だけで7月下旬の報告まで「解決済み」と扱うことも、根拠なく「silent nerf」と断定することもできない。

Codexの週間上限が減る3経路

6月の障害では自動処理とusage表示の問題が複合した¶

OpenAI Statusは6月26日、「Codexのusage limitが想定より速く消費される」という報告の調査を開始した。 6月29日の解決報告では、一部のアカウントを不正対策システムが誤ってrate limitしていたと説明し、影響は限定的だったとしている。¹

同じ6月29日、Codex担当のTibo Sottiaux氏は、単一の中心原因ではなく、複数の小さな問題が一部ユーザーで重なったと公表した。² 公式投稿が分けた問題は次の通りである。

問題	実際に起きたこと	OpenAIの対応
auto-review	想定より積極的に動作した	関連変更を巻き戻した
subagent	別の変更により追加作業が増えた	実行量を抑える修正を入れた
background suggestions	二重実行や失敗後の再試行が過剰だった	scheduling、重複生成、retryを修正した
usage reporting	auto-reviewと失敗requestを誤表示した	独立分類し、成功requestだけを表示した

「実消費」と「表示上の消費」は別の問題である。 auto-reviewやbackground suggestionsは実際のバックグラウンドトークンを増やした。一方、rate limitされたrequestは課金されていなかったが、usage graphには誤って表示されていた。減って見える問題のすべてが、同じ課金バグだったわけではない。

OpenAIはCLI、デスクトップアプリケーション、usage backendへhotfixを配布し、全ユーザーの利用上限をリセットしたうえで、banked resetを1回追加した。異常なバックグラウンド消費を早期検知する監視も追加した。²

7月の変更は上限値より消費速度とペース配分を変えた¶

GPT-5.6 Solは7月9日に一般提供が始まり、Codexにも展開された。³ 翌10日、OpenAIは24時間以内にusage limitを2回リセットすると告知した。⁶ この時点では需要増への対応と試用促進が目的であり、週間枠の削減は発表されていない。

7月12日にはPlus、Business、Proを対象として、 5時間の短期利用制限が一時的に撤廃された。⁴ これは利用可能量の削減ではないが、使い方は大きく変える。従来は短期枠を使い切ると作業が止まり、結果として週間枠の消費にも間が空いた。短期枠がなければ、同じ週次予算を連続セッションで一気に使える。

翌13日、Sottiaux氏は「nerfではない」としたうえで、4つの調整を説明した。⁵

OpenAIが推論最適化を適用し、GPT-5.6 Solの実効利用量を約10%増やした
Codex内のコンテキスト設定を372,000から272,000トークンへ一時的に戻した
reasoning effortの内部値を変える実験を巻き戻した
highとxhighでマルチエージェントが意図よりわずかに多くusageを使う問題を修正対象にした

372,000から272,000への変更は、モデル自体の最大コンテキストを縮小した話ではない。 GPT-5.6 SolのAPIモデルは1,050,000トークンのコンテキストを持つが、 272,000入力トークンを超えるrequestは全体が入力2倍・出力1.5倍の価格になる。⁷ Codexのプロダクト設定を372,000へ広げた結果、想定より多くusageが課されたため、 OpenAIは設定を戻したと説明している。⁵

したがって、7月の体感変化には相反する要因がある。推論最適化と272,000へのロールバックは消費を減らす方向に働く。 5時間枠の撤廃、長いコンテキスト、high・xhigh、マルチエージェントは、短時間でweeklyを消費しやすくする。

SNSの4仮説は同じ確度では扱えない¶

仮説	判定	読み方
silent nerf	未確認	公式は否定しており、週間上限の変更値を示す一次情報もない
usage計算または表示の不具合	一部確認済み	6月の実消費・表示問題、7月の372,000設定による過剰消費は公式確認済み
5時間制限の仕様変更	確認済み	7月12日に一時撤廃。週間枠の総量ではなく消費ペースへ影響する
重いモデル・新機能による実質消費増	確認済み	公式rate cardはモデル、入力、cached input、出力で消費量が変わると明記する

OpenAIは2026年4月、Codexのpricingを平均message数ベースから API token usageに対応したcredit方式へ移行した。⁸ 現行rate cardでは、GPT-5.6 Solは100万トークン当たり入力125、cached input 12.5、出力750 creditsである。 TerraはそれぞれSolの半分、Lunaは5分の1に設定されている。

同じ「1回の依頼」でも、モデル、出力量、長い会話履歴、reasoning effort、 subagent数によって消費は変わる。プロンプト回数だけを揃えた比較では、枠の増減を判定できない。

7月下旬の再発報告は公式には未解決である¶

7月22日には、Pro 20xを含むユーザーからweeklyの減りが再び速いという報告が出た。⁹ これは新しい観測として扱う価値があるが、コミュニティ投稿だけではプラン全体の上限変更、特定モデルの消費増、個別アカウントの問題を区別できない。

7月24日時点のOpenAI Statusには、7月17日のGPT-5.6 Solのserver overload、 18日のCodexアクセス拒否、20日のGitHub依存workflow障害などが記録されている。¹⁰ しかし、7月22日のweekly消費報告に対応する新しいusage incidentや、 6月29日と同等の公式事後報告は確認できない。

ここが元のSNS解釈で最も注意すべき境界である。 6月に公式確認されたバグは実在したが、その修正内容を7月下旬の報告へ自動的に当てはめることはできない。 現在言えるのは、過去に複数の消費増要因が確認され、 7月にも消費ペースへ影響する変更があったところまでである。

利用者ごとの差は共有poolと自動処理で広がる¶

OpenAIの公式FAQは、Codex、ChatGPT Work、ChatGPT for Excel、 Workspace Agentsが同じagentic usageとcredit poolを使うと説明している。¹¹ タスクの消費量は、作業の複雑さ、モデル、実行場所、コードベースの大きさ、セッションの長さで変わる。

この仕組みでは、同じプランでも次の使い方で差が広がる。

長い既存threadを継続し、大量のcontextを毎回持ち回る
highまたはxhighで複数のsubagentを動かす
Codex以外の共有pool対象機能も使う
background suggestionsやauto-reviewが多く発生するworkflowを使う
長い出力や大きなツール結果を繰り返し生成する

「毎日使っても上限に届かない」というユーザーと、「1日で大きく減った」というユーザーが同時に存在しても矛盾しない。一律のmessage数ではなく、実際のtoken mixと自動処理を含む作業量で減るためである。

異常消費は同条件の1タスクで切り分ける¶

体感差を報告可能な証跡へ変えるには、週単位の記憶ではなく、 1タスクの前後を同条件で記録する。

利用者がusage dashboardまたはCodex CLIの/statusで開始時の残量を記録する
利用者がモデル、reasoning effort、threadの新旧、対象repository、subagent使用数を固定する
Codexが1つの小さなタスクだけを実行し、終了直後に残量を再記録する
利用者が同じ規模のタスクを、subagentなし・低いreasoning effort・新規threadで比較する
差が再現した場合、時刻、client version、session log、画面の記録を添えて公式Issueへ報告する

OpenAI自身が案内する節約策は、promptを絞る、AGENTS.mdを短くする、不要なMCP serverを無効化する、日常作業を小型モデルへ切り替えることだ。¹² これらは異常の隠蔽ではなく、比較条件を揃えながら通常消費を下げる手段になる。

個人向けプランで確認できる公式導線はusage dashboardと/statusである。一方、各バックグラウンド処理が何token・何creditを使ったかを PlusやProユーザーがプログラムから取得できる公開APIは、7月24日時点の公式資料では確認できない。消費内訳とreset履歴の透明性が不足している限り、同種の疑念は再発しやすい。