본문으로 건너뛰기

Grok 4.6은 OpenAI 호환 호출로 쓰는 xAI의 멀티모달 chat 모델로, 한 턴에 텍스트와 이미지 부분을 담습니다. 요청은 500,000 토큰까지, 응답은 450,000 토큰까지이며 추론 강도 4단계를 제공합니다.

입력 $2출력 $6100만 토큰당캐시된 입력 $0.50200K 토큰 이상 프롬프트입력 $4출력 $12

플레이그라운드

Grok 4.6

Grok 4.6에게 무엇을 부탁할까요?

관련 모델과 다음 단계

찾는 모델이 없나요?

필요한 모델과 쓰려는 목적을 알려 주세요. 다음에 무엇을 추가할지 정하는 팀에 바로 전달됩니다.

구현, 에이전트 작업, 지식 노동에 맞는 안정적인 메시지 흐름

Grok 4.6은 이 카탈로그에서 xAI의 최상위 모델입니다. 컨텍스트 500,000 토큰, 한 번의 응답 최대 450,000 토큰, 추론 강도는 low부터 xhigh까지이며 기본값은 high입니다. 입력은 텍스트와 이미지이며, 이 경로는 file/PDF 파트를 받지 않습니다.

채팅 플레이그라운드 열기
구현, 에이전트 작업, 지식 노동에 맞는 안정적인 메시지 흐름
모델
Grok 4.6
적합한 작업
구현, 에이전트 작업, 지식 노동
메시지 구조
시스템 규칙 → 근거와 상태 → 이번 과제 → 출력 사양
사실의 범위
기능·제어 항목·가격은 실시간 스키마에서 옵니다

통합 원칙

가장 작은 메시지 구성으로 과제를 먼저 검증하고 필요한 맥락만 더하세요. 사실과 가정과 제약을 분리하고 중단, 재시도, 정산, 사람 검토 경로까지 설계합니다.

구현, 에이전트 작업, 지식 노동에 재현 가능한 작업 흐름 만들기

Grok 4.6은 이 카탈로그에서 xAI의 최상위 모델입니다. 컨텍스트 500,000 토큰, 한 번의 응답 최대 450,000 토큰, 추론 강도는 low부터 xhigh까지이며 기본값은 high입니다. 입력은 텍스트와 이미지이며, 이 경로는 file/PDF 파트를 받지 않습니다.

  • 윈도 배분

    입력 500,000, 출력 450,000

    윈도의 거의 전부를 한 번의 응답으로 돌려받을 수 있습니다. 긴 입력을 읽는 일뿐 아니라 긴 답을 쓰는 일 자체가 중심인 작업에 맞습니다.

  • 추론 강도

    네 단계, 기본값은 high

    low, medium, high, xhigh가 열려 있습니다. 추론 토큰은 출력으로 계산되므로 강도를 올릴 때 max_tokens 상한도 같이 올리세요.

  • 입력 파트

    텍스트와 이미지, 파일은 불가

    한 메시지에 텍스트 파트와 image_url 파트(detail은 auto, low, high)를 섞을 수 있습니다. file/PDF 파트는 이 경로에서 거부되므로 문서는 먼저 텍스트나 페이지 이미지로 바꾸세요.

과제의 무게와 상호작용 형태로 Grok 4.6 고르기

범용 순위표에 기대지 말고, 같은 실제 과제로 품질, 검증 가능성, 지연, 판매가 적합성을 확인하세요.

  1. 4.6 선택

    답 자체가 길고 어려움

    대규모 리팩터링, 코드를 많이 쓰는 에이전트 실행, 증거 묶음 전체를 한 턴에 들고 결론까지 가야 하는 지식 노동.

  2. 4.5 검토

    하루 종일 도는 긴 프롬프트 하나

    같은 선두 블록을 매번 다시 보내는 루프라면 형제 모델의 캐시 입력 단가가 더 낮습니다. 두 가격 카드를 비교한 뒤 정하세요.

  3. 4.3 검토

    깊이보다 처리량

    분류, 추출, 라우팅은 윈도가 더 넓고 추론을 아예 끌 수 있는 형제 모델의 몫입니다.

Grok 4.6의 능력을 막연한 라벨이 아니라 구체적인 일로 바꾸기

