CursorでGrokにコードを直してほしくても、内蔵モデルの選択と、外部APIに向けたキーの設定は別の構成です。文書化されたエージェント連携を使いたいならCursor内蔵のGrok 4.6を、アプリケーション側でリクエスト、ツール、利用量を管理したいならSpicyAPIを直接呼び出してください。 CursorでSpicyAPIのキーを使うには、Cursor Settings → Modelsを開き、カスタムのbase URL上書きがあるか確認します。以下の設定値とフォールバックを見れば、利用枠を購入する前に正しい経路を選べます。
契約の異なる二つのGrok経路
CursorのGrok 4.6ドキュメントには、grok-4.6、256kのコンテキストウィンドウ、そして4段階のeffort(low、medium、high、xhigh、既定はhigh)が記載されています。内蔵の連携では、Cursorのエージェントツールを使えます。
SpicyAPIのモデルページではxai/grok-4.6/chatが示されています。文書化されているOpenAI互換のChat Completionsリクエストでのモデル名はxai/grok-4.6で、送信先はhttps://api.spicyapi.ai/v1/chat/completionsです。この経路はテキストと画像のパートを受け付け、入力上限は500,000トークンで、独自のリクエスト制御があります。現在のスキーマはファイルやPDFのパートを受け付けません。ツール定義はモデルへの入力であり、実行ループは呼び出し側が用意します。
| 判断項目 | Cursor内蔵のGrok | SpicyAPI直接のGrok |
|---|---|---|
| 該当する画面での選択用識別子 | Cursorのドキュメント上のgrok-4.6 | Chat Completionsリクエストではxai/grok-4.6、カタログのエンドポイントはxai/grok-4.6/chat |
| コーディングの作業フローを組み立てて管理するのは誰か | Cursorの統合製品 | 自分のアプリケーション、または検証済みの互換クライアント |
| 入力ウィンドウ | 256kトークン | 500,000トークン |
| ファイル編集とテスト | Cursorがエージェントツールを管理 | 呼び出し側がツールを実行して編集を適用 |
APIの500,000トークンという上限は、Cursorの256kウィンドウを広げるものではありません。コード修正では、リポジトリ全体ではなく、定義を含むファイル、失敗内容、テストを送ってください。
まずPlaygroundで試す
- Grok 4.6を開き、Playgroundに切り替えます。
- メッセージ欄に下の質問を貼り付け、推論オプションでLowを選び、Run modelを押します。
> A delivery-window parser must accept a local time HH:MM from 00:00 through 23:59. The current function returns true for any string matching two digits, a colon and two digits. Explain which inputs it accepts incorrectly, and propose a small correction.
- 回答が24:00と12:60を拒否しているか確認します。拒否していれば、同じ質問をAPIやエディタからそのまま実行できます。
目的に合うなら内蔵経路を使う
- モデルピッカーを開き、アカウントで利用できる場合はGrok 4.6を明示的に選びます。このモデルを使いたいときはAutoではなく明示的な選択を使い、新しいチャットでもう一度確認してください。
- 作業に合わせてeffortを選びます。文書化されているモデルの既定は
highです。インド限定のStartプランでは、GrokはFastモードなしのmediumに固定されます。 - 下に示す使い捨てのパーサープロジェクトを開き、
is-time.mjsに限定した修正を依頼します。 - 適用されたdiffと実際のテスト結果を確認します。正しい説明があっても編集が適用されていなければ、エージェントの作業が完了したこととは別の結果です。
内蔵の選択には、SpicyAPIのbase URLもキーも不要です。費用を見積もるときは、現在のプランの利用枠とFastの設定を基準にしてください。ローンチ記事にある導入時のプロモーションは終了しています。
自分のキーを接続するか、直接APIを選ぶ
CursorのAPIキーのヘルプには、OpenAI、Anthropic、Google、Azure、AWS BedrockについてCursor Settings → Models → プロバイダー → キー → Saveの手順が記載されています。Grok 4.6向けのカスタムエンドポイントは記載されていません。
- Cursor Settings → Modelsを開き、OpenAIのbase URL上書きと、カスタムモデルを追加するオプションを探します。
- 両方の項目がある場合は、base URLに
https://api.spicyapi.ai/v1、プロバイダーのキーにSpicyAPIのキー、カスタムモデルにxai/grok-4.6を入力します。設定を保存します。 - 新しいチャットでそのカスタムモデルを選び、下の小さなパーサーの質問を送ります。大きな作業を送る前に、リクエストがSpicyAPIのログに表示されることを確認してください。
- 項目がない場合や、検証でモデルが拒否された場合は、Cursorのエージェントには内蔵のGrokを使うか、直接APIの例を実行します。SpicyAPIのキーをプロバイダーのキー欄に貼り付けるだけでは足りません。
カスタムキーが対象とするのはチャットで、Tab補完ではありません。BYOKのリクエストも、プロンプトの組み立てのためにCursorのバックエンドを経由し、Cursorのゼロリテンションの約束は適用されません。プロバイダーの料金と、組織プランでのクライアント手数料があればそれは別に発生します。
三つの識別子を混同しない
| 設定値 | SpicyAPI直接の値 | 用途 |
|---|---|---|
| Base URL | https://api.spicyapi.ai/v1 | /chat/completionsを自動で付けるクライアント向け |
| 完全なエンドポイント | https://api.spicyapi.ai/v1/chat/completions | curl、または完全なURLを送る呼び出し側向け |
| リクエストのモデル | xai/grok-4.6 | JSONボディの値 |
| カタログのタスク | xai/grok-4.6/chat | モデルタスクの一覧上の名前であり、Cursor内蔵ピッカーの名称ではない |
base URLと完全なエンドポイントは別々に保ってください。完全なエンドポイントをbaseの欄に入れると、クライアントが自分のパスを付け足したときに/chat/completions/chat/completionsになることがあります。「unknown model」エラーが出たらモデルの値を確認してください。プロンプトやeffortを変えても、指定先は直りません。
目的が一つの直接リクエストから始める
IDE側の切り分けを始める前に、まず直接リクエストを一つ送って、キーとモデルを確認します。
この例は、実行すると課金されるコードレビューのリクエストを一つ作成します。環境変数のキーを使います。max_tokens: 4000が制限するのは表示される返答だけで、推論トークンは出力として課金され、この上限では制限されません。reasoning_effort: lowは推論の作業量を減らしますが、費用の上限を固定するものではありません。
: "${SPICY_API_KEY:?Set SPICY_API_KEY first}"
curl --no-buffer --fail-with-body --dump-header response-headers.txt \
https://api.spicyapi.ai/v1/chat/completions \
-H "Authorization: Bearer $SPICY_API_KEY" \
-H "Content-Type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
--data '{
"model": "xai/grok-4.6",
"messages": [
{"role": "system", "content": "Review only the code shown. Explain the smallest correction and its acceptance cases. Do not claim that you executed anything."},
{"role": "user", "content": "A delivery-window parser must accept a local time HH:MM from 00:00 through 23:59. The current function returns true for any string matching two digits, a colon and two digits. Explain which inputs it accepts incorrectly, and propose a small correction."}
],
"reasoning_effort": "low",
"max_tokens": 4000,
"stream": true,
"stream_options": {"include_usage": true}
}'修正案はストリームのchoices[].delta.contentの断片から、トークン数は最後のusageチャンクから読み取ります。ストリームの形式はドキュメントで説明されています。
直接呼び出しが失敗したら、IDEを加える前に、そのキー、モデル、拒否されたフィールドを直してください。それらのエラーはカスタムクライアントの中でも残ります。
Agentに呼び出しを準備させる
繰り返しのコードレビューでは、コーディングAgentにSpicyAPI Skillを使うよう頼みます。“Read xai/grok-4.6/chat, then adapt the example to my input; show the request before running it.” CLIでの確認はspicyapi models get xai/grok-4.6/chat --json、MCPでの確認はmodel: "xai/grok-4.6/chat"を指定したspicyapi_model_getです。チャットの呼び出しには、互換クライアントかチャットAPIを使います。メディアタスク用のコマンドはチャットの返答を生成しません。
コーディングの題材を実行可能にする
要件はあえて絞ってあります。ちょうどHH:MMだけを受け付け、時は00〜23、分は00〜59、前後に空白は許さない。 次のバグのあるis-time.mjsから始めます。
export function isTime(value) {
return typeof value === 'string' && /^\d{2}:\d{2}$/.test(value);
}受け入れケースをis-time.test.mjsとして保存します。
import assert from 'node:assert/strict';
import test from 'node:test';
import { isTime } from './is-time.mjs';
const cases = [
['00:00', true], ['09:05', true], ['23:59', true],
['24:00', false], ['12:60', false], ['99:99', false],
['9:05', false], ['09:5', false], ['', false],
['09:05x', false], [' 09:05 ', false], ['09:05\n', false],
[null, false], [905, false],
];
for (const [value, expected] of cases) {
test(JSON.stringify(value), () => assert.equal(isTime(value), expected));
}node --test is-time.test.mjsを実行します。最初の関数は3件のケースで失敗します。24:00、12:60、99:99を受け付けてしまうためです。空白、末尾の改行、文字列以外のケースは残してください。後の修正で形式が広がってしまうのを防げます。コーディングエージェントには次のように頼みます。
Correct only is-time.mjs to satisfy the supplied tests. Preserve exactly two digits, reject surrounding whitespace, and return false for non-string input. Do not add a date library or change the tests. Run the tests if your tools permit, and report the actual result.
解の一例は次のとおりです。
export function isTime(value) {
if (typeof value !== 'string' || value.length !== 5) return false;
return /^(?:[01]\d|2[0-3]):[0-5]\d$/.test(value);
}範囲チェックで範囲外の時と分を拒否し、型と長さのチェックで5文字の形式を明示的に保ちます。この解は14件すべてのケースに通ります。エージェントに自分で修正案を作らせ、そのパッチに同じテストを走らせて、diffを読んでください。関数一つの修正で、設定や他の箇所の書式、依存関係に手を入れるべきではなく、5文字の時刻のために日付ライブラリを追加するべきでもありません。
まずカスタムクライアントのプレーンテキスト経路を確認する
同じパーサーの質問をカスタムクライアント経由で送ります。プロバイダー側にタスクが現れない場合は、選択したモデルとリクエストの送信先を確認してください。クライアントがまだ内蔵の経路を使っているか、送信前に失敗している可能性があります。
プレーンテキストが動いたら、他の設定は変えずに、ストリーミング、次にツールの順で追加します。
長い推論にはストリーミングを使う
highやxhighのeffortや長い出力にはstream: trueを使います(この例はすでに使っています)。ストリーミングなしの応答に約100秒を超える時間がかかると切断されることがあり、返答が返らないまま切断されたリクエストには課金されません。通常の最終回答はfinish_reason: stopで終わります。tool_callsはアプリ側に次の手順があることを、lengthはコードがもっともらしく見えても回答が途中で切れたことを意味します。直接のストリームは完了するのにIDEが止まる場合は、モデルを変える前にIDEのイベント処理を確認してください。詳細はテキストとストリーミングのドキュメントを参照してください。
ツール対応にはツールを実行する呼び出し側が必要
APIは最大128個のtools、tool_choice、parallel_tool_calls(真偽値、既定はtrue)を受け付けます。ツールの実装はアプリケーション側で用意する必要があります。
ツールループでは、要求された引数を検証し、許可された操作を実行し、その実際の結果をツールメッセージとして追加して、もう一度モデルを呼び出します。テキストの回答だけでは、パッチを適用することもNodeを実行することもできません。
たとえば、アシスタントが無害なget_acceptance_cases関数を要求したら、呼び出し側はその実際の結果を、対応するIDを付けて返します。
[
{"role":"assistant","content":null,"tool_calls":[{"id":"call_example","type":"function","function":{"name":"get_acceptance_cases","arguments":"{}"}}]},
{"role":"tool","tool_call_id":"call_example","content":"00:00 pass; 23:59 pass; 24:00 fail; 12:60 fail; surrounding whitespace fail"}
]実際のアシスタントメッセージとツール結果を、元の会話に追加してください。上のJSONは、その形を示したものです。ディスパッチの前に関数名と引数を検証し、ファイルの範囲、ツールのターン数、費用に上限を設けます。
この題材では、最初のツールに受け入れケースを返させます。次に、is-time.mjsに限定したファイル編集ツールと、node --test is-time.test.mjsに限定したテスト実行コマンドを加えます。
結果が順不同で届いても、各ツール結果をtool_call_idに対応づけてください。このファイル一つの作業では、parallel_tool_calls: falseにすると自前のハーネスを単純にできます。
チャットは動くのにカスタムクライアントでツールが失敗する場合は、モデルを変える前に、拒否されたフィールドやツールのスキーマを調べてください。
リポジトリのコンテキストは修正に関係するものだけにする
パーサーに必要なのは、その関数、仕様、テストであり、アプリケーション全体ではありません。実際のバグでは、失敗内容、定義を含むファイル、影響を受ける呼び出し箇所を含めます。大規模なリファクタリングを受け入れる前に、足りない情報を尋ねてください。
直接の経路は最大256件のメッセージを受け付けます。トークン数とメッセージ数は別々の上限です。過去の回答、ツール結果、画像もコンテキストを占めます。長いセッションでは、現在のソースと実際のテスト結果を、簡潔な判断の要約とともに保ってください。カスタムIDEは選択したファイルを要約したり省いたりすることがあるため、API側のウィンドウが大きくても、クライアントが送らなかったコンテキストは補えません。
画像入力とファイル入力は別の機能として扱う
ホスト型の経路はテキストとimage_urlのパートを受け付け、PDFやファイルのパートは受け付けません。UIの見た目のバグでは、取得可能なスクリーンショットを仕様と組み合わせます。たとえば、24:00を表示した画面は、パーサーの無効入力の状態を示す例になります。テキストの題材そのものに画像は不要です。
PDFの仕様書は、関連するテキストをローカルで抽出し、表の順序と脚注を確認してから送ります。これは抽出の作業フローであり、ネイティブのPDF入力ではありません。カスタムIDEが画像を転送できない場合や、未対応のファイルフィールドを付け足してしまう場合は、対応している直接リクエストか、そのテキスト版を使ってください。
作業に合わせてeffortと出力上限を選ぶ
直接APIはlow、medium、high、xhighを受け付けます。既定はhighで、noneは受け付けません。小さなパーサーのリクエストでは、明示的にlowを使います。より難しい修正で、低い設定では受け入れケースを満たせないときにeffortを上げてください。
IDEがeffortの操作を隠している場合、そのモードは直接リクエストと異なることがあります。説明の丁寧さの印象ではなく、実際のパッチと使用量を比べてください。
max_tokensの既定は4,096で、表示される返答として最大450,000トークンまで受け付けます。関数一つのパッチなら小さく保ちます。推論によって、課金される出力がそのパッチの何倍にもなることがあり、特に既定のhighでは顕著です。日常的な修正ではeffortを下げ、usageをもとに予算を立て、エージェントのループにはAPIキーごとの日次・累計の支出上限と、ワークスペースの日次・月次予算を設定してください。このChat Completionsエンドポイントには、呼び出しごとの見積もり上限はありません。
effortの設定を比べている間は、temperatureとtop-pは既定のままにします。
課金カテゴリを崩さずにトークン価格を読む
SpicyAPIの料金は、100万トークンあたり、キャッシュなしの入力が$2.00、キャッシュ済みの入力が$0.50、出力が$6.00です。キャッシュ済みの入力を含む入力の合計が200,000トークン以上になると、リクエスト全体にそれぞれ$4.00、$1.00、$12.00が適用されます。これらは利用者向けのカタログ価格であり、クライアントに新たな課金が発生したという記録ではありません。
キャッシュなしの入力12,000トークン、キャッシュ済みの入力8,000トークン、課金される出力2,000トークンという仮定の直接リクエストでは、カタログに基づく計算は次のとおりです。
Uncached input: 12,000 / 1,000,000 × $2.00 = $0.0240
Cached input: 8,000 / 1,000,000 × $0.50 = $0.0040
Output: 2,000 / 1,000,000 × $6.00 = $0.0120
Total: $0.0400この例の入力の合計は20,000であり、12,000ではありません。usageのフィールドが入力の合計とキャッシュ済みの部分集合を報告する場合は、キャッシュ済みのトークンを二重に課金しないでください。キャッシュ済みの部分集合を引くとキャッシュなしの入力になります。実際のリクエストを突き合わせるときは、実際のレスポンスのカテゴリとプラットフォームの記録を使います。
キャッシュなしの入力180,000、キャッシュ済みの入力30,000、課金される出力4,000という長いコンテキストの例では、入力の合計は210,000です。長いコンテキスト用の料金での計算は$0.720 + $0.030 + $0.048 = $0.798です。しきい値はリクエストのカテゴリ全体に適用され、200,000を超えた分だけには適用されません。そのため、不要なコンテキストを減らすと、トークン数と適用される料金区分の両方が変わることがあります。
これらは仮定のトークン数です。usageがキャッシュヒットを報告するまでは、キャッシュによる節約なしで予算を立ててください。精算は、推論の出力を含む実測の使用量に基づきます。
Cursorの価格と直接の価格は慎重に比べる
CursorのModels and Pricingページには、Grok 4.6の標準料金が100万トークンあたり入力$2、キャッシュ済み入力$0.50、出力$6、Fast料金が$4、$1、$12と記載されています。Fastは対象のProプランで既定で有効なので、長い作業を始める前にセレクターを確認してください。内蔵のGrokは、CursorのModelsプールとプランの利用枠から消費されます。サブスクリプションの利用枠、速度の選択、アカウント固有の条件が実際の支払いに影響するため、掲載された料金は月額請求の予測ではありません。
同じ入力(キャッシュなし)12,000、入力(キャッシュ済み)8,000、出力2,000トークンの場合、Cursorの標準は合計$0.040、Fastは$0.080、直接APIは$0.040で、掲載料金ではCursorの標準と同額です。これらの計算は、人工的に同一の使用量を仮定して、表示されたトークン単価を比べたものです。両製品が同じ作業をすることを示すものではありません。実際のエージェントのセッションでは、消費するトークン数が異なることがあります。
内蔵のエージェントは、ファイルの読み取り、パッチの適用、テストの再実行のために複数回呼び出すことがあります。トークン単価一つではなく、完了した修正にかかった総費用で比べてください。
CursorのAPIキーのヘルプには、TeamsとEnterpriseのBYOKに対して、入力、出力、キャッシュ済み入力をそれぞれ一度だけ数えて100万トークンあたり$0.25が別途かかると記載されています。22,000トークンの例では、プロバイダーの料金に$0.0055が加わります。個人のBYOKには、この組織プランのトークン手数料はありません。この手数料があるからといって、特定のカスタムモデルに対応していることにはなりません。
最初の作業では、総費用と、適用した修正がテストに通ったかどうかを記録してください。
Cursorの利用状況画面にある「Other Models」は課金のプールであり、リクエストが外部のプロバイダーに送られた証拠ではありません。直接の呼び出しかどうかは、プロバイダー側のタスク記録で確認してください。
観察できる順に失敗を切り分ける
- 送信先またはキー: effortを変える前に、401、unknown model、重複したパスを確認します。
- 拒否されたフィールド: 未対応のパラメーターやコンテンツパートを外し、機能を一つずつ追加します。
- UIが空、または止まる: 直接のレスポンスを、クライアントのパーサー、終了理由、完了マーカーと比べます。
- ツールが実行されない: 呼び出し側のツールのディスパッチと権限を確認します。
- パッチが誤っている: 失敗した受け入れケースと、実際に変更されたファイルを確認します。
次の変更は、失敗した層に対処するものにしてください。プロンプトを増やしても、拒否されたパラメーターは直りません。
二つ目の題材で会話のミスをあぶり出す
厳格なパーサーが通ったら、要件を一つ変えます。前後の空白は許すが、時刻の各要素は2桁のままにする。新しいケースでは、今度は通るべき 09:05 と、依然として失敗する9:05を区別します。型チェックの後、既存の長さ・範囲チェックの前にtrim()を適用し、二つの版のテストは別々に保ってください。
次のターンでは、修正後のソースと変更した要件を送ってください。リクエストIDに会話の記憶はありません。新しいパッチが9:05を受け付けたり、古い関数を編集したりする場合は、その後のテストで誤りが露呈します。
必要な根拠に合う経路を選ぶ
統合された編集とテスト実行にはCursor内蔵を選びます。自分のツールループと使用量の管理には直接APIを選びます。接続確認に成功した場合は、チャットにカスタムキーの設定を使えます。統合されたファイル編集とテストには、引き続きCursor内蔵が分かりやすい選択です。
このパーサーでは、修正を関数の範囲にとどめ、適用したパッチに対して14件すべてのテストを実行してください。
