CursorおよびxAI APIにおけるGrok 4.7：料金試算・Effortモード・Fastモード・コンテキストキャッシュの徹底解説

CursorへのGrok 4.7（モデル識別子：grok-4.7）の統合は、開発者の間で大きな関心を集めています。エディタのインターフェースには、推論の深さを指定するreasoning_effortと、Fastモードの切り替えという新たな設定項目が追加されました。しかしリリース以降、これらの設定がサブスクリプションの利用枠（allowance）の消費にどう影響するのか、また一般的な開発タスクで実際に何リクエスト分が差し引かれるのかについて、混乱が生じています。

ここで最も陥りやすい方法論的な落とし穴は、公開されているxAI APIの料金設定からCursorの消費ルールを直接推測しようとすることです。的確な判断を下すには、公式のxAI料金体系（コンテキストキャッシュの挙動や長文コンテキストの閾値を含む）と、アカウントの管理画面で直接確認するしかないCursor独自のクォータ消費ルールの2つの異なるレイヤーを明確に区別する必要があります。

---

コミュニティでの議論：利用枠への疑問と検証ベンチマークの不足

新モデルに関する議論は、9月23日にユーザーIACROSが刷新されたモデル選択メニューを共有したr/cursorコミュニティへの投稿から始まりました。

そのスレッド内で、ユーザーdiymuppetは利用枠の消費コストが不透明である点を次のように指摘しました。

「…利用枠（allowance）の消費コストが明確ではありません… High / Extra Highは、ユーザー個人にとって具体的に何を意味するのでしょうか？」

また、コミュニティメンバーのabjectchain96は、Fastモードは2倍のコストがかかると推測して利用を控えるよう助言し、推論effortのレベルをタスクの複雑さに応じて使い分けることを提案しました。

一見すると合理的に思えるこれらの議論ですが、対照条件を整えたベンチマークや、Cursorのアカウント残高に基づく検証データは一切提示されていませんでした。参加者は実際のクォータ消費量を計測することなく、憶測のみを共有していたのです。フォーラム上の推測だけを根拠に利用枠の消費ルールを結論付けるのは危険です。実際の消費ルールはユーザーの推測ではなく、Cursorのサブスクリプション規約によって定義されているためです。

---

公式xAI APIの料金体系：標準コンテキストと長文コンテキストの比較

xAIのパブリックAPIにおいて、grok-4.7は500,000トークンのコンテキストウィンドウを持ち、ナレッジカットオフは2026年5月となっています。基本料金はxAI公式料金ページに掲載されています。

標準コンテキスト（200kトークン未満）

入力の合計サイズが200,000トークン未満のリクエストには、以下の標準料金が適用されます：

• キャッシュなし入力（Uncached Input）： 100万トークンあたり$2.00
• キャッシュ済み入力（Cached Input）： 100万トークンあたり$0.50
• 出力トークン（Output、推論トークンを含む）： 100万トークンあたり$6.00

1リクエスト$0.27の試算例

以下のパラメータを持つ独立したAPIリクエストを想定します：

• キャッシュなし入力：100,000トークン（ベースコンテキスト、システム指示、タスクコード）
• キャッシュ済み入力：20,000トークン（変更のないセッション履歴）
• 出力トークン：10,000トークン（推論トークンおよび生成された回答）

ステップ別の計算内訳：

1. キャッシュなし入力：$100,000 \times \frac{$2.00}{1,000,000} = $0.20$
2. キャッシュ済み入力：$20,000 \times \frac{$0.50}{1,000,000} = $0.01$
3. 出力：$10,000 \times \frac{$6.00}{1,000,000} = $0.06$
4. リクエスト合計コスト： $$0.20 + $0.01 + $0.06 = \mathbf{$0.27}$

長文コンテキストの閾値（200kトークン以上）

xAIのAPIには段階的な料金体系（ティア制）が導入されています。プロンプト入力の合計が200,000トークン以上に達すると、超過分だけでなくそのリクエストに含まれるすべてのトークンに対して割増料金が適用されます。

200k以上のコンテキストに対する料金：

• キャッシュなし入力：100万トークンあたり$4.00
• キャッシュ済み入力：100万トークンあたり$1.00
• 出力トークン：100万トークンあたり$12.00

200k以上となるリクエストの具体的な試算例

