xAI의 Grok 플러그인 카탈로그, 책임이 아닌 커밋을 고정하다

xAI의 새 플러그인 마켓플레이스에는 한 가지 짚어볼 설계 결정이 담겨 있습니다. 모든 원격 플러그인 소스는 40자리 커밋 SHA를 고정하지만, xAI는 해당 커밋의 내용을 검토하지 않는다고 명시합니다. 카탈로그는 재현 가능하고, 신뢰 판단은 사용자 몫입니다.

Grok Build 확장 마켓플레이스란 무엇이며, 누가 사용할 수 있나요?

Grok Build 플러그인 마켓플레이스는 xAI의 터미널 코딩 에이전트인 Grok Build용 확장 기능을 모아 놓은 오픈 인터미널 카탈로그로, 2026년 6월 11일에 베타로 출시되었습니다 . 중앙화된 상업용 앱 스토어가 아닙니다. 카탈로그는 공개 GitHub 저장소 xai-org/plugin-marketplace이며, xAI가 직접 작성한 퍼스트파티 플러그인은 plugins/에, 서드파티 항목—로컬에 벤더링되거나 원격 참조 방식—은 external_plugins/에 위치합니다 . 신규 등록은 호스팅 백엔드 업로드가 아닌 풀 리퀘스트 방식으로 이루어집니다.

한줄 요약: Grok Build 플러그인 마켓플레이스는 xAI 터미널 코딩 에이전트용 설치형 확장 기능을 PR 방식으로 관리하는 GitHub 카탈로그(xai-org/plugin-marketplace)로, 2026년 6월 11일 베타 출시되었습니다. CLI는 SuperGrok 또는 X Premium+ 구독이 있어야 사용할 수 있지만, 기반 모델은 API 키로 직접 접근할 수도 있습니다.

접근 경로는 두 가지입니다. CLI는 curl -fsSL https://x.ai/cli/install.sh | bash로 설치하며, SuperGrok 구독 또는 X Premium+ 멤버십이 필요합니다 . 이면의 모델인 grok-build-0.1(별칭 grok-code-fast-1)은 컨텍스트 256,000토큰의 코딩 모델로, 입력 100만 토큰당 $1.00, 출력 100만 토큰당 $2.00, 캐시 입력은 $0.20입니다 . 이 모델은 구독 없이 API 키만으로도 직접 접근할 수 있어, 대화형 CLI 티어가 적용되지 않는 환경에서도 팀이 스크립트로 활용할 수 있습니다.

자동화 관점에서 Grok Build는 사람 없이도 실행되도록 설계되어 있습니다. 헤드리스 모드는 단발 프롬프트용 grok -p, plain·json·streaming-json을 지원하는 --output-format, 그리고 신뢰된 파이프라인에서 권한 게이트를 건너뛰는 --always-approve를 제공합니다 . 오케스트레이터는 grok agent stdio로 임베딩할 수 있으며, 이는 JSON-RPC 위에서 Agent Client Protocol 에이전트를 제공하고 캐시된 로그인 또는 XAI_API_KEY로 인증합니다 .

이 가이드 전체에서 유의해야 할 점이 있습니다. 마켓플레이스는 명시적으로 베타 상태이므로 스키마, 명령어, 접근 티어가 아직 변경될 수 있습니다 . 여기서 다루는 구체적인 내용은 2026년 6월 중순 기준 스냅샷으로, 확정된 사양이 아님을 감안하세요.

Grok Build 플러그인 구조 — 스킬, 훅, 그리고 번들 구성 요소

Grok Build의 확장 모델은 스킬, 훅, 플러그인이라는 세 가지 기본 단위가 서로 중첩되는 구조로 이루어져 있습니다. 스킬은 가장 작은 단위로, 마크다운 지시사항·스크립트·리소스의 재사용 가능한 폴더이며, 사용자가 직접 호출할 수 있는 스킬은 /<skill-name> 형식의 슬래시 커맨드로도 노출됩니다 . 훅은 툴 호출 전후 또는 세션 이벤트 시점에 실행되는 라이프사이클 스크립트입니다. 플러그인은 이들을 하나로 묶는 번들입니다. 단일 설치로 스킬, 슬래시 커맨드, 서브에이전트(Agent) 정의, 훅, MCP 서버, LSP(언어 서버) 설정을 한 이름 아래 모두 제공할 수 있습니다 .

