Grok 4.6

• 2026년 8월 12일, 장시간 실행 에이전트와 고난도 인터랙티브·시각 작업에 초점을 맞춘 Grok 4.6을 출시함

  • Grok 4.5를 기반으로 연구, 정보 분석, 코드베이스 전반의 작업, 아이디어를 완성도 높은 애플리케이션이나 업무 결과물로 구현하는 복잡한 다단계 작업을 더 오래 이어갈 수 있음

  • Cursor와 Grok Build에서 바로 이용 가능하며, API와 OpenRouter·Vercel·Cloudflare 같은 파트너에서도 제공됨

    • 첫 주에는 Grok Build와 Cursor의 기본 포함 사용량을 2배로 제공함

• 장시간 에이전트 작업을 뒷받침하도록 학습 기반을 강화함

  • Grok 4.5보다 보충 학습을 오래 진행했으며, 추론·고급 기술 개념을 위한 선별된 모델 생성 데이터와 고품질 엔지니어링 데이터, 개선된 옵티마이저·학습 방식을 적용함

    • Grok 4.5로 추론 강도, 에이전트 하네스, STEM·소프트웨어 엔지니어링·지식 업무 영역의 SFT trajectory를 다시 생성하고, 모델 기반 검사로 문제가 있는 trace를 걸러냄

  • 지식 업무와 일반 코딩뿐 아니라 커널 최적화, 웹 개발, CAD 등 도메인별 환경을 포함한 폭넓은 에이전트형 RL 작업으로 학습함

• 광범위한 제품 아이디어를 작동하는 첫 버전으로 구현하는 능력이 향상됨

  • 익숙하지 않은 분야를 조사하고 애플리케이션 구조와 핵심 상호작용을 구현한 뒤, 여러 차례의 피드백을 반영하며 결과물을 계속 다듬을 수 있음

    • 장시간 작업에서는 다음 단계로 넘어가기 전에 자체 테스트와 검증을 더 자주 수행함

  • 구체적인 제품 아이디어를 주면 한 번에 애플리케이션 구조와 시각 언어를 잡아 Grok 4.5보다 강한 시각·인터랙티브 프로젝트 초안을 생성하며, 상당한 수준의 결과물에서 출발해 반복 개선하는 작업에 특히 유용함

• 에이전트 코딩·지식 업무 평가에서 최전선 수준의 성능을 기록함

  • 9개 벤치마크를 합산한 Artificial Analysis Intelligence Index에서 61점으로 GPT-5.6 Sol Max와 동률을 기록함

    • 경쟁 모델 수치는 각 개발사가 공개한 시스템 카드 또는 벤치마크 리더보드에서 가져왔으며, 자체 보고 결과와 공개 결과 중 가장 높은 점수를 사용함

• 확장된 역량에 맞춰 안전장치와 평가 범위를 강화함

  • 취약점 패치, 엔지니어링 설계 주기 단축, AI 연구 지원처럼 합법적인 활용에서 유용성과 보안을 높이도록 안전 체계를 조정함

  • 출시 전에는 역대 가장 광범위한 역량·안전장치 보정 테스트를 수행했으며, 출시 후 평가와 제3자 테스트도 폭넓게 진행함

• API 가격은 입력 토큰 100만 개당 $2, 출력 토큰 100만 개당 $6부터 시작함

  • 2배 가격의 fast variant도 제공하며, API에서 Grok 4.6을 이용할 수 있음

    • API 키를 생성해 빌드를 시작하거나 API 문서를 참고해 기존 스택에 통합 가능

  • Grok Build와 Cursor를 사용할 수 있고, x.ai/build에서는 무료로 시작 가능

^{source https://x.ai/news/grok-4-6}

HN에서는 Grok 4.6이 최상위 모델 경쟁에 합류했다는 기대만큼 발표 수치를 그대로 믿기 어렵다는 경계도 두드러졌다. 여러 연구소가 짧은 간격으로 비슷한 수준의 성능 향상을 내세운 만큼, 기술 격차가 실제로 좁혀진 것인지 유리한 평가 항목만 부각한 것인지 독립 검증이 필요하다는 지적이다. 특히 시각 디자인처럼 평가가 주관적인 분야는 이전 모델이나 사람이 만든 결과물과 직접 비교해야 개선 폭을 가늠할 수 있다.

실사용 평가는 작업에 따라 갈렸다. Grok 4.5부터 답변이 빠르고 간결해 코딩 에이전트로 쓰기 좋았고, 비용까지 낮다는 경험담이 이어졌다. 보안 검토에서 예상하지 못한 공격 지점을 찾았다는 사례도 있었다. 반면 코딩 품질이 다른 최상위 모델에 못 미친다는 평가도 나왔다. 계획과 아키텍처 검토는 다른 모델에 맡기고 구현은 Grok으로 처리하거나, 낮은 비용을 활용해 자체 검토를 한 차례 더 시키는 방식이 현실적인 대안으로 제시됐다.

성능과 별개로 신뢰 문제도 선택을 갈랐다. 기본 시스템 지침이 사용자의 요청보다 앞서 정상적인 대화까지 거부할 수 있다는 우려가 제기됐고, 안전장치의 범위와 오작동 가능성도 논쟁거리가 됐다. 운영 주체와 데이터 취급을 믿기 어렵다는 반응, 머스크와 관련된 제품을 쓰지 않겠다는 태도 역시 적지 않았다. 이는 단순한 호불호보다 업무 데이터와 코드 저장소를 맡길 수 있느냐는 문제에 가깝다.

도입 여부는 벤치마크 순위만으로 정하기 어렵다. 실제 저장소에서 결과 품질과 수정 비용을 비교하고, 응답 속도와 사용량 제한, 시스템 지침과 데이터 처리 조건을 함께 확인해야 한다. 가격 우위가 재검토 비용을 상쇄하는지, 조직이 공급자에 대한 신뢰 문제를 감당할 수 있는지가 더 실질적인 판단 기준이다.