Grok2API: ein Go-Gateway mit Account-Pools für Grok Build, Web und Console

Grok2APIs drei Account-Pools: Build, Web und Console im Vergleich

Grok2API ist ein Go-Gateway mit integrierter React-Admin-Konsole, das für drei Grok-Dienste getrennte Account-Pools verwaltet: Grok Build, Grok Web und Grok Console. Nach außen stellt es einheitliche OpenAI- und Anthropic-kompatible APIs bereit, sodass Standard-SDKs, Codex und Claude Code ohne eigene Anpassung dagegen arbeiten können. Im Architekturdiagramm des README trennen sich Zugriffsdomäne, Gateway-Kern, Provider-Kanäle und gemeinsame Infrastruktur.

Die drei Provider verhalten sich unterschiedlich. Grok Build authentifiziert über OAuth oder Device-OAuth und entdeckt seine Modelle pro Account, unterstützt Responses, Chat, Messages, Compact, gespeicherte Responses sowie Video für Bezahlkonten. Grok Web nutzt SSO mit einem nach Stufe gefilterten, eingebauten Modellkatalog und ergänzt Bilder samt Bildbearbeitung. Grok Console bleibt laut Tabelle zustandslos, bietet aber neben Responses, Chat und Messages auch TTS, STT und Realtime. Jeder Provider hält eigene Credentials, Quota, Health, Abkühlphasen und Modellfähigkeiten, und Wiederholungen bleiben innerhalb seiner Route.

Setup mit docker compose: config.yaml, Hex- und Base64-Geheimnis, Port 8000

Der Schnellstart arbeitet mit offiziellen Docker-Images für linux/amd64 und linux/arm64. Nach dem Klonen kopiert man config.example.yaml zu config.yaml und füllt den Secrets-Abschnitt: ein Hex-Geheimnis und ein Base64-Geheimnis werden generiert und eingetragen, dazu ein Bootstrap-Admin mit Benutzername und Passwort. Der Start folgt dem üblichen Trio docker compose pull, docker compose up und docker compose logs, die Admin-Konsole liegt danach unter http://127.0.0.1:8000.

Ein paar Hinweise des README verdienen Beachtung. SQLite-Daten und lokale Medien landen im Compose-Volume, was für den Erstkontakt reicht. Nach der ersten Anmeldung sollte man das Administrator-Passwort ändern und die bootstrapAdmin-Konfiguration aus der Datei entfernen. Und einmal gespeicherte Anmeldedaten vertragen keine Rotation des credentialEncryptionKey mehr, denn dann lassen sich die verschlüsselten Credentials nicht mehr entschlüsseln. Wer Optionen später anpasst, ändert die meisten Einstellungen in der Konsole, die sie heiß nachlädt, config.yaml bleibt bei Startwerten.

Endpunkte von /v1/responses bis /v1/videos: Routing mit Build-, Web- und Console-Präfixen

Die API-Oberfläche umfasst /v1/responses, /v1/chat/completions, /v1/messages, /v1/images/generations und /v1/images/edits sowie /v1/videos als asynchrone Jobs. Die maßgebliche Modellquelle ist laut README die Modellseite in der Konsole oder GET /v1/models, es gibt keine statische Liste im Text, weil Build-Modelle ohnehin pro Account entdeckt werden.

Öffentliche Modellnamen lassen den Provider meist weg, das Gateway wählt selbst. Wer eine Route festnageln will, nutzt Präfixe wie Build/, Web/ oder Console/ vor dem Modellnamen. Beim Failover bleibt die Auswahl auf eine Route begrenzt, und wenn eine öffentliche Modell-ID mehrere Routen bündelt, darf das Gateway bei Bedarf auf eine andere schaltbare Route ausweichen. Client-Schlüssel lassen sich einschränken, mit Modell-Allowlists sowie optionalen Grenzen für RPM, Parallelität, Ausgaben und Ablaufdatum. Gespeicherte Responses, Compact und Prompt-Cache-Affinität hängen vom gewählten Provider ab, Swagger steht nur zur Verfügung, wenn server.swaggerEnabled auf true steht.

Egress-Scope pro Provider: FlareSolverr, Proxy-Pool-Modus und kontrollierte Wiederholungen