이 번들링이 핵심입니다. MCP 서버 등록, 스킬 폴더 추가, 언어 서버 설정, 서브에이전트 선언을 각각 따로 연결할 필요 없이, grok plugin install <name> --trust 한 번으로 전체 구성을 한 번에 가져올 수 있습니다 . 플러그인이 배포 단위이고, 앞서 설명한 기본 요소들이 그 구성 요소입니다.

검색은 고정된 위치 순서를 따르므로 스킬이나 플러그인의 어떤 버전이 실제로 로드될지 예측할 수 있습니다.

• 프로젝트 경로 — ./.grok/skills/와 ./.grok/plugins/, 현재 작업 중인 저장소 범위에 한정.
• 사용자 경로 — ~/.grok/..., 모든 프로젝트에 공통 적용.
• 마켓플레이스 설치 — ~/.grok/plugins/marketplaces/ 하위에 벤더링.
• 추가로 설정된 경로, 그리고 --plugin-dir CLI 플래그로 명시적으로 전달된 경로.

마켓플레이스 소스는 ~/.grok/config.toml의 [[marketplace.sources]] 블록으로 선언하며, ~/.grok/plugins/known_marketplaces.json이 이를 뒷받침합니다 . 이 레이어 구조 덕분에 프로젝트 로컬 스킬이 사용자 레벨이나 마켓플레이스 스킬을 덮어쓸 수 있어 특정 저장소를 특정 동작으로 고정하기에 유용하지만, 슬래시 커맨드가 예상과 다른 것으로 해석될 때를 대비해 인지하고 있어야 합니다.

훅은 환경 변수를 통해 컨텍스트를 전달받으며, 이를 통해 라이프사이클 스크립트는 자신이 어느 환경에서 실행되는지 알 수 있습니다. 모든 훅은 GROK_HOOK_EVENT, GROK_HOOK_NAME, GROK_SESSION_ID, GROK_WORKSPACE_ROOT를 수신합니다. 플러그인에 포함된 훅은 추가로 GROK_PLUGIN_ROOT와 GROK_PLUGIN_DATA도 받으므로, 플러그인 번들 스크립트가 경로를 추측하지 않고 자체 파일과 영속 상태를 정확히 찾을 수 있습니다 . 프로젝트 훅은 실행 전 명시적인 신뢰 승인이 필요합니다. 훅은 툴 호출 전후에 임의 코드를 실행하므로 이 게이트는 중요합니다 .

구조는 아직 정착 중입니다. 2026년 6월 15일자 v0.2.52 변경 로그에서는 플러그인 스킬 로딩, 플러그인-MCP 인증, 그리고 스킬·MCP 서버·커맨드가 표시되지 않던 마켓플레이스 목록 문제를 수정했습니다 . 여기서 설명하는 패키징 메커니즘은 2026년 6월 중순 기준 스냅샷이며, 확정된 인터페이스가 아님을 상기시켜 줍니다.

현재 Grok Build 카탈로그에는 어떤 플러그인이 있나요?

출시 마켓플레이스는 6개의 파트너 플러그인으로 문을 열었으며, 6개 모두 실제 소프트웨어 작업의 인프라 레이어를 겨냥합니다 — 범용 채팅 도우미는 하나도 없습니다 . 코딩 에이전트가 실제로 다루는 데이터베이스, 배포, 에러 추적, 브라우저, 엣지 런타임을 아우릅니다. MongoDB는 데이터 탐색과 쿼리 작업, Vercel은 배포 관리, Sentry는 프로덕션 디버깅, Chrome DevTools는 라이브 브라우저 제어, Cloudflare는 Workers와 Durable Objects, Superpowers는 인기 에이전틱 워크플로우 번들을 제공합니다 .

인프라에 편중된 구성은 의도적입니다. 공식 플러그인 세트는 LLM이 대화할 수 있는 기능의 데모라기보다, 에이전트가 실제로 문제를 일으키는 영역 — 잘못된 쿼리, 실패한 배포, 잡히지 않은 예외, 불안정한 네트워크 호출 — 을 그대로 보여줍니다. xAI 공식 제품 페이지에는 출시 6개와 함께 서드파티 및 프로젝트 목록도 표시되는데, browser-review v0.8.2, github-flow v2.1.0, xai-code-review v1.0.0 같은 커뮤니티 항목과 프로젝트 플러그인 team-tool도 포함됩니다 . 버전 번호를 보면 이것들이 고정된 벤더 번들이 아닌 독립적으로 유지보수되는 패키지임을 알 수 있습니다.