모든 시나리오에는 입력 경계, 검증, 복구가 필요합니다. 공식 기능, 벤치마크, 도구 지원을 지어내지 않습니다.

  • 저장소 규모의 변경을 한 턴에

    구현

    저장소 규모의 변경을 한 턴에

    인터페이스, 불변 조건, 테스트를 주고 계획과 diff, 그 변경이 만들어 내는 마이그레이션 위험까지 요구하세요.

  • 계획이 넓은 도구 호출

    에이전트

    계획이 넓은 도구 호출

    함수 정의는 최대 128개, tool_choice와 함께 쓸 수 있습니다. 되돌릴 수 없는 단계는 제품이 직접 관리하는 승인 관문 뒤에 두세요.

  • 긴 증거 묶음을 결정으로 닫기

    지식 노동

    긴 증거 묶음을 결정으로 닫기

    출처마다 이름을 붙이고, 출처에서 결론까지의 경로를 요구하며, 어떤 전제가 뒤집히면 권고가 달라지는지도 쓰게 하세요.

  • 이미지는 장식이 아니라 증거

    화면과 도표

    이미지는 장식이 아니라 증거

    작은 글자가 중요하면 스크린숏이나 구성도를 detail: high로 보내고, 거기서 무엇을 읽어야 하는지 정확히 말하세요.

맥락을 Grok 4.6 API가 검사할 수 있는 입력으로 정리

목표, 근거, 상태, 제약, 출력 사양이 각자 다른 역할을 맡아야 요청을 압축하고 디버깅하고 재현할 수 있습니다.

  1. system

    변하지 않는 규칙은 고정 블록에

    페르소나, 출력 계약, 규약은 실행마다 움직이면 안 됩니다. 선두가 안정적이어야 캐시도 가능해집니다.

  2. 증거

    출처는 모두 구분하고 이름 붙이기

    텍스트 파트든 이미지 파트든 이름이 필요합니다. 결론이 근거가 된 자료를 되짚을 수 있어야 하기 때문입니다.

  3. 강도

    강도는 과제에 맞추기

    제약이 서로 얽힐 때 올리고, 초안이나 다시 쓰기처럼 지연이 체감되는 작업에서는 낮게 두세요.

  4. 출력

    파싱할 형태를 먼저 말하기

    response_format으로 JSON 객체를 요구할 수 있습니다. 필수 필드와 결과가 비었을 때의 형태를 정해 두세요.

제품에 붙이기 전에 Grok 4.6 재현 사례부터 증명

실시간 스키마, 견적, 스트리밍, 오류 동작을 확인한 뒤에 통합 요청을 재사용하세요.

  1. 01 · 기준선

    가장 작은 요청을 플레이그라운드에서 검증

    메시지 계층, 출력 형태, 스트리밍, 현재 제어 항목을 확인합니다.

  2. 02 · 경계

    실패·취소·재시도를 실행

    타임아웃, 끊긴 스트림, 과도한 입력, 재생성, 중복 제출을 검증합니다.

  3. 03 · 통합

    통합 API 요청을 그대로 복사

    공개 모델 id와 messages 사양을 쓰고, 모델 제어 항목은 실시간 스키마에서 읽습니다.

  4. 04 · 운영

    사용량을 계량하고 계속 평가

    상태, 최종 사용량, 실패 사유, 품질 피드백을 저장하고 비싼 호출은 먼저 견적을 보여 줍니다.

Grok 4.6의 능력을 명확한 계약 위에 올리기

플레이그라운드, API 예시, 요청 상태, 사용량 기록이 서로 어긋나지 않으므로 평가에서 운영 통합까지 같은 이해로 갑니다.

  • 공통 사양

    메시지·스트림·오류가 한 가지 형태

    모델을 바꿔도 요청 구성, 상태 처리, 오류 복구 방식은 그대로 유지됩니다.

  • 실시간 스키마

    현재 엔드포인트의 제어 항목 사용

    플레이그라운드와 API 예시가 사용 가능한 필드, 한도, 기본 동작을 함께 보여 줍니다.

  • 관측 가능한 수명주기

    모든 요청에 분명한 상태가 있음

    제출, 스트리밍, 실패, 취소, 사용량이 검사 가능한 공개 의미로 표현됩니다.

  • 이식 가능한 통합

    모델이 바뀔 때의 재작업 줄이기

    계약이 분명하면 제품 코드는 입력, 결과, 사용자 경험에 집중할 수 있습니다.

Grok 4.6 API 통합 전에 확인할 경계