Cursor Ultraの上限対策：使用量プール、従量課金、支出上限

月額200ドルのCursor Ultraを契約していても、「上限に近づいている」という警告が出ることがあります。ここで最も避けたいのは、すべての割合を1つの共通枠だと思い込み、すぐに支出設定をNo Limitへ変えることです。まず減っているカウンターを特定し、作業を止めない価値が追加料金を上回るかを判断してから、許容できる月間上限を設定します。

結論：Ultraに1つだけの総使用量メーターはない

2026年9月27日時点で、CursorはPro、Pro Plus、Ultraに2つの独立した使用量プールがあり、それぞれ月次請求サイクルでリセットされると説明しています。Cursor ModelsとOther Modelsです。Ultraは月額200ドルと記載され、両方のプールを含みますが、選ぶモデルによって含有使用量の減り方は変わります。

• Cursor Models：現在はGrok 4.7、Grok 4.6、Grok 4.5、Composer 2.5が対象です。Cursorは、このプールにより多くの含有使用量があると説明しています。
• Other Models：明示的に選択したサードパーティーモデル用です。各モデルのAPI価格に応じて使用量が計算されます。

したがって、「Ultraを80%使った」という情報だけでは原因を特定できません。Cursor Modelsが減っているのか、Other Modelsが減っているのか、あるいは特定機能の週間枠が警告を出しているのかを分けて確認する必要があります。

たとえば、Xに投稿されたユーザーのスクリーンショットには、Cursor Modelsの月間使用量72%と、Grok Botの週間枠90%が同時に表示されていました。これは別のカウンターです。Grok Botの週間警告だけで、Ultraの月間モデルプールが枯渇したとは判断できません。

プランや課金設定を変える前に、動いているカウンターを特定する

残りトークンを推測するより、警告が出た場所、選択中のモデル、請求項目を照合する方が確実です。

表示されているもの	通常の意味	次に行うこと
Cursor Modelsの割合が増えている	GrokやComposerがCursor Modelsプールを消費している	Other Modelsの残量を確認し、モデル変更がタスクに合うか判断する
Other Modelsの割合が増えている	サードパーティーモデルがAPI価格に応じて消費している	高価格モデル、長いコンテキスト、頻繁なAgent実行を確認する
Grok Botの週間警告	Bot機能固有の週間枠がリセットに近い	週間リセットを待つか、その機能の利用を減らす。月間Ultra枠とは混同しない
Included UsageとOn-Demand Usageが別表示	含有使用量と追加の従量課金が別の請求項目として記録されている	従量課金の有効化状態と支出上限を確認する

3分でできる、結果を検証できる確認手順

1. Cursorのエディター設定またはusage dashboardを開き、Cursor ModelsとOther Modelsの割合、月次リセット日を記録します。公式説明では、両方のプールをこれらの場所で確認できます。
2. 直近の重いタスクに戻り、実際に選択していたモデルを確認します。モデルごとに消費速度が違うため、リクエスト回数だけでは費用を判断できません。
3. Billing & InvoicesでIncluded UsageとOn-Demand Usageを比較します。後者に金額があれば、サブスクリプションに含まれない追加料金が発生しています。
4. Spendingを開き、従量課金が有効か、現在の月間上限はいくらか、No Limitになっていないかを確認します。
5. 1ファイルのリファクタリングなど、範囲が明確な小さなタスクを1つ実行し、どのプールまたは請求項目が動いたかを再確認します。

警告の文言が曖昧な場合は、自分のdashboardに表示される2つのプールと請求項目を基準にしてください。スクリーンショットやチャットの回答、単独のバナーは、自分のアカウントのライブデータの代わりにはなりません。

従量課金を有効にする価値がある条件

作業中断を避ける価値が、許容できる追加費用より大きい場合にだけ、従量課金は合理的です。Cursorのusage-based chargesの説明では、個人プランは従量課金を明示的に有効にする必要があり、含有使用量を超えたリクエストはAPI価格で請求され、サブスクリプションとは別に表示されます。

