Codexを少し触っただけのつもりなのに、使用量や残量の減りが想像より速いときがあります。そういうときは「自分が無駄に使ったのかな」と考えがちですが、実際には experimental まわりで有効にしていた機能や、複数エージェント系の動作が原因になっていることがあります。
Codexの消費が早すぎると感じたら、まず experimental で触った設定、複数エージェント、/fast、長時間セッションを見直してください。
先に結論
experimental という単語だけで一括りにすると少し雑です。2026年3月17日に確認したOpenAI公式情報では、Codexの消費量は「作業のサイズ」「コードベースの大きさ」「長時間タスク」「長いセッションで保持するコンテキスト量」によって大きく変わると案内されています。
つまり、experimental をONにした瞬間に一律で減りやすくなる、というよりも、experimental 経由で使い始めた機能の中に、結果として消費の重いものが混ざっていないかを見るのが本筋です。
OpenAI公式が「experimental をONにすると一律で使用量が増える」と明記しているわけではありません。この記事は、experimental で有効にした機能の中に重い処理がないか確認しましょう、という整理です。
なぜ急に重く見えるのか
OpenAI Help Center では、Codexの使用量は小さなスクリプトでは軽く済む一方で、大きいコードベース、長時間タスク、長いセッションでは1メッセージあたりの消費が大きくなると説明されています。
さらに、OpenAIの Subagents ドキュメントでは、複数エージェントのワークフローは単一エージェントの実行より多くのトークンを消費すると案内されています。複数の子エージェントがそれぞれモデル呼び出しやツール実行を行うからです。
加えて、Speed ドキュメントでは Fast mode を有効にすると速度が 1.5 倍になる代わりに、クレジット消費は 2 倍になると案内されています。
つまり、次のどれかが入ると「そんなに使っていないのに減りが速い」と感じやすくなります。
- 長い会話を続けている
- 大きいリポジトリを何度も読ませている
- 複数エージェントや並列ワークフローを使っている
- Fast mode を有効にしている
experimental を疑いたい場面
特に疑いやすいのは、過去に /experimental や設定画面からいろいろ試したあとです。
たとえば、以前は「面白そうだから全部ONにした」「複数エージェントを試した」「便利そうな新機能をまとめて有効化した」という使い方をしていると、あとから何が消費増の原因だったか分かりにくくなります。
ここでポイントになるのは、experimental というラベル自体ではなく、その中身です。並列処理、追加のモデル呼び出し、長時間バックグラウンド実行につながる機能なら、当然ながら消費も軽くはなりません。
2026年3月17日時点での補足
ここは日付つきで整理しておいたほうが誤解が少ないです。
2026年3月17日に確認した OpenAI の Subagents ドキュメントでは、現在の Codex リリースでは subagent workflows は既定で有効と案内されています。つまり、現行版では「experimentalを手動でONにしたから消費が増えた」というより、「複数エージェント的な重い使い方になっていたから消費が増えた」と考えるほうが正確です。
以前の情報や古い記事では、複数エージェントを experimental 扱いで説明しているものもあります。そのため、古い記憶のまま切り分けると少しズレます。
今のCodexでは、「experimental を疑う」というより「重い機能が有効か、重いワークフローを踏んでいないか」を疑うほうが実務的です。
まず確認したいチェックリスト
- ~/.codex/config.toml を開いて、最近追加した設定を見直します。
- 複数エージェントを前提にした使い方をしていないか確認します。
- Fast mode を有効にしていないか確認します。
- 長い会話を続けず、新しいセッションで同じ依頼を試します。
- 大きな依頼を一発で投げず、小さく分割して比較します。
Windowsなら設定ファイルの代表例は次の場所です。
C:\Users\ユーザー名\.codex\config.tomlもし ~/.codex/agents/ やプロジェクト内の .codex/agents/ にカスタムエージェントを置いているなら、そちらも確認対象です。親エージェントが複数の子エージェントを呼ぶ前提になっていると、想像以上に消費が進みます。
こんな切り分けが有効です
一番分かりやすいのは、同じ相談を条件だけ変えて比べることです。
軽い条件
- 新しいセッション
- 単一エージェント
- 小さめの対象ファイル
- Fast mode なし
重い条件
- 長いセッションの続き
- 並列エージェントあり
- リポジトリ全体をまたいだ依頼
- スピード優先設定あり
これで明らかに減り方が違うなら、原因は「Codex全体がおかしい」というより、設定やワークフロー側にある可能性が高いです。
まとめ
Codexのlimitが低すぎる と感じたとき、まず「OpenAI側の不具合かな」と考えるのは自然です。ただ、実際には設定や使い方の影響がかなり大きいです。
特に、experimental 周りを触ったあとに違和感が出たなら、experimental という名前だけを見るのではなく、その中で何を有効にしたのかを分解して見直したほうが早いです。
Codexの消費が早いときは、experimental を雑に疑うのではなく、「複数エージェント」「長時間セッション」「大きいコンテキスト」「Fast mode」の4点を優先して確認するのが近道です。