入力コンテキストの合計が200kの閾値を超える大規模コードベースでのリクエストを想定します：

• キャッシュなし入力：180,000トークン
• キャッシュ済み入力：40,000トークン（合計入力：$180,000 + 40,000 = 220,000$ トークン ≧ 200k）
• 出力トークン：10,000トークン

計算内訳：

1. キャッシュなし入力：$180,000 \times \frac{$4.00}{1,000,000} = $0.72$
2. キャッシュ済み入力：$40,000 \times \frac{$1.00}{1,000,000} = $0.04$
3. 出力：$10,000 \times \frac{$12.00}{1,000,000} = $0.12$
4. リクエスト合計コスト： $$0.72 + $0.04 + $0.12 = \mathbf{$0.88}$

この閾値は、直接xAI APIを呼び出す場合にのみ厳密に適用されます。xAIの200kの閾値をCursor内部の消費量にそのまま当てはめることはできません。Cursorは独自のメカニズムでコンテキストウィンドウとプラン制限を管理しているためです。

---

Fastモード：その位置付けと料金仕様の詳細

Fastモードは、軽量化された蒸留モデルであると誤解されがちです。しかしxAIの仕様によれば、実態は以下の通りです：

1. アーキテクチャ： 応答レイテンシを最小化するために最適化された高スループットインフラストラクチャ上で動作する、完全なフルサイズのgrok-4.7モデルそのものです。
2. 提供形態： パートナー連携（CursorやGrok Buildプラットフォームなど）向けに設計されており、一般的なパブリックxAIエンドポイントでは提供されていません。
3. パートナー向け料金： xAIが設定するパートナー向けFast料金は、200k未満のコンテキストで$4.00 / $1.00 / $12.00（標準料金の正確に2倍）、200k以上のコンテキストで$6.00 / $1.50 / $18.00（長文標準料金の1.5倍）となっています。

CursorにおけるFastモードの消費

xAIのパートナー料金体系が2倍だからといって、Cursor側でも正確に2リクエスト分が差し引かれたり、利用枠の消費が2倍になったりするとは限りません。Cursorの課金管理システムは、独自の使用量指標（Fastリクエスト数やサブスクリプションのプラン区分）で運用されています。実際の差し引き量は契約プランの条件に依存するため、アカウント画面で直接追跡・確認するしかありません。

---

Reasoning Effortの制御とPrompt Cachingの仕組み

Grok 4.7では、推論プロセスがモデルのアーキテクチャにネイティブに組み込まれており、無効化することはできません。パラメータであるpresencePenalty、frequencyPenalty、stopはサポートされておらず、指定するとリクエストエラーが発生します。

reasoning_effortパラメータは分析の深さを制御します：

• low：最小限の思考時間と最短のレイテンシ。単純な修正や単一のツール実行に適しています。
• medium：生成速度とコード生成深度のバランスが取れた設定。
• high（デフォルト）：アーキテクチャの綿密な分析、複雑な依存関係やアルゴリズムの処理。
• xhigh：最大限の探索深度。応答レイテンシは顕著に増加します。

内部の推論トークンの正確な数は公開ドキュメントで固定されておらず、通常の出力トークンと同じレートで課金されます。「単純なタスクにhighは無駄」あるいは「複雑なコードにはxhighが必須」と決めつけるべきではありません。唯一信頼できる判断基準は、自身のコードベース上でコードの品質、応答レイテンシ、そして利用枠の消費量を実測することです。

Prompt Caching（プロンプトキャッシュ）の仕組み

Prompt Cachingの仕組みにより、変更のない重複コンテキストに対する課金を削減できます：

• ルーティングと局所性（Locality）： Responses APIでprompt_cache_keyパラメータを渡すか、Chat Completionsでx-grok-conv-idヘッダーを指定することで、キャッシュがウォームな状態のノードにリクエストをルーティングできます。これによりキャッシュヒットの確率が高まりますが、これらは必須ではありません。キーを省略したからといって、後続のすべての呼び出しが必ずコールドになるとは限りません。
• 確率的なキャッシュ挙動： ノードの再起動やキャッシュの追い出しが発生し得るため、キャッシュヒットは100%保証されるものではありません。モデルによって認識された実際のキャッシュ量は、usage.prompt_tokens_details.cached_tokensフィールドで返されます。
• マルチターンのコンテキスト： マルチターン対話において、Responses APIは暗号化されたreasoning.encrypted_contentブロックを返します（またはprevious_response_idを介して参照）。これを後続の呼び出しで渡すことで、サポートされている仕様の範囲内で推論の継続性が維持されます。ただし、それ以外のシナリオにおいてキャッシュが必ず破棄されたりコンテキストが永久に失われたりすると断定することは避けるべきです。
• プレフィックスの不変性： 過去の会話ターンの編集、システムプロンプトの変更、あるいはコンテキスト断片の並び替えを行うと、キャッシュのプレフィックス一致が崩れ、ヒット率が大幅に低下します。

