Claude Code と Codex は、同じ一つの毎日 token 枠を消費しているわけではありません。2026年6月30日時点で大事なのは、「今日あと何 token 使えるか」ではなく、いま動いているメーターがどれで、その作業をどの契約が支払っているかです。
Claude Code では、メーターはローカルの /usage、Pro / Max / Team / Enterprise の usage bar、Claude Console の API spend、workspace spend limit、またはチームが自分たちの監視基盤へ出している OpenTelemetry かもしれません。Codex では、ChatGPT プランに含まれる利用枠、購入した credits、workspace credits、Fast mode の高い credit 消費、画像生成、または OpenAI Platform の API key billing かもしれません。
そのため、最初に「アップグレードすべきか」と考えるのは危険です。まず、使っているツール面、プラン面、モデル、コンテキスト量、課金ルートを特定します。そのうえで、コンテキストを消す、compact する、モデルを変える、effort を下げる、不要な MCP を切る、spend limit を設定する、credits を買う、または API key 課金へ移す、という順番で判断します。
**証拠メモ：**OpenAI Codex の pricing、speed、auth、slash command、analytics、image generation 文書は 2026年6月30日に確認しました。Anthropic Claude Code の cost、usage、analytics、settings、OpenTelemetry 文書も同日に確認しています。
まずメーターを見る。アップグレードはその後
使用量の判断が外れる原因は、たいてい次の三つを混ぜてしまうことです。
- agent が実際に読んでいるコンテキスト量
- 製品画面が表示している残り利用量
- どの請求書、またはどの credit プールが減っているか
この三つを分けてから予算を動かします。
| 作業面 | 最初に見るメーター | 深い所有者 | 最初の制御 |
|---|---|---|---|
| Claude Code のローカル購読セッション | /usage、status line、拡張の Account & usage | プラン上限とローカル履歴 | 古い履歴を消す、compact、effort を下げる、モデルを替える、不要な MCP を切る |
| Claude Code の API / Console 経路 | Claude Console usage と workspace spend limit | API billing と workspace rate limit | 上限を設定し、ユーザー別 spend を見て、OTel を出す |
| チームの Claude Code | Claude analytics、OTel、gateway、SIEM | Team / Enterprise の管理ポリシー | ユーザー、モデル、tool、skill、plugin、MCP、agent で帰属させる |
| ChatGPT ログインの Codex | Codex usage dashboard と CLI /status または /usage | 含まれるプラン枠と任意 credits | ルーチンは小さいモデル、コンテキスト削減、Fast mode は価値がある時だけ |
| API key の Codex | OpenAI Platform billing、limits、API pricing | 従量 API 契約 | プロジェクト予算を置き、CI と対話作業を分離する |
メーターを間違えると、次の動きも間違います。高いプランは、大きすぎる CLAUDE.md、騒がしい MCP、放置された subagent team、Codex Fast mode の常用、または誤った予算に向いた API key を直してくれません。
Claude Code：プランを疑う前に /usage を読む
Claude Code の cost 文書では、/usage が最初のローカル診断面になります。Session block は現在の session の token 統計を表示します。API 利用者にとっては token spend の見積もりに役立ちます。Pro、Max、Team、Enterprise の購読者にとっては、ローカルのドル表示は正式な請求ではありません。購読者は plan usage bars、activity stats、どの要素がプラン制限に入るかの内訳も見ます。
安全な読み方はこうです。
/usageは現在のローカル session を理解するために使う- plan bars は購読枠の圧力を理解するために使う
- Claude Console は API billing の正式な確認面として使う
- analytics や OpenTelemetry はチーム帰属に使う
同じ画面では、最近の使用量を skills、subagents、plugins、個別の MCP servers に分けて見られます。日単位、週単位の切り替えもあり、VS Code 拡張にも Account & usage ダイアログがあります。つまり /usage は飾りではなく、最初の分岐表です。
| 症状 | よくある原因 | 制御 |
|---|---|---|
| 短い prompt なのに消費が大きい | 隠れたコンテキスト、古い履歴、tools、MCP 定義 | /context を確認し、履歴を消し、狭い指示で compact |
| 計画段階で枠が早く減る | extended thinking、高い effort、広すぎる探索 | /effort を下げ、対象ファイルを指定し、stop condition を書く |
| チーム spend が分からない | ローカル表示だけでは帰属できない | OTel または analytics を有効にし、ユーザー、モデル、tool、agent で集計 |
| API 請求が予想外 | workspace spend limit がない、または広すぎる | workspace spend limit と必要な per-user rate limit を設定 |
Codex：プラン枠、credits、API key を分ける
Codex の会計は別の形です。OpenAI の Codex pricing ページは、一つの daily token cap ではなく、included plan usage、credits、workspace credits、API key billing を分けています。
2026年6月30日時点で、公開表に見える local messages / 5h の範囲は次の通りです。
| Codex 経路 | Local messages / 5h | 注意点 | 制御の意味 |
|---|---|---|---|
| Plus | GPT-5.5: 15-80、GPT-5.4: 20-100、GPT-5.4 mini: 60-350 | モデル、タスクサイズ、複雑さ、ローカルコンテキストで変わる | ルーチン編集は mini、大きな repo context を毎回入れない |
| Pro 5x | GPT-5.5: 75-400、GPT-5.4: 100-500、GPT-5.4 mini: 300-1750 | 大きい枠だが無制限ではない | 重いモデルは高リスクのコード経路に残す |
| Pro 20x | GPT-5.5: 300-1600、GPT-5.4: 400-2000、GPT-5.4 mini: 1200-7000 | 最も大きい included tier でも context-sensitive | 長い task と background work を別に監視する |
| Business included usage | GPT-5.5: 15-80、GPT-5.4: 20-100、GPT-5.4 mini: 60-350 | workspace contract と flexible pricing で変わる | 管理者は公開行だけでなく workspace credits を見る |
| API key | 従量課金 | OpenAI Platform API pricing が適用される | ChatGPT 枠ではなく API spend と rate limit の管理 |
OpenAI はモデルや機能ごとの credit rate も示しています。GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-Image-2 の image path、GPT-Image-2 の text path は、input、cached input、output の rate が違います。長い coding run と短い診断 prompt は同じ credits ではありません。
Fast mode も別の倍率です。OpenAI の speed 文書では、対応する ChatGPT login session の速度を上げる一方、credits を高い rate で消費すると説明されています。GPT-5.5 は標準の 2.5x、GPT-5.4 は 2x です。API key session は標準 API pricing を使い、ChatGPT Fast mode credits は使いません。
画像生成も純粋な text-only turn ではありません。Codex の文書では、built-in image generation は一般の Codex usage limits に入り、text-only より早く included limits を消費し得ます。図解、UI mock、記事画像を作る session は、普通のコード編集とは別に考えます。
二つのツールに共通する制御ループ
メーターは違っても、運用ループはほぼ同じです。
- 作業名を決める。 exploration、edit、review、CI、image generation、automation のどれか。
- 支払い元を決める。 subscription plan、usage credits、workspace credits、API key のどれか。
- コンテキストを決める。 files、instructions、MCP、logs、tools、screenshots、history のどれが入るか。
- モデルと effort を決める。 高価な model と高 effort は高い不確実性に使う。
- 前後で測る。
/usage、/status、dashboards、OTel、Console spend、Platform billing を見る。 - 一つずつ変える。 clear、compact、model switch、server disable、task split の後に再測定する。
一度に五つ変えると原因が分かりません。一つずつ変えれば、チームは再現できる budget playbook を作れます。
混ぜてはいけない billing 境界
最も高くつく誤解は、すべての credits を一つの財布として扱うことです。
Claude Code の API usage は Anthropic Console で追跡され、workspace spend limits で管理できます。Pro と Max には subscription usage bars と usage credits が表示される場合があります。チームでは analytics、OpenTelemetry、gateway attribution、SIEM がさらに加わります。
Codex credits は、included limits 後の対応する使用や flexible workspace contract のための OpenAI 側の継続単位です。OpenAI Platform API key billing は別の従量ルートです。Codex の API key workflow は ChatGPT included credits を消費しません。
止めるべき境界は次です。
- Console billing が示さない限り、Claude Code subscription usage を API bill と呼ばない。
- Codex API key usage を ChatGPT plan limit と呼ばない。
- Fast mode を無料の速度として扱わない。
- image generation を text-only coding turn と同一視しない。
- 一時的な quota-drain や dashboard 異常を長期 baseline にしない。
チーム制御：dashboard、telemetry、spend limit
チーム運用では、ローカル command だけでは足りません。
Claude Code は Team と Enterprise 向けの analytics dashboard を持ち、API customer は Console dashboard で usage と spend を見られます。ユーザー別 token counts と cost estimates には OpenTelemetry export が推奨されています。OTel は token usage、cost usage、session count、tool activity、model、skill、plugin、MCP、agent 属性を出せます。
これにより、「誰かが使いすぎた」ではなく、「この workflow は毎回同じ MCP、plugin、subagent を読み込むため context が膨らむ」と言えます。後者なら直せます。
Codex にも admin と analytics の surface があります。OpenAI の enterprise governance 文書では、workspace admins と analytics viewers が adoption、usage、product surface と model ごとの credit / token usage を追跡できると説明されています。ただし data lag があり得るため、spike 調査では dashboard、local log、billing surface が揃うまで結論を急がない方が安全です。
実務のポリシーは次のようになります。
- interactive development、CI、review、experiments の予算を分ける
- 関係ない仕事には新しい session を使う
- 共有 instruction は短く保ち、専門知識は on-demand skill に移す
- 高価な model は価値がある task に限定する
- チーム展開前に usage metrics を export する
- credits 購入前に stop-and-inspect threshold を置く
利用枠が速く減るときの順番
最初に upgrade しないでください。順番は次です。
| 手順 | Claude Code | Codex | 理由 |
|---|---|---|---|
| 1 | /usage、plan bars、Console を見る | dashboard と /status または /usage を見る | 動いたメーターを確認する |
| 2 | /context、clear、compact | compact、新しい task、context 削減 | context が最も安い修正点になりやすい |
| 3 | model または effort を下げる | GPT-5.5 から GPT-5.4 / mini へ | model mix は burn rate をすぐ変える |
| 4 | 不要な MCP / plugin / agent を切る | 不要な MCP、tools、review loops を切る | tool overhead は小さい task を膨らませる |
| 5 | telemetry を見る | admin analytics と Platform billing を見る | 個人 session と team spend を分ける |
| 6 | 最後に契約を変える | credits、workspace limit、API billing | 契約変更は診断の後 |
異常日にはもう一つルールを追加します。多くのユーザーが同時に急な drain を報告する場合、まず accounting、dashboard、background work、retry の問題として扱います。スクリーンショット、model、context、task type を保存し、公式 surface が安定してから比較します。
予算チェックリスト
- 実行前： goal、files、stop condition、verification command を書く。
- 開始時：
/usageまたは/status、model、effort、Fast mode、API key route を確認。 - 探索中： 全 repo scan ではなく、対象ファイルを読む。
- 長い log の前： test output を filter するか、noise を isolated subagent に渡す。
- Opus、GPT-5.5、Fast mode の前： その不確実性が burn rate に値するか確認。
- 画像生成の前： text-only coding turn より高くつく前提で扱う。
- 終了後： before/after usage と実際の成果を書き、model 名だけで終わらせない。
よくある質問
Claude Code は Codex より安いですか？
一律ではありません。契約、model、context、billing route が違います。具体的な task、model、context size、payer で比較します。
Claude Code の token usage はどこで見ますか？
まず /usage です。API billing は Claude Console、チーム帰属は analytics または OpenTelemetry を使います。
Codex credits はどこで見ますか？
Codex usage dashboard と CLI /status または /usage を見ます。API key workflow は OpenAI Platform billing と limits を見ます。
Codex には一つの daily token limit がありますか？
ありません。plan windows、model-specific ranges、credits、workspace contracts、Fast mode、image generation、API key billing を分けて理解します。
すぐに使用量を減らす方法は？
関係ない仕事は新しい session にし、履歴を compact し、routine task は model / effort を下げ、不要な MCP を切り、対象ファイルと stop condition を明確にします。
急に減るなら credits を買うべきですか？
診断後です。巨大な context、Fast mode、image generation、tool loop、一時的な provider-side incident が原因かもしれません。
**結論：**Claude Code と Codex の使用量制御は、メーターのルーティングです。メーターを特定し、context を縮め、model を選び、契約変更は workflow が本当に必要としたときに行います。