본문으로 건너뛰기

Grok 4.5는 에이전트형 소프트웨어·엔지니어링 작업을 위한 xAI의 코딩 모델로, OpenAI 호환 chat 호출로 씁니다. 최대 500,000 토큰을 받고 450,000 토큰까지 반환하며 추론 강도는 xhigh까지입니다.

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

플레이그라운드

Grok 4.5

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

관련 모델과 다음 단계

찾는 모델이 없나요?

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

에이전트형 소프트웨어, 엔지니어링, 긴 프롬프트를 반복하는 루프에 맞는 안정적인 메시지 흐름

Grok 4.5는 에이전트형 소프트웨어, 엔지니어링, 워크플로 작업을 겨냥한 xAI 모델입니다. 컨텍스트와 응답 상한, 강도 범위는 최상위 형제와 같고 다른 것은 캐시 입력 단가입니다. 긴 선두 블록을 매번 다시 보내는 루프의 비용은 바로 거기에 쌓입니다.

채팅 플레이그라운드 열기
에이전트형 소프트웨어, 엔지니어링, 긴 프롬프트를 반복하는 루프에 맞는 안정적인 메시지 흐름
모델
Grok 4.5
적합한 작업
에이전트형 소프트웨어, 엔지니어링, 긴 프롬프트를 반복하는 루프
메시지 구조
시스템 규칙 → 근거와 상태 → 이번 과제 → 출력 사양
사실의 범위
기능·제어 항목·가격은 실시간 스키마에서 옵니다

통합 원칙

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

에이전트형 소프트웨어, 엔지니어링, 긴 프롬프트를 반복하는 루프에 재현 가능한 작업 흐름 만들기

Grok 4.5는 에이전트형 소프트웨어, 엔지니어링, 워크플로 작업을 겨냥한 xAI 모델입니다. 컨텍스트와 응답 상한, 강도 범위는 최상위 형제와 같고 다른 것은 캐시 입력 단가입니다. 긴 선두 블록을 매번 다시 보내는 루프의 비용은 바로 거기에 쌓입니다.

  • 캐시되는 선두

    반복이 곧 요점

    루프가 도는 동안 요청의 앞부분을 바이트 단위로 고정해 재사용되게 하세요. usage에는 입력 중 몇 토큰이 캐시됐는지가 돌아옵니다. 적중은 측정할 결과이지 기대할 전제가 아닙니다.

  • 같은 그릇

    입력 500,000, 출력 450,000

    컨텍스트와 한 번의 응답 상한이 최상위 형제와 같아서, 거기서 통하는 메시지 구성을 그대로 옮겨도 됩니다.

  • 강도 범위

    low부터 xhigh, 기본값 high

    이 모델에는 끄는 스위치가 없습니다. 추론 토큰은 출력으로 계산되므로 강도와 함께 max_tokens 상한도 올려야 합니다.

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

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

  1. 4.5 선택

    하루에도 여러 번 도는 같은 긴 지시

    엔지니어링 에이전트, 리뷰 봇, 고정된 지시서를 입력만 바꿔 재생하는 워크플로 단계.

  2. 4.6 선택

    요청이 매번 다름

    선두 블록이 매번 바뀌면 재사용할 것이 없고, 그때는 최상위 형제가 더 맞는 거래입니다.

  3. 4.3 선택

    숙고가 전혀 필요 없는 단계도 있음

    같은 에이전트 안에서도 분배, 태깅, 추출은 none을 받는 형제 모델로 옮길 수 있습니다.

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

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

  • 고정된 지시서, 바뀌는 저장소

    엔지니어링 에이전트

    고정된 지시서, 바뀌는 저장소

    규약과 리뷰 기준, 출력 계약은 고정 블록에 두고 그 턴에 바뀐 파일만 보내세요.

  • 하나의 정책으로 도는 다단 파이프라인

    워크플로

    하나의 정책으로 도는 다단 파이프라인

    단계마다 같은 정책 선두를 재사용하고 과제 줄만 바꾸면, 모든 단계가 같은 기준으로 판단됩니다.

  • 문서화된 기준에 비춘 diff

    코드 리뷰

    문서화된 기준에 비춘 diff

    기준을 한 번 주고 그다음에 diff를 보내세요. 지적과 심각도, 그 지적이 근거로 삼은 조항을 함께 요구합니다.

  • 정해진 점검에 스크린숏 넣기

    루프 안의 시각 입력

    정해진 점검에 스크린숏 넣기

    이미지 파트는 detail이 auto, low, high입니다. 이 경로에는 file/PDF 파트가 없으므로 문서는 텍스트나 이미지로 들어와야 합니다.

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

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

  1. 고정 선두

    선두 블록은 한 번 쓰고 손대지 않기

    손댈 때마다 루프가 재사용하던 선두가 무효가 됩니다. 실행마다 다듬지 말고 의도적으로 버전을 나누세요.

  2. 가변 꼬리

    변하는 것은 전부 끝에

    과제 줄, diff, 현재 상태는 고정 블록 뒤에 항상 같은 순서로 둡니다.

  3. 도구

    도구 표면을 명시적으로 선언

    함수 정의 최대 128개와 tool_choice. 이름과 스키마도 재사용되는 선두의 일부이므로 고정해 두세요.

  4. 계측

    매 실행마다 usage 읽기

    캐시된 입력 토큰, 출력 토큰, 지연 세 가지가 루프가 설계대로 도는지 알려 줍니다.

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

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

  1. 01 · 기준선

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

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

  2. 02 · 경계

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

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

  3. 03 · 통합

    통합 API 요청을 그대로 복사

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

  4. 04 · 운영

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

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

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

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

  • 공통 사양

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

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

  • 실시간 스키마

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

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

  • 관측 가능한 수명주기

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

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

  • 이식 가능한 통합

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

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

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