터미널에서 보이는 카탈로그는 지금 이 순간에도 내부적으로 수정 중입니다. 2026년 6월 15일 v0.2.52 체인지로그에는 TUI에서 스킬, MCP 서버, 슬래시 명령어가 올바르게 표시되지 않던 마켓플레이스 목록 오류 수정이 포함됐으며, 플러그인 설치 제안, 플러그인 스킬 로딩, 플러그인-MCP 인증 문제도 함께 수정됐습니다 . 다시 말해, 출시 4일 후에도 xAI는 목록에 등재된 플러그인의 컴포넌트가 렌더링되는지 여부를 긴급 패치하고 있었습니다. 카탈로그를 평가하는 개발자 입장에서 보면, 파트너 목록은 탄탄하고 인프라 중심이지만 그 주변 탐색 환경은 워낙 빠르게 변해서 지난주에 본 것과 오늘 로드되는 것이 다를 수 있습니다.

이 중 어느 것도 설치 방식을 바꾸지는 않습니다 — 모든 원격 소스는 여전히 전체 커밋 SHA를 고정하고 명시적인 신뢰 단계를 거쳐 설치됩니다 . 하지만 기대치를 조정해 줍니다. 카탈로그는 엄선된 스토어가 아닌 실시간 베타 수준의 디렉터리이며, 그 내용은 주변 도구들이 수정되는 속도만큼 빠르게 서드파티 제출을 통해 확장되고 있습니다.

Grok Build는 다른 런타임용으로 작성된 확장을 인식하나요?

그렇습니다 — Grok Build는 Claude Code 및 AGENTS.md 에코시스템용으로 제작된 확장을 별도 설정 없이 읽어들이므로, 기존 라이브러리가 그대로 로드됩니다. xAI의 스킬, 플러그인, 마켓플레이스 문서에 따르면, CLI는 Claude Code 마켓플레이스, 플러그인, 스킬, MCP, 에이전트, 훅, CLAUDE.md와 .claude/rules를 포함한 명령 파일을 직접 수집합니다 . 이는 임포트 마법사가 아닌 의도적인 호환성 선택입니다. 이미 다른 에이전트 런타임을 위해 관리하고 있는 동일한 아티팩트가 시작 시 그대로 인식됩니다.

지원 범위는 Anthropic의 관례를 넘어섭니다. Grok Build는 AGENTS.md 계열 — AGENTS.md, Agents.md, AGENT.md — 과 사용자 수준의 ~/.agents/skills 및 ~/.agents/commands도 읽습니다 . 실질적으로 이는 팀이 이미 에이전트 컨텍스트와 재사용 가능한 명령을 인코딩하는 가장 널리 채택된 두 가지 방식을 포괄하므로, 검색 범위는 폐쇄된 생태계가 아닌 Grok 자체의 ./.grok/ 및 ~/.grok/ 경로의 상위 집합입니다.

전략적 의미는 명확합니다. xAI는 Grok Build를 재작성을 요구하는 백지 플랫폼이 아닌, 기존 확장 라이브러리와 호환되는 런타임으로 포지셔닝하고 있습니다. 크로스 툴 지원은 Claude Code나 AGENTS.md 관례에 이미 투자한 팀의 전환 비용을 낮춥니다 . 이 프레이밍은 도입을 고려할 때 중요합니다 — 직접 동기화해야 하는 병렬 툴체인에 투자하는 것이 아니라, 이미 작성한 기능의 대안 실행기를 평가하는 것입니다.

평가 측면에서 시사점은 구체적입니다. 팀의 기존 확장 디렉터리를 Grok Build에 지정하고 바로 실행할 수 있습니다 — 작성해야 할 마이그레이션 스크립트도, 스키마 변환 단계도, 스킬·훅·MCP 서버의 병렬 재구성도 필요하지 않습니다. 어떤 결정을 내리기 전에 현재의 CLAUDE.md 규칙과 슬래시 명령어가 grok-build-0.1에서도 동일하게 동작하는지 테스트할 수 있습니다 .

