Codexクレジットの計算と購入：週次上限との関係

Codexに、全ユーザー共通の「1日○回」という上限はありません。止まったら、まず Codex Usage dashboard を開き、CLIを使っているなら現在のセッションで /status を実行してください。この2つで、アカウント側の残量・reset・購入可否と、いまのセッションのモデル・設定・コンテキストを分けて確認できます。

課金の順序は、プランに含まれる利用枠 → 対象上限後の利用可能な追加クレジット → 別契約のAPI keyです。credits購入は週次メーターをゼロに戻さず、reset日も変更しません。

次に、表示された症状を 5時間枠、追加の週次制限、購入済みクレジット、APIレート制限、API支出、ローカルのコンテキスト上限 のどれかへ振り分けます。カウンターが違えば、待つべきか、作業を小さくすべきか、クレジットを使うべきかも変わります。プラン変更は診断の後です。

まず60秒で「どの上限か」を判定する

ここで重要なのは、残り利用枠、累積token活動、コンテキスト占有率は別の数字だということです。/status は現在のCLIセッションとrate-limit表示を見るのに向きます。/usage が使える環境ではアカウントのtoken活動や対象reset操作を確認できますが、/status と完全な同義ではありません。API keyを使った実行は、ChatGPTのUsageではなくPlatform側で確認します。

より細かな切り分けが必要なら、Codexのtokenとコンテキストの読み方 と CodexのAPI keyと購読の違い を別ページで確認できます。

5時間は「5時間働ける」という約束ではない

OpenAIのCodex pricing文書 は、対象プランの local messages と cloud chats を「5時間ごとの範囲」として示し、両方が同じ5時間枠を共有すると説明しています。ローカルで編集した後にcloud taskを動かせば、別々の無料枠が二つあるとは限りません。さらに追加の週次制限が適用される場合があります。

5時間という数字はreset windowです。5時間ずっと作業できる保証ではありません。消費量は、モデル、taskの大きさと複雑さ、localかcloudか、読み込むファイルと履歴、reasoning、tool利用、retrieval、cacheの効き方で変わります。短いpromptでも大きなrepositoryと長い履歴を毎回読ませれば重くなり、長い依頼でも対象が限定されcacheが効けば相対的に軽いことがあります。

2026年7月の一時変更について

2026年7月には、対象プランの5時間制限が一時的に外れ、保存して後で使えるresetが付与されたという案内・報道がありました。しかし、これは恒久的なプラン契約ではありません。banked resetは、アカウント、時期、付与条件、使用済みかどうかによって見え方が変わります。

したがって、古いスクリーンショットに5時間meterがあるのに自分の画面にはない、またはその逆でも、それだけで不具合や恒久廃止とは判断できません。サインイン済みUsage dashboardに現在表示される状態を優先してください。

メッセージ範囲からcreditsを逆算しない

プラン表の local messages / 5h は含まれる利用枠の目安で、rate cardはinput、cached input、output tokensをcreditへ換算します。「1 message＝一定credits」ではありません。既知の1ファイルを直すtaskと、monorepoを探索してtoolsを呼び長い結果を返すtaskでは、同じ1依頼でも負荷が違います。

続行可否はUsage dashboard、credits計算は現在のrate cardで確認します。モデル名や範囲は変わるため、この記事では表全体を固定しません。

Proだけを詳しく確認したい場合は ChatGPT ProのCodex quota確認 を使ってください。

credits、API rate、API spendは同じ財布ではない

Codexの利用制限で最も高くつく誤解は、「credits」「API token」「ChatGPTの残量」を一つにまとめることです。

購入クレジット

OpenAIのCodex rate card では、現在の多くの対象プランがinput、cached input、output tokenをcreditへ換算します。含まれる利用枠に達した後、Plus/Proで購入クレジットを使える場合や、flexible pricingのworkspaceで管理者がworkspace creditsを用意する場合があります。

購入ボタンやauto-rechargeが見えるかは、プランとworkspace roleに依存します。表示されない場合に非公式な販売者や共有アカウントを探すのではなく、workspace owner/adminへ確認するか、resetを待ちます。

token-based rate cardでは、input / 100万 × input単価 + cached input / 100万 × cached input単価 + output / 100万 × output単価で読みます。2026年8月4日のGPT-5.4 miniは、input 18.75、cached input 1.875、output 113 credits / 100万tokensです。100,000 input、400,000 cached input、20,000 outputなら、1.875 + 0.75 + 2.26 = 4.885 credits、約4.89です。これは読み方の例で、実際の控除はlive rateとUsage表示に従います。

対象のPlus/Proは、webまたはCodex appの Codex Settings > Usage > Credits から購入できます。対象アカウントではauto top-upも設定でき、残高が最低値を下回ると既定の支払い方法で目標残高まで補充します。設定時点ですでに閾値未満なら、すぐ購入される場合があります。

