Grok Build, Grok Web, Grok Console을 하나의 API로 묶는다는 말은 간단해 보입니다. 하지만 chenyme/grok2api의 설계는 요청을 전달하는 프록시보다 계정과 출구를 관리하는 게이트웨이에 가깝습니다. Go 백엔드와 React 관리자 콘솔을 중심에 두고, Provider Registry가 세 서비스의 서로 다른 인증·모델·미디어 경로를 나눕니다.
Build는 OAuth 또는 Device OAuth를 사용하고 계정별로 모델을 발견합니다. Web은 SSO와 원격 quota를 전제로 이미지, 이미지 편집, 영상까지 다룹니다. Console 역시 SSO를 쓰지만 stateless Responses·Chat·Messages 흐름을 중심으로 둡니다. 같은 “Grok”이라는 이름 아래에 있어도 계정 상태와 기능 표면이 같지 않다는 전제입니다.
그래서 Provider마다 credential, quota, health, cooldown, concurrency, model capability를 독립적으로 보관합니다. 각 Provider에는 별도의 isolated egress scope도 붙습니다. HTTP/SOCKS/Resin, proxy pool, probe, allocation, fallback, FlareSolverr를 Egress Manager에서 다루고, Gateway는 선택된 Provider로 요청을 보냅니다.
실패 처리의 선도 분명합니다. sticky session, quota/concurrency guard, bounded failover는 선택된 Provider 내부에서만 작동합니다. Build 계정의 quota가 부족하다고 Web로 조용히 바꾸지 않는 방식입니다. 이 선택은 자동 복구의 범위를 좁히지만, 서로 다른 인증 정책과 모델 조건이 한 요청 흐름에서 섞이는 일도 줄입니다. 운영자 입장에서는 편의성보다 추적 가능성을 얻는 대신, 어떤 Provider를 선택할지와 모델 노출 상태를 더 신중하게 관리해야 합니다.
이 게이트웨이는 Responses, Chat Completions, Anthropic Messages, 이미지, 비동기 영상 API를 제공하고 Codex, Claude Code, OpenAI·Anthropic 호환 SDK를 연결 대상으로 둡니다. 요청이 끝나면 사용량, 감사, client billing을 확정하고, 저장 응답·compact·prompt-cache affinity·reasoning replay 같은 세션 기능도 선택적으로 운용합니다. API 표면은 통일하지만 내부의 계정 풀과 egress 풀은 통일하지 않는 셈입니다.
README는 공식 이미지가 linux/amd64와 linux/arm64를 지원한다고 적고, 프로젝트 목적을 기술 연구와 학습으로 한정합니다. Grok 공식 약관과 현지 법률을 따라야 한다는 주의도 포함합니다. 실제 배포라면 인증정보 보관, 계정 정책, 프록시 사용 조건, quota 고갈 시의 동작을 먼저 검증해야 합니다. 이 저장소가 던지는 질문은 “Grok을 API로 쓸 수 있나”보다 “API 뒤에서 계정과 네트워크 경계를 얼마나 정확히 유지할 수 있나”에 가깝습니다.