複数の AI コーディング契約の上限をどう管理するか
Cursor、Claude、Codex、Copilot と API クレジットを同時に払うとき、主ツールと予備を分け、間違った枠を使い切らないための実務メモ。
先月、同じマシンで 3 つ の有料 AI コーディング面を同時に使っていました。IDE プラン、ターミナル agent の契約、コーディング agent 枠付きのチャット製品です。上限の単位はバラバラ。UTC 0 時リセット、ローリング週次、高速／低速プールの混在——リファクタの diff 途中で止まって初めて気づく、というパターンでした。
学んだのは地味で高い話です。契約が重なってもバックアップにはならない。役割を決めない限り、請求メーターが 3 本 走ります。
ここではベンダーが永続的に比較可能なクォータを公開しているふりはしません。上限は変わります。数字は 契約ではなく信号 として扱ってください。ツール選びは AI コーディングツールの選び方 と Cursor vs Claude Code vs Codex から。
実際に消費しているもの
表やメニューバーアプリの前に、「AI でコードするとき 何が減るか」を書き出します。
| メーター種別 | だいたいの意味 | 痛い場面 |
|---|---|---|
| メッセージ／リクエスト | チャット 1 ターン、agent 1 ステップ、インライン補完 | 1 チケットで agent ループが長い |
| プレミアムモデル | 高速／フラッグシップ vs フォールバック | 高速プール空で大規模 refactor |
| 時間ウィンドウ | 日次、週次、数時間ローリング | 週末前の追い込み |
| 同時実行／シート | チームプラン、組織プール | 1 Pro ログインを 2 人で共有 |
| API 残高（$） | コンシューマ契約外の従量 | agent 経路に API キーが混ざる |
コンシューマ契約と API は 別商品 です。両方払うのはあり得ます。同じ作業で両方燃やすと請求が跳ねます。
役割：メイン、オーバーフロー、API
流行ではなく、どの枠を燃やしてよいか で決めます。
メイン → 日常の repo 作業（review、小さな diff）
オーバーフロー → メインが絞られたとき、または向き不向きで切替
API → バッチ、スクリプト、CI 寄りの試行（$ 上限を先に決める）
メインは AI コーディング workflow チェックリスト の実態に合わせます。エディタ中心なら IDE プラン、シェルから ship ならターミナル agent。
オーバーフローは「UI が 2 つ好き」ではありません。メインのメーターが低い、または別ツールの方がタスクに合うときの 意図的な逃がし です。
API は月初に ドル上限 を書きます。黙って API キーに切り替わる agent が主な漏れ口です。
1 週間のフィールドセット（式はいらない）
- 2 週間メインを 1 つ——毎チケット全部試さない。
- 壁に当たったら 3 列：日付、ツール、症状（低速プール、ハードストップ、アップグレード誘導）。
- UI のリセットタイムゾーンをメモ。
- 個人枠なら 仕事用と個人用アカウントを分ける。
7 日で型が見えます。IDE で 80% は足りるが マルチファイル agent だけターミナル側——逆もあります。
正直な境界： 第三者の数字は、ベンダーダッシュボードと一度突合できない限り信じません。ティア名変更、「無制限」表示と IC の理解はズレがちです。
ダッシュボード、CLI、メニューバー
入口はバラバラです。
- プロダクト内の使用量——多くはここが正。Settings／Billing に埋もれがち。
- CLI セッション——ターミナル agent は shell で状態が見えることも。長いループの前に確認。
- デスクトップ集約——契約が 3 本以上なら、下の CodexBar を参照。
DevCove の拡張ディレクトリは agent 拡張（skill、plugin、MCP）用です。メニューバー utility ではありません。
CodexBar：複数プロバイダを 1 つのメニューバーに
CodexBar（MIT、codexbar.app）は Peter Steinberger（steipete）の macOS 14+ メニューバーアプリで、macOS／Linux 向け codexbar CLI も optional です。agent ではなく、AI コーディング各社の上限（ソースが出せる範囲のセッション／週／月ウィンドウ）と 次回リセットまでのカウントダウン を常に見える化します。
本文の複数契約と噛み合います。Cursor、Claude Code、Codex、Copilot、Gemini CLI、Grok、Zed、Windsurf、OpenRouter など、用量 UI は社ごとに違います。CodexBar は公式ダッシュボードの 代替ではなく集約——プロバイダごとのメニュー項目（または Merge Icons＋切替）で、refactor の前に billing タブを行ったり来たりしなくて済みます。
バーに出るもの
- プロバイダ別の用量メーター（アイコン上。エラーや stale で暗くなることあり）。
- ウィンドウごとのリセット countdown——UTC 0 時リセットと 5 時間ローリングが混在するときに効く。
- API 系の spend／クレジット（OpenAI Admin API、Claude Admin API、OpenRouter、LiteLLM、AWS Bedrock 等。provider ドキュメント 参照）。
- ステータス polling と incident バッジ——「上限切れ」が auth cookie 切れのことも。
- Settings → Usage & Spend の 7/30 日ローカル見積、脚本では
codexbar cost。
Widget や通知、週次 confetti は任意。IC にとっての核は 一目で余裕。
上限の取得方法（プライバシーと権限）
privacy-first：パスワードは保存しない。プロバイダごとに既存の OAuth、device flow、API キー、CLI（Codex、Claude、Gemini 等）、opt-in ブラウザ Cookie（Cursor プラン用量など）を再利用。既知の config／ログのみ。フルディスク crawl ではない。Safari 系では Keychain や Full Disk Access のプロンプトがあり得ます——README の privacy note と issue #12。
便利さと、第三者アプリへのセッション素材アクセスのトレードオフです。CLI のみ有効なら Cookie 経路の多くを避けられます。
インストールと CLI（スナップショット 2026-07-29）
| 形態 | 入手 |
|---|---|
| macOS アプリ | GitHub Releases または brew install --cask codexbar |
| CLI のみ | brew install steipete/tap/codexbar（Linux 可）、Arch は AUR codexbar-cli |
| 初回 | Settings → Providers で有効化し、各社サポート経路でログイン |
CLI 例（上流ドキュメント）：
codexbar config providers
codexbar config enable --provider cursor
codexbar config disable --provider grok
Windows は公式 macOS 版なし。Win-CodexBar がコミュニティ版。Linux デスクトップは bundled CLI で Waybar／GNOME／Plasma 連携——README の “Linux desktop integration”。
複数契約ワークフローでの使い方
- 長い agent の前——メーターとリセット時刻。ウィンドウ残り 20 分なら scope を絞るか 意図的に オーバーフローへ。
- 週 1——1 社選び CodexBar と billing 画面を突合。tier 名が変わっていれば memo 更新。
- バーから自動ルーティングしない——CodexBar は情報。メイン／オーバーフロー／API が仕事の行き先を決める。
数字は遅れたり、dashboard 変更で壊れたりします。CodexBar も上の表と同様 信号 であり、請求の正本ではありません。
DevCove の plugin／Skills ディレクトリに載せない理由
CodexBar は Cursor／Claude Code／Codex に skill・plugin・MCP として入るものではありません。デスクトップ companion です。複数契約の「見える化」が本題だからここで紹介し、agent のコンテキスト拡張ではないから拡張ディレクトリには載せません。
タスクのルーティング
| タスクの形 | 燃やす先 | 理由 |
|---|---|---|
| 1 ファイルの inline 修正 | メイン IDE／Copilot 系 | ターンが軽い |
| テスト＋shell の agent ループ | ターミナル agent メイン | 権限が合う |
| スタックトレース説明だけ | 非プレミアム に余裕がある方 | 高速プールは編集用 |
| 大 refactor・多ファイル | メイン→絞られたらオーバーフロー、prompt を小さく | ループでメーターが乗算 |
| リリース checklist＋diff | 人＋チェックリスト | モデルは ship ゲート の代わりにならない |
agent 途中で上限なら、ツールを替える前に スコープを狭める。半成品 patch を第 2 製品に全部貼ると 二重課金 になりがちです。
追加・解約・統合の目安
追加：メイン throttling が週 1 超で merge 可能時間を落とし、かつオーバーフロー役が定義済み。
解約：2 ツールが同じ メイン役 で、2 つ目が FOMO。または API と consumer が重複して consumer を使い切らない。
統合：チームが 1 本の agent 経路に review／権限を揃えた——Cursor vs Claude Code vs Codex 参照。
「契約は 1 つだけ」とは言いません。意図して 2 つ持つ IC も多い。両方メイン なら二重請求・二重の壁です。
まだ見る失敗パターン
- PR 途中のハードストップ——長 run の前に commit／stash。
- タスクと tier の不一致—— typo に flagship、センシティブ refactor を低速プール。
- ログイン共有——同僚がプールを使い切った。
- agent 内 API キー——残高メールまで気づかない。
上限がアーキを支配し始めたら、ブランド変更より ルーティングと workflow を直してください。
スナップショット
社内 memo には確認日、請求書どおりのプラン名、公式 pricing／usage へのリンクを。
AI Coding ツール一覧 も dated 方針です。あなたの プラン表記の方が速く変わります。
要約： 複数契約は複数クラウドアカウントと同じ——ラベルは似てメーターは別。メイン・オーバーフロー・API 上限を決め、1 週間リアル ticket を記録してから、2 枚目の請求が容量か重複かを判断してください。