次の3条件をすべて満たす場合は、有効化を検討しやすくなります。

• リリース、修正、移行など明確な締切があり、遅延の損失を見積もれる。
• 残作業が「コードレビュー2件」「特定モジュール1つ」のように限定され、終わりのないAgentループではない。
• 重いタスクごとに使用量を確認し、予算に達した時点で止められる。

一方、次の場合はまず無効のままにする方が安全です。

• どのプールが消費されているか分かっていない。
• 複数のAgent、Automation、長いコンテキストの処理を並列実行し、費用を予測しにくい。
• 個人予算に超えられない上限がある、または次の請求サイクルまで待てる。
• もう一方の含有プールに余裕があり、現在のタスクに適したモデルがある。

従量課金を有効にしても、モデル利用が「無制限」に戻るわけではありません。含有使用量を超えた後も計測課金で処理を続けることへの同意です。継続性は得られますが、費用管理は別に必要です。

推測せずに支出上限を決める方法

最も安全な上限は、プラットフォームが勧める数字ではなく、現在の請求サイクルで追加支払いを許容できる最大額です。従量課金を有効にすると、dashboardのSpendingで個人の月間上限を設定できます。Cursorの支出上限の説明では、No Limitを選ぶと上限が削除されると明記されています。

最初の上限は次の手順で決めます。

1. 残りの日数ではなく、請求サイクル中に予定している重い開発セッション数を数えます。
2. 許容できる追加費用の総額を決めます。
3. その総額を残りの重いセッション数で割り、確認用の目安を作ります。
4. Cursorには月間の総上限を設定し、各セッション後に実際の消費と目安を比較します。

たとえば、追加費用を最大40ドルに抑え、リセットまでに重いAgentセッションが10回あるなら、1回4ドルを手動確認の目安にできます。これはCursorのセッション単位上限でも料金保証でもありません。異常に高いタスクを早めに見つけるための基準です。

支出上限には2つの注意点がある

1つ目は、上限変更はすぐ反映されても、利用停止の判定は瞬時ではないことです。Cursorによれば、システムが上限到達を認識するまで、使用量が一時的に上限を超える場合があります。その限定的な超過分は一時的なspend-limit creditとして扱われ、請求は現在の上限までに制限されます。

2つ目は、同じ請求サイクル中に上限を引き上げると、以前creditになっていた一部または全部が、新しい上限まで請求対象になる可能性があることです。creditを維持したい場合は上限を変更しないか、従量課金を無効にします。

個人開発者には、No Limitより有限の上限が通常は安全です。残りのサイクルでこの制御による歯止めがない追加支出を明確に受け入れ、請求を継続監視できる場合にだけ上限を外してください。

追加料金を払うか、開発フローを変えるか

判断材料は、減っているプール、タスクの緊急性、そして消費が一時的か毎月繰り返すかです。

現在の状況	優先する行動	理由
Cursor Modelsが残り少なく、Other Modelsに余裕がある	適した難しいタスクだけをサードパーティーモデルへ移し、定型作業はCursor Modelsに残す	もう一方のプールを使えるが、サードパーティーモデルは固有のAPI価格で消費する
Other Modelsが残り少なく、Cursor Modelsに余裕がある	定型コーディング、書き換え、探索をGrokまたはComposerへ移す	残っている含有プールを使い、高価なモデルを本当に必要な作業へ残せる
両方が上限に近く、短期の締切が1つ残っている	有限の月間上限を付けて従量課金を有効にする	継続の価値が明確で、損失にも境界を作れる
毎月早い段階で両方が減り、並列AgentやAutomationを多用している	並列数を減らし、コンテキストを短くし、タスクをまとめて1サイクル観察する	繰り返すフローの問題は、1回の上限引き上げでは解決しにくい
補完、機械的修正、局所編集が中心	Tabと小さく区切ったタスクを優先する	Ultraにはunlimited Tab completionsが含まれるため、Agentを複雑な判断に残せる

