Cursor와 API로 쓰는 Grok 4.6: 설정, 코드, 비용

Cursor에서 Grok이 코드를 고치게 하고 싶지만, 내장 모델을 선택하는 것과 외부 API로 키를 연결하는 것은 서로 다른 구성입니다. 문서화된 에이전트 통합이 필요하면 Cursor 내장 Grok 4.6을 쓰고, 애플리케이션이 요청, 도구, 사용량을 직접 관리해야 하면 SpicyAPI를 직접 호출하세요. Cursor 안에서 SpicyAPI 키를 쓰려면 Cursor Settings → Models를 열어 사용자 지정 base URL 재정의가 있는지 확인합니다. 아래 설정 값과 대안을 보면 사용량을 구매하기 전에 올바른 경로를 고를 수 있습니다.

계약이 다른 두 가지 Grok 경로

Cursor의 Grok 4.6 문서에는 grok-4.6, 256k 컨텍스트 윈도우, 그리고 네 가지 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 파트를 받지 않습니다. 도구 정의는 모델에 대한 입력일 뿐이며, 실행 루프는 호출하는 쪽에서 제공해야 합니다.

API의 500,000 토큰 한도가 Cursor의 256k 윈도우를 넓혀 주지는 않습니다. 코드 수정에는 저장소 전체가 아니라 정의가 있는 파일, 실패 내용, 테스트를 보내세요.

먼저 Playground에서 시험하기

1. Grok 4.6을 열고 Playground로 전환합니다.
2. 메시지 입력란에 아래 질문을 붙여 넣고, 추론 옵션에서 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.

1. 답변이 24:00과 12:60을 거부하는지 확인합니다. 거부한다면 같은 질문을 API나 편집기에서 그대로 실행할 수 있습니다.

작업이 그것이라면 내장 경로를 쓰기

1. 모델 선택기를 열고 계정에서 제공되는 경우 Grok 4.6을 명시적으로 선택합니다. 이 모델을 쓰고 싶다면 Auto 대신 명시적 선택을 쓰고, 새 채팅에서 다시 확인하세요.
2. 작업에 맞게 effort를 고릅니다. 문서화된 모델 기본값은 high입니다. 인도 전용 Start 플랜은 Grok을 Fast 모드 없이 medium으로 고정합니다.
3. 아래의 일회용 파서 프로젝트를 열고 is-time.mjs에 한정한 수정을 요청합니다.
4. 적용된 diff와 실제 테스트 결과를 확인합니다. 올바른 설명이 있어도 적용된 편집이 없다면, 에이전트 작업이 끝난 것과는 다른 결과입니다.

내장 선택에는 SpicyAPI의 base URL도 키도 필요 없습니다. 예산을 잡을 때는 현재 플랜의 허용량과 Fast 설정을 기준으로 하세요. 출시 글에 있던 초기 프로모션은 끝났습니다.

내 키를 연결하거나 직접 API를 고르기

Cursor의 API 키 도움말에는 OpenAI, Anthropic, Google, Azure, AWS Bedrock에 대해 Cursor Settings → Models → 제공자 → 키 → Save 절차가 나와 있습니다. Grok 4.6용 사용자 지정 엔드포인트는 문서에 없습니다.

1. Cursor Settings → Models를 열어 OpenAI base URL 재정의와 사용자 지정 모델 추가 옵션을 찾습니다.
2. 두 컨트롤이 모두 있으면 base URL에 https://api.spicyapi.ai/v1, 제공자 키에 SpicyAPI 키, 사용자 지정 모델에 xai/grok-4.6을 입력합니다. 설정을 저장합니다.
3. 새 채팅에서 그 사용자 지정 모델을 선택하고 아래의 작은 파서 질문을 보냅니다. 더 큰 작업을 보내기 전에 요청이 SpicyAPI 로그에 나타나는지 확인하세요.
4. 컨트롤이 없거나 검증에서 모델이 거부되면, Cursor의 에이전트에는 내장 Grok을 쓰거나 직접 API 예제를 실행합니다. SpicyAPI 키를 제공자 키 입력란에 붙여 넣는 것만으로는 충분하지 않습니다.