카탈로그 전체에 해당하는 한 가지 주의 사항이 있습니다. 호환성은 검색과 로딩을 관장하며 출처는 보장하지 않습니다. 확장이 Claude Code용으로 작성됐든 Grok Build용으로 작성됐든, xAI는 여전히 서드파티 코드를 작성하거나 제어하거나 검증하지 않습니다 . 따라서 기존 라이브러리를 재사용한다고 해서 직접 수행하지 않은 검증이 이전되지는 않습니다.

Grok Build 카탈로그 플러그인, 누가 검수하고 누가 안 하나?

xAI에서는 설치하는 플러그인을 검수하지 않습니다. Grok Build 카탈로그는 SHA 핀닝을 통해 무결성을 보장하지만, 의도에 대해서는 아무런 보증도 하지 않습니다. xAI는 "제3자 플러그인을 저작·통제·검증하지 않으며" 해당 플러그인은 있는 그대로(AS-IS) 제공된다고 명시합니다 . 실질적인 결론은, grok plugin install을 실행하는 개발자가 모든 검수 책임을 진다는 것입니다. 마켓플레이스는 배포 수단일 뿐, 보안 심사 기관이 아닙니다.

SHA 핀닝은 유일하게 강력히 보장되는 항목입니다. 카탈로그 항목의 원격(url) 소스에는 40자 소문자 커밋 SHA 전체를 반드시 제공해야 하며, Grok Build는 설치 시 클론 이후 이를 재검증합니다 . 이 핀은 두 가지 실질적 효과를 발휘합니다. 강제 푸시를 통한 무단 코드 주입을 차단하며(업스트림 작성자가 태그나 브랜치 내용을 몰래 교체할 수 없음), 설치를 재현 가능하게 만들어 줍니다 — 오늘 감사한 바이트가 내일 설치되는 바이트와 동일합니다 .

SHA 핀닝이 알려주지 않는 것은 해당 커밋의 코드가 안전한지 여부입니다. 핀으로 고정된 SHA도 악의적이거나, 과도한 권한을 요구하거나, 환경에 맞지 않는 플러그인을 가리킬 수 있습니다. 핀닝은 카탈로그가 광고한 정확한 커밋을 받았음을 검증할 뿐, 그 커밋이 신뢰할 만하다는 것을 보장하지는 않습니다. 시크릿을 유출하는 훅이나 파일시스템에 광범위하게 접근하는 MCP 서버도, 무해한 플러그인과 똑같이 재현 가능하게 설치됩니다.

"xAI는 제3자 플러그인을 저작·통제·검증하지 않습니다" — xAI, Grok Build 플러그인 마켓플레이스 문서 (source: xai-org/plugin-marketplace).

실행 전에 거치는 추가 관문이 두 개 있지만, 두 가지 모두 심사가 아닌 동의 확인 절차입니다. 설치에는 명시적인 --trust 단계가 필요하고, 프로젝트 수준 훅은 실행되기 전에 별도의 /hooks-trust 모달을 통과해야 합니다 . 이 절차가 존재하는 이유는 플러그인이 워크스페이스 접근 권한으로 실행되는 훅·서브에이전트·MCP 서버를 번들링할 수 있기 때문입니다. 플러그인 훅은 GROK_PLUGIN_ROOT와 GROK_PLUGIN_DATA를 수신하며, 모든 도구 호출 전후로 실행될 수 있습니다 .

어떤 관문도 소스 코드를 직접 읽는 것을 대체할 수 없습니다. 카탈로그는 PR 기반·코드 오너 검토 방식을 채택하고 있으나, 보안 인증·패키지 서명·제출 순위 정책은 존재하지 않습니다 . 따라서 어떤 팀이든 현실적인 워크플로는 플러그인의 훅과 MCP 정의를 읽고, SHA가 검토한 것과 일치하는지 확인한 뒤, --trust로 설치하는 것입니다 — 반드시 이 순서대로.

공개 카탈로그에 플러그인을 등록하는 방법

Grok Build 카탈로그에 게시하는 것은 xai-org/plugin-marketplace 저장소에 대한 Git 풀 리퀘스트 워크플로입니다. 업로드 폼, 검토 대시보드, 승인 대기열은 없습니다. 플러그인을 두 디렉토리 중 하나에 배치하고, 카탈로그 항목을 추가하고, 인덱스를 재생성하고, 로컬에서 검증한 뒤, 코드 오너의 승인이 필요한 PR을 열면 됩니다 [2].

