Codexの利用枠を短時間で20ポイント消費したら止める―AGENTS.mdとApp Serverを実際に試す

Codexの長時間処理で利用枠を急速に消費したときに止めたい。AGENTS.mdへCost guardを書き、最初の試行では残量を取得できず、Codex App Serverのaccount/rateLimits/readで5時間枠と週次枠を読めるところまで確認した。Ralph loopとの組み合わせも記録する。

公開:
Codexの利用枠を短時間で20ポイント消費したら止める―AGENTS.mdとApp Serverを実際に試す

Codexへ長い修正を任せていると、「このままRalph loopのように実装と検証を回したら、利用枠を一気に使わないか」が気になります。自分の環境では、短時間に利用枠を20ポイント以上使ったら止めるルールをAGENTS.mdへ入れて、実際に動かせるか試しました。

最初はうまくいきませんでした。停止条件を書くだけなら簡単ですが、Codex自身が現在の5時間枠・週次枠を読めなければ、20ポイント減ったことを判定できません。そこからCodex App Serverのaccount/rateLimits/readまで調べ、既存のChatGPT認証のまま利用率を取得できるところまで確認しています。

前日に公開した「Codex CLIの認証をChatGPTに固定する―forced_login_methodでAPI認証経路を制限する」の続きにあたる内容です。認証経路を固定したあと、長時間処理の消費量をどう監視するかを扱います。

前の記事から、利用枠の急減も止めたくなった#

前の記事では、Codex CLIの認証をChatGPTへ固定するforced_login_method = "chatgpt"と、AGENTS.mdへ停止ルールを書く方法を確認した。

当時のCost guardはかなり単純だった。

## Cost guard

- If the current ChatGPT/Codex allowance is exhausted, stop and report it.
- Keep Codex authentication on ChatGPT.
- Do not choose API authentication as a fallback for Codex tasks.
- Before expanding a task into a large repository-wide change or repeated fix/build loop, stop and report the current state.

このルールで「上限へ到達したら止める」「API認証へ切り替えない」は指示できる。

ただ、長時間の自律作業を考えると、上限へ到達する前にも止めたい。

そこで今回追加したのが、短時間に20ポイント以上利用枠を消費したら停止するという条件。

最初に考えたルールは次の形だ。

## Cost guard

- Keep Codex authentication on ChatGPT.
- Never switch to API authentication as a fallback for Codex tasks.
- At the start of a task, record the remaining Codex allowance whenever usage information is available.
- If either the 5-hour or weekly remaining allowance drops by 20 percentage points or more within 30 minutes, stop immediately.
- Do not continue with additional fixes, builds, retries, tests, or repository-wide changes after the 20-point threshold is reached.
- Before expanding a task into a large repository-wide change, mass edit, repeated fix/build loop, or repeated test/retry loop, stop and report the current state and current allowance first.

ここでは「20%」を相対的な20%減少として扱わず、**20 percentage points(20ポイント)**としている。

開始時80%残りなら、30分以内に60%以下まで減った時点が停止ラインになる。

AGENTS.mdへ書いた最初の試行では、残量を取得できなかった#

AGENTS.mdへルールを追加し、Codexへ確認させた。

最初の結果はこうなった。

指定内容を AGENTS.md に追加しました。残り利用量を確認できる機能はこの環境で見つからなかったため、数値は確認できていません。今回はファイル追加だけ行いました。

ここは少し引っかかった。

停止条件は書けている。ただ、20ポイント減を判定するための開始時の数値が取れていない。

続けて「これ実質動作するようにするにはどうすりゃいいの」と確認すると、問題がはっきりした。

AGENTS.mdはCodexが作業前に読む指示ファイルで、公式ドキュメントでもプロジェクト固有の指示をCodexへ渡す仕組みとして説明されている。Codexはセッション開始時にAGENTS.mdを読み、グローバル設定とリポジトリ内の指示を順番に取り込む。

つまり、AGENTS.mdには「20ポイント減ったら止まる」と書ける。一方、現在の利用率そのものを返すデータ源は別に必要になる。

この段階では、Cost guardは次の状態だった。

AGENTS.md
  ↓
「20ポイント減ったら停止」と指示
  ↓
現在値を取得できない
  ↓
差分を計算できない

長時間タスクへ広げる前に止めるルールは機能するが、利用率を見ながら20ポイントで判定するところまでは進められていない。

Codex App Serverのaccount/rateLimits/readで利用率を読めた#

次に調べたのがCodex App Server。

OpenAIの現在のApp Serverドキュメントには、ChatGPTの利用制限を取得するメソッドとしてaccount/rateLimits/readが掲載されている。

公式の説明では、返却値に次の情報が含まれる。

  • usedPercent:その制限窓で現在使っている割合
  • windowDurationMins:制限窓の長さ
  • resetsAt:次回リセット時刻
  • primary / secondary:利用枠の制限窓
  • rateLimitsByLimitId:複数の制限枠がある場合の情報

要求自体はJSON-RPCで送る。

