Account pooling is the reason to consider it
Grok2API brings Grok Build, Grok Web, and Grok Console accounts behind one gateway. The README describes a Go backend, a React admin console, and OpenAI-compatible and Anthropic-compatible APIs. Its value for an operator is centralized account selection and client access, provided the required routes work with the connected accounts.
The documented capabilities include Responses, Chat Completions, Anthropic Messages, images, asynchronous video, and provider-specific voice routes. These are repository claims, not results from our sandbox. Compatibility with Codex or Claude Code still needs verification against the workflow you intend to run.
Provider choice matters. The README says Build uses OAuth and discovers models per account, while Web and Console use SSO and built-in catalogs. It also says credentials, quotas, health, cooldowns, concurrency, and capabilities remain separate. Build does not expose image generation or editing routes. Check the serviceable results from GET /v1/models rather than assuming every account supports every advertised capability.
What our recorded run establishes
Our stored run began on August 24, 2026, at 15:45:04.634 UTC, using commit 6463c6a3910cf120d37ff81c63d079ce619127f1, with the detected Go project under backend/. The recorded configuration was 3 CPUs, 8 GB of memory, and image golang:1.24-bookworm. The checkout metrics were 611 files, approximately 189,514 source lines, and 9 MB. These describe that checkout, not the current repository.
The install stage exited 0 in 40.780 seconds, rounded to 41 seconds. Its retained output says go: downloading go1.26.0 (linux/amd64). The image label therefore cannot establish the actual toolchain used throughout the run. The parser's dependency count was 237; the record does not verify that 237 packages were installed or security-scanned.
The build-labelled stage exited 0 in 98.899 seconds, rounded to 99 seconds. Its retained output is vet-exit:0. The stage status alone does not establish that a gateway binary was compiled, installed, or started. The available record lacks the full command and artifact checks needed to confirm those outcomes.
The test command exited 1 in 894.476 seconds, rounded to 894 seconds. The parser recorded 113 package successes, 8 package failures, and 11 packages without tests. Its total field of 121 must not be presented as an exhaustive count of individual tests: unique coverage and the complete log were not reconciled. Packages without tests are not failed tests.
The retained tail explicitly names failures in internal/application/gateway, internal/application/media, and internal/infra/persistence/relational, each after roughly 360 seconds. It also contains successful package results and routing-snapshot warnings. It does not identify all eight reported failures or establish why they occurred. Similar durations do not prove a timeout cause, and the overall command was not marked timed out.
No installed-binary check, live Grok request, media workload, throughput benchmark, or security audit is established by this record. Successful command stages cannot substitute for those checks.
Setup continues after source commands
The README's quick start uses Docker Compose and documents images for linux/amd64 and linux/arm64. It asks operators to copy config.example.yaml, generate JWT and credential-encryption secrets, and set a bootstrap administrator password. The documented service address is http://127.0.0.1:8000.
After sign-in, the documented sequence is to connect a provider account, wait for quota and capability synchronization, inspect model routes, create a client key, and call an endpoint. These are instructions for a deployment, not steps our recorded run completed. The README also tells operators to change the administrator password and remove bootstrapAdmin after first sign-in.
Credential custody is a continuing responsibility. The README warns against rotating credentialEncryptionKey after credentials have been stored. It also warns that Build refresh tokens may rotate and should not be actively shared among independent clients. Its backup checklist includes configuration, database, and media storage. Plan those responsibilities before importing accounts.
A single instance is documented with SQLite, memory, and local media. Multiple instances require PostgreSQL, Redis, and a shared read/write media directory, along with replica and cluster configuration. Reverse-proxy deployments also need explicit proxy trust settings. These deployment claims were not validated in our sandbox.
A spending limit has documented exceptions
The README says client keys support model allowlists and optional request-rate, concurrency, spending, and expiry limits. It also describes important limits to monetary accounting.
Speech-to-text duration is known only after a successful response completes, so concurrent requests may briefly exceed a key's spending limit. Realtime, video edits or extensions, and custom routes without a recognized official price are documented as unpriced: they remain callable and do not consume the spending limit.
If your decision depends on a universal cost ceiling, those exceptions matter more than the presence of a billing dashboard. Verify which routes your users can call and how each is accounted for. Our run did not measure billing enforcement or costs.
Read historical reports in their proper scope
Release v3.1.5 is a separate reference from our August 24 checkout. Its notes list compatibility fixes for streams, response fields, video input, cooldowns, quota reconciliation, and provider prefixes. We did not run that release, and the supplied release page does not establish that it is the latest version.
Issue #1011 reports Web image requests returning upstream_unavailable on v3.1.5. It was opened on August 27, 2026, and closed as completed on September 2. Issue #993 concerns Console behavior on v3.1.4 and was closed as not planned on September 11 after being marked stale. These reports describe users' experiences with those versions. Closure alone does not verify a fix, and neither report establishes a current general defect or explains our sandbox failures.
The supplied repository API snapshot reports 7,853 stars, 24 open issues and pull requests combined, and a last push on October 22, 2026. Those are attention and activity signals. They do not measure adoption, support responsiveness, compatibility, or reliability.
How to use the ratings
These are editorial evidence ratings, not benchmark results. The scale is 1 for little supporting evidence, 2 for partial evidence with major unknowns, 3 for a documented path with meaningful verification gaps, 4 for detailed supporting material with limited practical validation, and 5 for strong documentation plus relevant independent validation. Each category considers its own evidence; unknown adoption or compatibility earns no extra credit.
Setup receives 3/5 because the README describes the deployment sequence, but our command record does not verify a running gateway. Documentation receives 4/5 for its concrete account, deployment, proxy, and billing instructions, with practical validation still missing. Community receives 2/5 because repository attention and issue activity are visible, while adoption and support quality remain unmeasured. Maturity receives 2/5 because release history is visible but live operation is unverified and the historical test-command failure remains unexplained.
Choose by the service you need
LiteLLM's README distinguishes its deployable AI Gateway from its Python SDK. Consider the gateway when the requirement is a central service across multiple model providers. One API documents provider channels, load balancing, and token restrictions; consider it for that channel-management workflow. Neither alternative was tested in our run.
For Grok2API, the useful next step is a controlled deployment check: confirm the binary and startup path, connect an account you are authorized to use, inspect available routes, and exercise the client and billing paths you need. Investigate the named historical package failures with complete output before drawing conclusions about their cause. Review the project's research-purpose notice and Grok terms separately from technical compatibility.