Der ausgehende Verkehr ist nach Scope getrennt, Knoten sind an Build, Web, Console oder Web-Assets gebunden. Die Konsole akzeptiert HTTP, HTTPS, SOCKS4/4A, SOCKS5/5H und Resin, mit Import per Abonnement oder als Text und Base64, Stapelprobes, Filterung, Zuweisung und Lastverteilung. Der Fallback pro Scope lässt sich auf keine, direkte oder feste Knoten einstellen.

Zwei Details steuern das Verhalten unter Last. Der Proxy-Pool-Modus vermeidet eine globale Abkühlung, wenn ein einzelner Knoten einen Verbindungsfehler liefert. Und die Egress-Schicht wiederholt nur Verbindungsfehler, die nachweislich vor dem Absenden der Anfrage auftreten; bereits gesendete Generierungsanfragen oder Authentifizierungsfehler werden nicht erneut abgespielt. Für Web- und Console-Routen hinter Cloudflare gibt es ein FlareSolverr-Profil zur verwalteten Clearance, und als optionaler Sidecar steht ein Egress-Qualitätswächter bereit, der aktive Modellprobes ausführt.

Von SQLite zu PostgreSQL und Redis: deployment.instanceID und GROK2API_DATABASE_URL

Der Betrieb skaliert in zwei Stufen. Eine einzelne Instanz kommt mit SQLite und lokalem Speicher aus. Mehrere Instanzen verlangen PostgreSQL, Redis und ein gemeinsam genutztes Medienverzeichnis, dazu eine eindeutige deployment.instanceID pro Replikat und eine gemeinsame clusterID, damit sich die Knoten als ein Cluster verstehen.

Für die Anbindung an PostgreSQL lässt sich der Verbindungsstring über die Umgebungsvariable GROK2API_DATABASE_URL injizieren, die den Wert database.postgres.dsn aus der Datei überschreibt, was in Container-Setups den Umgang mit Secrets vereinfacht. Die Produktionscheckliste des README liest sich kurz, aber konkret: HTTPS verwenden, auth.secureCookies aktivieren, Swagger bei öffentlich erreichbaren Deployments abschalten, config.yaml sowie Datenbank- und Medienspeicher sichern und einen vorgeschalteten Reverse-Proxy setzen.

Releases bis v3.1.5 und die Haftungsgrenze unter MIT

Die Versionshistorie bewegt sich schnell, die letzten Einträge sind v3.1.3, v3.1.4 und v3.1.5, veröffentlicht am 25. August 2026. Das Projekt steht unter der MIT-Lizenz, die Nutzung, Kopie, Veränderung und Weitergabe großzügig erlaubt, aber jede Gewährleistung ablehnt. Metadaten listen rund 7500 Sterne und 2280 Forks, die Codebasis teilt sich in backend/go.mod für den Go-Teil und frontend/package.json für die React-Konsole.

Eine Grenze steht nicht in einer Tabelle, sondern im Notizblock des README: Das Projekt dient laut eigener Aussage nur technischer Forschung und dem Lernen, und wer es benutzt, muss die offiziellen Nutzungsbedingungen von Grok und lokale Gesetze einhalten, sonst trägt er allein die Folgen. Als Alternative für ein ähnliches Ziel mit anderem Zuschnitt nennt das README DEEIX-Chat, eine selbst hostbare Plattform, die Modell-Routing, Chat, Dateien, Tools, Abrechnung und Administration in einem System zusammenführt, ohne den Umweg über Web-Session-Pools.

Redaktionelles Fazit

Grok2API passt für Selbsthoster, die mehrere Grok-Konten hinter einer einzigen OpenAI- oder Anthropic-kompatiblen Schnittstelle bündeln wollen, etwa um Codex oder Claude Code gegen dieselben Endpunkte laufen zu lassen, und die bereit sind, den Egress- und Kontingent-Overhead selbst zu verwalten. Es passt nicht, wer eine offiziell unterstützte Schnittstelle erwartet, denn das README stuft das Projekt selbst als rein technisches Forschungs- und Lernobjekt ein und verweist für alles andere auf die Nutzungsbedingungen von Grok. Vor dem produktiven Start sollte man prüfen, ob nach dem Import eines Kontos GET /v1/models dessen Modelle sauber anzeigt, ob docker compose logs ohne Wiederholungsfehler bleibt und ob die config.yaml samt Datenbank und Medienspeicher in die eigene Sicherung einbezogen ist.

Offizielle Quellen

1. Official README
2. Project repository
3. Release notes