購入creditsは購入日から12か月有効で、期限後は繰り越されません。原則返金不可・譲渡不可です。creditsが他の対応agentic featureと共有される場合もあるため、購入前にUsageの消費先と支払者を確認してください。

APIレート制限

API keyでCodexを動かす場合、RPMやTPMなどはPlatformの組織・プロジェクト側の制限です。ChatGPT workspaceのメンバーであることは、API組織への所属、API key、model access、usage、billingを自動では付与しません。詳細な429診断は OpenAI APIのrate limitガイド に分離します。

API支出

API spendは、標準API料金で請求される別契約です。ChatGPTプランの5時間枠が減ったからAPI残高も同じ割合で減る、という関係ではありません。逆に、API keyへ切り替えてもsubscription枠が回復するわけではありません。payerがChatGPT側からPlatform側へ変わるだけです。

API key routeはCLI、SDK、IDEで使えますが、Codex cloud機能のすべてを含むわけではありません。たとえばGitHub reviewやSlackなど、cloud側の機能境界を保ったまま「APIなら全部同じ」と説明しないことが重要です。

active turnとGitHub reviewの例外を知る

含まれる上限へ到達しても、OpenAIはactive turnがfair-useの範囲で完了する場合があると説明しています。これは「制限後も無制限に新しい依頼を開始できる」という意味ではありません。実行中のturnが終わった後に、Usageまたはlimit bannerが提示する次の選択肢を確認してください。

Code reviewも実行場所でmeterが変わります。

• GitHubからtriggerされた自動Codex reviewはCode Review meterを使います。
• ローカルで「この差分をreviewして」と依頼した作業や、GitHub外のreviewはgeneral usageに数えられます。
• 「reviewだから常に別枠」とは判断せず、どこから起動したかを記録します。

なぜ急に減ったのか：単変数で観察する

「昨日より速く減った」と感じたとき、モデル、context、MCP、task範囲を同時に全部変えると原因を特定できません。次の短い観察を1回行います。

1. Usage dashboardで開始時の残量とreset表示を記録する。
2. /status でモデル、context状態、local/cloudを記録する。
3. たとえば「認証モジュール全体を直す」ではなく、「この1ファイルの失敗するtest原因だけを説明する」という境界付きtaskを実行する。
4. 終了後にUsageと/statusを再確認し、tool、retrieval、長いlog、Fast modeの有無も記録する。
5. 次の試行では、モデルだけ、contextだけ、またはtask範囲だけを変える。

これは万能なbenchmarkではありません。アカウント間の厳密比較にも使えません。それでも、自分のworkflowで何が将来の消費を変えるかを見つけるには、感覚的な「1 promptあたり」の計算より再現しやすい方法です。

日本語の実務例

大きなmonorepoで障害調査をするとき、最初から「全部調べて修正して」と依頼すると、設定、履歴、tool出力を広く読む可能性があります。最初のturnを「再現command、対象package、直近のerror 30行だけで原因候補を3つに絞る」にすれば、解決を約束せずに探索範囲を減らせます。

次のturnで候補を一つだけ検証し、最後に修正とtestを依頼します。必要なcontextは残しつつ、関係ない会話は新しいtaskへ分けます。AGENTS.mdは対象directoryに必要な指示だけ置き、使わないMCP serverは無効にします。小さい定型作業には軽いモデルを選び、速度が価値を生む場面以外ではFast modeを常用しません。

上限後の安全な次の一手

次の順序なら、原因を見失いにくくなります。

1. 確認する。 Usage dashboard、limit banner、/status、必要なら/usage、Platformを正しい順で見る。
2. 待つ。 reset時刻が明確で緊急でなければ、追加支出をせず待つ。
3. 未来の消費を軽くする。 taskを分割し、contextを絞り、不要なMCP/toolを外し、適切な軽量モデルを使う。
4. 正規のcreditsを使う。 自分のUsage画面に表示され、支払者とauto-recharge上限を確認できる場合だけ使う。
5. プランを変える。 同じworkflowを単変数で観察しても継続的に枠が不足すると確認できた後に比較する。
6. API keyへ意図的に切り替える。 Platform側のproject、billing、rate limit、cloud機能の不足を理解した場合に限る。

避けるべきなのは、共有アカウント、credentialの売買、非公式reset script、複数アカウントでの制限回避です。利用規約とセキュリティの問題を増やし、どのmeterが動いたかも追えなくなります。共有PC・アカウントの境界は Codexを同じPCで使う場合の制限 を参照してください。

迷ったときの結論

Codexの利用制限は、単一のtoken残量ではなく複数のカウンターです。まずUsage dashboardでアカウント側、/statusで現在のセッション、PlatformでAPI側を確認します。5時間枠とlocal/cloud共有、追加の週次枠、credits、API rate、API spend、contextを分ければ、待つべき場面で課金したり、API 429をプラン変更で直そうとしたりする誤りを避けられます。

この記事のrate例は2026年8月4日に確認しました。最後の判断は、必ず自分のサインイン済みUsage dashboardと OpenAIのlive pricing表 で行ってください。