---

ペアベンチマークプロトコル：Cursor利用枠の実測手順

Cursorにおける利用枠の消費は、xAI APIのドル換算額や200kの閾値と1対1で対応しているわけではありません。そのため、真のコストを把握する唯一の方法は、同等の2つのタスクを用いて分離されたベンチマーク測定を実施することです。

1. 準備（Setup）

• 同一リポジトリ内で、規模と複雑さが同等のタスクを2つ準備します（例：同規模のモジュールに対するテストコード作成を行うTask AとTask B）。
• Cursorのアカウント使用量パネル（Subscription / Usage設定）を開きます。
• 以下の項目に沿ってベースライン指標を記録します：

記録項目	記録例
タスク識別子	Task A (Standard) / Task B (Fast)
エディタインターフェース	Chat / Composer
モデルとモード	Grok 4.7 Standard / Grok 4.7 Fast
reasoning_effort レベル	medium（両テストで同一に設定）
初期利用枠残高	実行前に記録した残高
生成時間（レイテンシ）	計測された所要時間（秒）
最終利用枠残高	応答完了後に記録した残高
実際の利用枠消費量	差分（消費されたユニット数 / リクエスト数）
成果物の品質	コードの正確性、テストの通過状況

2. テストの実施（Execution）

1. テスト1（Standard）： クリーンな新規セッションを開始し、標準モードのGrok 4.7を選択してeffortをmediumに設定します。Task Aを送信します。生成所要時間を計測し、アカウントプロファイルで利用枠の消費量を記録します。
2. テスト2（Fast）： 同じワークスペースファイル群を用いて別のクリーンなセッションを開始し、Grok 4.7 Fastを選択してeffortを同じくmediumに設定します。Task Bを送信します。実行レイテンシと新たなクォータ消費量を記録します。

3. 判断基準（Decision Path）

• Fastモードの消費量がStandardと同等、あるいは差がごくわずかで、明確な速度向上が得られる場合：インタラクティブなチャットや迅速なデバッグ用途にはFastモードが適しています。
• Fastモードの消費量が大幅に高く、秒単位のレイテンシ短縮がそれほど重要でない場合（Composerによるバックグラウンド生成など）：標準モードをデフォルトとして維持します。
• mediumでのコード品質が不十分な場合： 同じタスク種別でhighを試し、レイテンシの増加とクォータ消費をモニタリングします。highは複雑に入り組んだロジックに限定して利用するのが賢明です。

4. トラブルシューティング（Troubleshooting）

• 利用枠の減りが想定より早い場合：
  • Cursorアカウントのダッシュボードで詳細な利用内訳（Usage breakdown）を確認してください。
  • アクティブセッションのコンテキスト量を確認してください。多数のファイルが添付された長いスレッドは、選択したモデルに関係なくプロンプトサイズを肥大化させます。
  • 最新のCursorプラン規約を確認してください。xAIの200k API閾値がエディタ側の課金を直接決定していると思い込まないようにしましょう。
• 応答レイテンシが極端に長い、またはフリーズしたように見える場合：
  • reasoning_effortをmediumまたはlowに下げてください。
  • 会話を新規にリセットし、過去の冗長な履歴の再処理を避けてください。
• モデルの利用不可エラーが発生する場合：
  • Cursor設定内のプロバイダー設定および認証状態を確認してください。
  • 独自のAPIキーを使用している場合は、xAI開発者コンソールでアカウント残高と権限を確認してください。

---

参考文献

1. xAI Docs — Grok 4.7
2. xAI Docs — Reasoning
3. xAI Docs — Prompt Caching in Multi-turn
4. xAI Docs — Pricing
5. Reddit r/cursor — Discussion on Grok 4.7