Grok 프로바이더
왜 목록에 있는가
섹션 제목: “왜 목록에 있는가”가장 큰 경쟁 JetBrains 플러그인 zhukunpenglinyutong/jetbrains-cc-gui(star 5,315)는 ai-bridge/channels/ 아래에 여섯 개의 CLI 채널 — claude, codex, grok, kimi, opencode, pi — 을 붙였지만 그 사이에 공통 계약이 없습니다.
Grok은 그 여섯 중 하나입니다. 이 라이브러리가 지원을 계획하는 프로바이더 목록은 그 집합에서 나왔습니다. 어느 CLI가 중요한지에 대한 추측이 아니라, 사람들이 플러그인에서 실제로 구동하기를 원한 CLI가 무엇인지에 대한 근거이기 때문입니다.
알려진 것
섹션 제목: “알려진 것”여섯 채널 중 하나라는 사실, 그 이상은 없습니다.
조사는 두 채널의 send 파라미터를 상세히 기록했지만 — Claude의 sessionId·disableThinking·agentPrompt에 대해 Codex의 threadId·baseUrl·apiKey·serviceTier — Grok은 그중에 없었습니다.
알려지지 않은 것
섹션 제목: “알려지지 않은 것”그 밖의 전부입니다. 아직 조사되지 않았습니다.
- 커맨드 이름과 대화를 식별하는 방식.
- 어느 플래그가 이것을 제어 가능한 양방향 스트림으로 만드는지.
- 출력이
type판별자를 가진 NDJSON인지. 그렇다면EventParser가 그대로 동작합니다. - 권한 어휘, 그리고
PermissionMode가 그것을 표현할 수 있는지. auth와mcp서브커맨드가 있는지, 그리고 어떤 형태로인지.
여기서 조사를 대신하는 추론은 제시하지 않습니다. 이 CLI를 붙일 때, 사실은 그것을 실행하는 데서 나올 것입니다.
붙였을 때 기여할 것
섹션 제목: “붙였을 때 기여할 것”AbstractAdapter는 멤버 다섯 개이며, 두 번째 어댑터가 질문을 던지기 전까지 그대로입니다. 두 번째로 도착하는 CLI가 형태를 결정하고, 그 이후의 것들이 그 형태가 단일한 한 쌍에 맞춰진 것이 아님을 확인해 줍니다.
이식 순서는 프로바이더마다 달라지지 않습니다.
- CLI의 실제 동작에 맞춰 어댑터를 정확히 이식한다.
- 기존 계약을 우회해야 했던 모든 지점을 기록한다.
- 공통 형태를 추출한다.
- 그 뒤에야
AbstractAdapter를 넓힌다.
다음으로 볼 것
섹션 제목: “다음으로 볼 것”- 프로바이더 작성하기 — CLI를 붙인다는 것이 무슨 일인지.
- Codex 프로바이더 — 계획된 프로바이더 중 가장 많은 것이 확립된 것.
- 로드맵 — 작업 순서상 이것의 위치.