사용자 지정 키가 적용되는 것은 채팅이며 Tab 자동 완성은 해당되지 않습니다. BYOK 요청도 프롬프트 구성을 위해 Cursor의 백엔드를 거치며, 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를 실행합니다. 처음의 함수는 세 케이스에서 실패합니다. 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);
}

범위 검사는 범위를 벗어난 시와 분을 거부하고, 타입과 길이 검사는 다섯 글자 형식을 명시적으로 유지합니다. 이 해법은 열네 케이스를 모두 통과합니다. 에이전트가 직접 수정안을 만들게 하고, 그 패치에 같은 테스트를 실행한 뒤 diff를 읽어 보세요. 함수 하나를 고치는 수정이라면 설정, 다른 곳의 서식, 의존성을 건드려서는 안 되고, 다섯 글자 시각 때문에 날짜 라이브러리를 추가해서도 안 됩니다.

먼저 사용자 지정 클라이언트의 일반 텍스트 경로를 확인하기

같은 파서 질문을 사용자 지정 클라이언트로 보냅니다. 제공자 쪽에 태스크가 나타나지 않으면 선택한 모델과 요청 대상을 확인하세요. 클라이언트가 아직 내장 경로를 쓰고 있거나, 보내기 전에 실패했을 수 있습니다.

일반 텍스트가 동작하면 다른 설정은 바꾸지 말고 스트리밍을, 그다음에 도구를 추가합니다.

긴 추론에는 스트리밍을 쓰기

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 컨트롤을 숨기고 있다면, IDE가 고른 모드가 직접 요청과 다를 수 있습니다. 설명이 얼마나 꼼꼼해 보이는지가 아니라 실제 패치와 사용량을 비교하세요.

max_tokens의 기본값은 4,096이며 보이는 답변 기준으로 최대 450,000 토큰까지 받습니다. 함수 하나짜리 패치라면 작게 유지하세요. 추론 때문에 과금되는 출력이 그 패치보다 몇 배나 길어질 수 있으며, 특히 기본값인 high effort에서 두드러집니다. 일상적인 수정에는 낮은 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

이 예에서 입력 합계는 12,000이 아니라 20,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가 비어 있거나 멈춤: 직접 응답을 클라이언트의 파서, 종료 사유, 완료 마커와 비교합니다.
• 도구가 실행되지 않음: 호출 쪽의 도구 디스패치와 권한을 확인합니다.
• 잘못된 패치: 실패한 수용 케이스와 실제로 변경된 파일을 확인합니다.

다음 변경은 실패한 층을 겨냥해야 합니다. 프롬프트를 늘려도 거부된 파라미터는 고쳐지지 않습니다.

두 번째 예제로 대화 실수를 드러내기

엄격한 파서가 통과하면 요구 사항을 하나 바꿉니다. 앞뒤 공백은 허용하되, 시각 요소는 두 자리를 유지한다. 새 케이스는 이제 통과해야 하는 09:05 와 여전히 실패하는 9:05를 구분합니다. 타입 검사 뒤, 기존의 길이·범위 검사 앞에 trim()을 적용하고, 두 버전의 테스트는 따로 두세요.

다음 턴에는 수정된 소스와 바뀐 요구 사항을 함께 보내세요. 요청 ID에는 대화 기억이 없습니다. 새 패치가 9:05를 받아들이거나 예전 함수를 수정한다면, 후속 테스트가 그 오류를 드러냅니다.

필요한 근거에 맞는 경로를 고르기

통합된 편집과 테스트 실행에는 Cursor 내장을 고르세요. 자체 도구 루프와 사용량 제어에는 직접 API를 고르세요. 연결 확인에 성공했다면 채팅에는 사용자 지정 키 설정을 쓸 수 있습니다. 통합된 파일 편집과 테스트에는 여전히 Cursor 내장이 가장 분명한 선택입니다.

이 파서에서는 수정을 함수 범위에 한정하고, 적용된 패치에 대해 열네 개 테스트를 모두 실행하세요.