同じ公式ページには大まかな目安もあります。毎日Tabを使う人は通常、含有使用量内に収まり、Agentを限定的に使う人も多くは範囲内です。Agentを毎日使う人は月間総使用量が通常60〜100ドル、複数AgentやAutomationを使うヘビーユーザーは200ドル以上になることが多いとされています。これは利用者区分の目安であり、あなたの請求予測ではありません。実際の従量課金は、モデル、トークン量、コンテキスト長、作業方法で変わります。

すでに払った200ドルではなく、タスクの価値で判断する

Ultraのサブスクリプション費用はすでに発生したコストです。それだけを理由に追加の従量課金を続けるべきではありません。重いタスクごとに次の3点を確認します。

1. 今完了することで、どれだけの手作業時間や遅延損失を避けられるか。
2. もう一方の含有プールのモデルで、許容できない品質低下なしに処理できるか。
3. もう1回有料で試しても終わらない場合、いくらで止めるか。

3つとも具体的に答えられるなら、上限付き従量課金は突然停止するより合理的です。3つ目が決まらないなら、先に作業フローを変える方が安全です。

今日そのまま実行できる順序

診断より先に支払いを始めないため、次の順に進めます。

1. 警告の発生元を特定する：Cursor Models、Other Models、Grok Bot、請求画面のどれか。
2. 2つの月間プールを記録する：割合とリセット日を保存し、1つの総量のように扱わない。
3. モデルとタスクを対応させる：直近の重い作業で使ったモデル、並列Agent、長いコンテキストを確認する。
4. 請求区分を見る：Included UsageとOn-Demand Usageが別々に増えているか確認する。
5. スイッチより先に予算を決める：今サイクルの追加上限額を決め、有限の上限付きで従量課金を有効にする。
6. 小さく検証する：範囲が明確なタスクを1つ完了し、2つのプールと請求を再確認する。
7. 確認後にだけ拡大する：結果と消費の両方が許容範囲なら、タスク規模または上限を増やす。

成功とは警告が消えることだけではありません。どのプールが減っているか、なぜ追加費用が増えたか、いくらで作業を止めるかを説明できる状態です。

Cursor Ultraの上限に関するよくある質問

Grok Botが90%なら、Ultraもほぼ使い切ったということですか？

必ずしもそうではありません。Grok Botの週間枠と、Cursor ModelsおよびOther Modelsの月間プールは別のカウンターです。Ultraの含有使用量が残り少ないと判断する前に、usage dashboardで両方のプールを確認してください。

No LimitにするとCursorを無制限に使えますか？

いいえ。No Limitは従量課金の月間支出上限を外すだけです。含有使用量を超えたリクエストには対応する料金が発生します。Ultraのunlimited Tab completionsも、すべてのAgentやモデルリクエストが無料で無制限になるという意味ではありません。

支出上限に達しても使用量は増えますか？

Cursorは停止判定が瞬時ではないため、一時的な超過があり得ると説明しています。限定的な超過分は一時creditとなり、現在の上限まで請求されます。同じサイクルで上限を上げると、その一部または全部が新しい上限まで請求対象になる場合があります。

使用済みの割合だけで、残り作業量を予測できますか？

正確には予測できません。モデルのAPI価格、コンテキスト長、出力量、並列実行が消費を変えます。小さく範囲を限定したタスクを実行し、その後dashboardを確認する方が実用的です。

覚えておくべき判断ルール

従量課金を有効にする前にプールを確認し、上限を引き上げる前に予算を決めます。高頻度で使う個人開発者にとって管理しやすい基本形は、有限の上限、価値の高いタスクを適切なプールへ割り当てること、そして高コストなタスクごとの使用量確認です。最初からNo Limitにすることではありません。