{"method":"account/rateLimits/read","id":6}

usedPercentは「使用済み」の割合を表す。

記事内で残量として扱う場合は、単純化すると次の計算になる。

remainingPercent = 100 - usedPercent

実際に端末のCodex CLI App Serverへ、既存のChatGPT認証のまま問い合わせたところ、利用率を取得できた。APIキーは使っていない。

確認時点は2026年10月1日 01:15 UTC(日本時間10:15)。

残量として見ると、**5時間枠が97%、週次枠が71%**だった。

5時間枠:97% 残り
週次枠 :71% 残り

最初の試行では「利用量を読む機能が見つからない」と止まっていたので、ここでようやくCost guardの基準値を置けるようになった。

20ポイント停止を実運用へ近づける構成#

ここまでで役割を分けられる。

forced_login_method = "chatgpt"
  ↓
Codexの認証経路をChatGPTへ固定

AGENTS.md
  ↓
開始時に利用率を記録
  ↓
30分後・大きな反復処理の前に再確認
  ↓
20ポイント以上減っていれば停止

Codex App Server
  ↓
account/rateLimits/read
  ↓
usedPercent / resetsAt を取得

前の記事で設定したforced_login_method、今回のAGENTS.md、App Serverは役割が違う。

横にスクロールできます
役割使うもの今回の目的
認証経路を固定config.tomlCodexをChatGPT認証で使う
作業ルールを常設AGENTS.md20ポイント急減時の停止条件を指示する
現在値を取得Codex App Server利用率とリセット時刻を読む

自分の環境では、利用率を取得できることを確認したあと、長い作業では「30分後」と「大きな作業へ広げる前」に再確認する方針をAGENTS.mdへ追加した。

ただし、この段階の停止はCodex自身がルールに従ってチェックを実行する運用になる。

OS側からプロセスを強制終了するハードリミットまで必要なら、App Serverを読む外側のラッパーを用意し、しきい値到達時にCodexプロセスを停止する構成の方が強い。

今回そこまでは実装していない。

Ralph loopを回すならCost guardを一緒に置きたい#

今回この設定を入れた理由の一つが、CodexへRalph loopに近い動きをさせたかったこと。

ここでいうRalph loopは、開発タスクで次の反復を自律的に続ける運用を指している。

実装
 ↓
ビルド・テスト
 ↓
失敗原因を確認
 ↓
修正
 ↓
再検証
 ↓
未完なら繰り返す

AGENTS.mdへこの作業方針を書いておけば、毎回「続けて」「もう一度ビルドして」と入力する回数を減らせる。

例えば次のようなルールを置いている。

## Ralph loop

- For implementation and fixing tasks, do not stop after a single code change.
- Run all applicable validation, including build, tests, lint, and type checks.
- Analyze failures, fix the underlying cause, and run validation again.
- If the task is not complete, continue the cycle without waiting for another user instruction.
- Before expanding the task into a large repository-wide change, mass edit, or repeated fix/build loop, apply the Cost guard rules.

Ralph loopとCost guardは相性がよい。

自律的な反復は、人間が細かく「続けて」と指示しなくても進む。その分、修正→ビルド→再修正を短時間に何度も回す可能性がある。

今回の20ポイントルールは、その反復が想定以上に利用枠を使っているときの停止条件として置いた。

なお、ここで使っているRalph loopは1回のCodexセッション内で実装・検証・修正を反復させる運用を中心にしている。外部スクリプトがCodexプロセス自体を終了後に再起動し続ける構成まで含める場合は、別途オーケストレーションが必要になる。

今回確認できた範囲と注意点#

今回の実作業で確認できた範囲はここまで。

  • AGENTS.mdへ20ポイント急減時の停止ルールを書ける
  • AGENTS.mdの記述だけでは、最初の試行で利用枠の数値を取得できなかった
  • Codex App Serverにaccount/rateLimits/readがある
  • 既存のChatGPT認証を使った状態で利用率を取得できた
  • 確認時点では5時間枠97%残り、週次枠71%残りだった
  • 長い作業では30分後と、大規模・反復作業へ広げる前に再確認する運用へ変更した
  • APIキーへ切り替えて確認する必要はなかった

一方、OSレベルの強制停止までは今回の作業に含めていない。

AGENTS.mdは作業方針をCodexへ渡す場所。account/rateLimits/readは現在値を取得する場所。この2つをつなげたことで、最初に書いたCost guardを実際の利用率に基づいて判断できる状態へ一段進められた。

前日の認証経路の記事と合わせると、現在の構成はこうなる。

config.toml
  └─ forced_login_method = "chatgpt"

AGENTS.md
  ├─ Ralph loop
  └─ Cost guard
       └─ 30分以内に20ポイント減 → 停止

Codex App Server
  └─ account/rateLimits/read
       └─ 利用率を取得

長時間のCodex作業を自律化するなら、実装を繰り返す指示と、止める条件の両方を持たせておく方が扱いやすい。

参考#