chenyme/grok2api
Grok2API fronts Grok Build, Web, and Console account pools with OpenAI- and Anthropic-compatible APIs, but its unofficial SSO routing creates terms, credential, and renewal risk.
This Go gateway separates **Grok Build, Grok Web, and Grok Console** into account pools and exposes Responses, Chat Completions, Images, asynchronous Videos, and **Anthropic Messages**. It adds quota gating, sticky sessions, failover, audit records, and an admin UI.
Treat it as infrastructure requiring explicit security ownership: retain the AES-256-GCM encryption key, rotate the bootstrap admin setup, require client API keys, use HTTPS, redact logs, and keep Swagger disabled in production. Console calls must replay full conversation and tool state.
This Go gateway separates **Grok Build, Grok Web, and Grok Console** into account pools and exposes Responses, Chat Completions, Images, asynchronous Videos, and **Anthropic Messages**. It adds quota gating, sticky sessions, failover, audit records, and an admin UI. Treat it as infrastructure requiring explicit security ownership: retain the AES-256-GCM encryption key, rotate the bootstrap admin setup, require client API keys, use HTTPS, redact logs, and keep Swagger disabled in production. Console calls must replay full conversation and tool state. It is an unofficial research project that tells users to follow Grok terms and local law. Web and Console SSO cannot auto-renew, Console supports only stateless POST Responses, and grok-4.5 is unavailable through the Console provider.
This expands gateway scope from model routing into unofficial provider emulation, account pooling, multimodal APIs, and state replay, while concentrating credential, session, logging, and terms-compliance risk in one service. Against managed gateway candidates, its operational flexibility comes with substantially more explicit security ownership and provider-specific limitations.