디렉토리 선택이 출처를 나타냅니다. xAI가 직접 작성·벤더링한 퍼스트파티 플러그인은 plugins/ 아래에, 나머지는 모두 external_plugins/에 위치합니다(로컬 벤더링 또는 원격 소스 참조) [2]. 카탈로그 항목 자체는 .grok-plugin/marketplace.json에 위치합니다. 필수 필드는 name(케밥 케이스)과 source 두 개이며, 나머지는 선택적 메타데이터입니다: description, category, homepage, keywords, domains, version, author, tags [2][4]. 원격 url 소스는 SHA 전체를 핀으로 고정해야 하며, 이는 모든 설치에 적용되는 동일한 제약입니다.

PR 전에 두 가지 스크립트를 반드시 실행해야 합니다. 컴포넌트 인덱스를 재생성한 뒤 카탈로그를 검증하세요:

python3 scripts/generate-plugin-index.py
python3 scripts/validate-catalog.py

하나라도 건너뛰면 검토자가 PR을 반려합니다. 두 스크립트가 모두 통과하면 PR을 엽니다. 머지에는 코드 오너 검토가 필요합니다 [2]. 해당 검토가 유일한 관문입니다. xAI는 베타 기간 중 제출 SLA, 순위·순서 정책, 보안 인증을 명시하지 않으므로, 머지 일정은 정해져 있지 않으며 유지관리자의 처리 속도에 달려 있습니다 — 제출 물량이 늘어날수록 검증되지 않은 병목이 될 수 있습니다 [2][7].

공개 카탈로그를 반드시 사용할 필요는 없습니다. Git 저장소라면 무엇이든 ~/.grok/config.toml에 [[marketplace.sources]] 블록을 추가해 프라이빗 마켓플레이스 소스로 활용할 수 있습니다 [3]. 독점적이거나 내부용 플러그인이라면 이 경로가 맞습니다. 팀이 자체 저장소에서 셀프 호스팅하고, 원하는 대상에게만 설치 접근권을 공유하며, PR 검토와 공개 노출을 모두 건너뛸 수 있습니다. 결국 배포 범위와 제어 권한 사이의 선택입니다 — 검색 가능성을 원하면 xai-org/plugin-marketplace에 제출하고, 플러그인을 조직 내부에 두고 싶다면 셀프 호스팅을 선택하세요.

지금 팀에 Grok Build 플러그인 확장을 도입해야 할까요?

SuperGrok 구독 또는 X Premium+ 멤버십을 보유하고 있고 MongoDB, Vercel, Sentry, Cloudflare 중 하나를 이미 프로덕션에서 운영 중이라면 지금 바로 도입할 것을 권장합니다 — 6개 출시 파트너 플러그인이 커스텀 MCP 서버를 처음부터 구축하지 않아도 에이전트 기반 인프라 워크플로를 제공합니다 . 스키마 안정성이 필수 조건이라면 대기하세요: 명령어, 매니페스트 필드, 접근 등급 모두 명시적으로 베타 상태이며, v0.2.52도 2026년 6월 15일 현재 마켓플레이스 목록 및 플러그인 설치 회귀 문제를 패치 중이었습니다 .

xAI 런타임에 먼저 커밋하지 않아도 되는 저위험 평가 경로가 있습니다. Grok Build는 Claude Code 마켓플레이스, 플러그인, 스킬, MCP, 에이전트, 훅, CLAUDE.md와 .claude/rules 같은 명령 파일을 별도 설정 없이 읽으며, AGENTS.md 계열과 사용자 수준의 ~/.agents/skills도 지원합니다 . 따라서 배포 모델을 변경하기 전에 기존 확장 라이브러리를 Grok Build에 연결해 현재 에이전트와 벤치마크해볼 수 있습니다.

공유 배포 전에 테스트 환경에서 엔터프라이즈 제어 항목을 감사하세요. xAI는 requirements.toml을 재정의 불가능한 정책 레이어(~/.grok/와 /etc/grok/ 모두)로 문서화하고 있으며, off·workspace·devbox·read-only·strict의 5가지 샌드박스 프로필을 Linux에서는 Landlock, macOS에서는 Seatbelt로 지원합니다. 또한 Bash, Edit, Read, Grep, MCPTool, WebFetch에 대한 권한 규칙과 배포 전체에서 bypass-permissions 모드를 비활성화하는 옵션도 제공합니다 . read-only 및 strict 모드의 자식 프로세스 네트워크 차단은 Linux 전용이므로 — macOS 개발자 환경에서 해당 공백이 문제가 되는지 미리 확인하세요.

핵심 결론: Grok Build 플러그인 확장은 강력한 크로스 런타임 호환성을 갖춘 설정 가능한 팀 배포 레이어로 보되, 검증된 공개 앱 스토어로 취급하지 마세요. 이번 분기에 기존 Claude Code 또는 AGENTS.md 라이브러리를 대상으로 파일럿을 진행하고, 모든 원격 소스를 40자 커밋 SHA로 고정하며, xAI가 패키지 서명 및 검토 처리량 모델을 공개하기 전까지 독점 플러그인은 자체 호스팅으로 유지하세요 .

자주 묻는 질문

Grok Build 플러그인이란 무엇이며, 스킬과 어떻게 다른가요?

스킬은 마크다운 명령, 스크립트, 리소스로 구성된 단일 목적의 폴더로, 사용자가 호출 가능한 스킬은 하나의 슬래시 명령(/<skill-name>)으로 노출됩니다. 플러그인은 이러한 기본 요소들을 묶는 패키지 추상화로, 여러 스킬·슬래시 명령·서브에이전트(Agent) 정의·훅·MCP 서버·LSP 설정을 하나의 설치 단위로 번들합니다 . 요약하면, 스킬은 단일 기능이고 플러그인은 여러 기능을 하나로 묶어 각각 개별 설정하지 않고 한 번에 설치할 수 있게 합니다.

Grok Build는 Claude Code 확장 및 AGENTS.md 규칙과 호환되나요?

네. Grok Build는 Claude Code 마켓플레이스, 플러그인, 스킬, MCP, 훅, 에이전트 정의는 물론 CLAUDE.md와 .claude/rules 같은 명령 파일도 별도 설정 없이 읽습니다. AGENTS.md 계열(AGENTS.md, Agents.md, AGENT.md)과 사용자 수준의 ~/.agents/skills, ~/.agents/commands도 지원합니다 . 이는 기존 에이전트 확장과 호환되는 런타임으로 작동함을 의미하며, 해당 규칙을 이미 사용 중인 팀의 전환 비용을 낮춥니다.

서드파티 Grok Build 플러그인 설치는 얼마나 안전한가요?

모든 원격(url) 소스는 40자 소문자 커밋 SHA를 전체 지정해야 하며, Grok Build는 설치 시 클론 후 이를 재검증합니다 — 이는 강제 푸시를 통한 무음 코드 삽입을 방지하고 설치를 재현 가능하게 합니다 . 단, SHA 고정은 해당 커밋 시점에 게시된 코드와 일치함을 보장할 뿐이며, xAI는 서드파티 플러그인을 "작성, 통제, 검증하지 않으며" AS-IS로 제공된다고 명시합니다 . 공유 또는 프로덕션 환경에서 실행하기 전에 플러그인 소스를 직접 읽고 --trust를 통해 프로젝트 훅을 제어하세요.

독점 팀 확장을 위한 Grok Build 마켓플레이스를 자체 호스팅할 수 있나요?

네. ~/.grok/config.toml에서 [[marketplace.sources]]를 설정해(~/.grok/plugins/known_marketplaces.json과 함께) 직접 관리하는 임의의 git 저장소를 지정할 수 있습니다 . 탐색, TUI 마켓플레이스 탭(/marketplace 또는 /plugins), grok plugin install <name> --trust 같은 설치 명령 모두 동일하게 작동하며, 공개 xai-org/plugin-marketplace GitHub 카탈로그에 의존하지 않습니다. 내부 플러그인을 비공개로 유지하려면 이 방법을 권장합니다.

Grok Build 접근 등급은 무엇을 포함하며, API 대안이 있나요?

Grok Build CLI는 SuperGrok 구독 또는 X Premium+ 멤버십이 필요합니다 . 기반 모델인 grok-build-0.1(별칭 grok-code-fast-1)은 256,000토큰 컨텍스트를 지원하며 API 키로도 접근 가능합니다 — 입력 1M 토큰당 $1.00, 캐시 입력 $0.20, 출력 1M 토큰당 $2.00입니다 . 즉, 소비자 구독 없이도 헤드리스 또는 프로그래밍 방식으로 모델을 직접 활용할 수 있으나, 플러그인 및 마켓플레이스 도구는 제한된 CLI에서만 제공됩니다.