Grok2API : une passerelle multi-comptes pour Grok Build, Web et Console

Le projet et ses trois pools de comptes

Grok2API est une passerelle Go avec une console d'administration React intégrée. Elle gère des pools de comptes indépendants pour Grok Build, Grok Web et Grok Console, et expose des API unifiées compatibles OpenAI et Anthropic. L'aperçu du README le décrit comme une passerelle API multi-comptes pour ces trois services. Le diagramme d'architecture sépare les domaines d'accès, de noyau, de canal fournisseur et d'infrastructure partagée. La passerelle route les requêtes via un registre de fournisseurs, et la synchronisation des comptes actualise les identifiants, les quotas et les modèles. L'utilisation, les audits et la facturation client sont finalisés après chaque requête.

Comment les domaines sont séparés

Le diagramme d'architecture du README divise le système en quatre domaines. Le domaine d'accès contient les clients API et l'administration React. Le domaine central contient les services de gestion, la synchronisation des comptes, le service de passerelle et le service d'audit. Le domaine du canal fournisseur a un registre de fournisseurs et trois fournisseurs : Grok Build, Grok Web et Grok Console. L'infrastructure partagée comprend un gestionnaire de trafic sortant, SQLite ou PostgreSQL, et de la mémoire ou Redis. Chaque fournisseur conserve un état de compte indépendant et utilise un périmètre de sortie isolé. Le basculement reste au sein du fournisseur sélectionné, et le gestionnaire de sortie gère les pools de proxys, le repli et la clairance.

Capacités des fournisseurs et opérations de compte

Chaque fournisseur a sa propre authentification et gestion des modèles. Grok Build utilise OAuth ou OAuth d'appareil, découvre les modèles par compte et prend en charge les réponses, les discussions, les messages, la compaction, les réponses stockées et la vidéo. Grok Web utilise SSO, a des modèles intégrés filtrés par niveau, et ajoute les images et l'édition d'images. Grok Console utilise SSO et fournit des réponses, des discussions et des messages sans état. L'import et l'export de comptes diffèrent selon le fournisseur : Build prend en charge OAuth d'appareil et JSON/JSONL, tandis que Web et Console acceptent le SSO collé ou TXT et JSON/JSONL. La synchronisation de quota en masse, le renouvellement des identifiants Build et la conversion Web vers Build ou Console sont disponibles.

Démarrage du service avec Docker

Le démarrage rapide utilise des images Docker officielles pour linux/amd64 et linux/arm64. Les étapes sont : cloner le dépôt, copier config.example.yaml en config.yaml, générer un secret hexadécimal et un secret Base64, et les placer dans la section secrets. Ensuite, définir un nom d'utilisateur et un mot de passe admin bootstrap. Pour démarrer le service, utilisez docker compose pull, up et logs. La console d'administration est à http://127.0.0.1:8000, et les données SQLite et les médias locaux sont stockés dans le volume Compose. Après la première connexion, le README recommande de changer le mot de passe administrateur et de supprimer la configuration bootstrapAdmin. Il avertit également de ne jamais faire pivoter credentialEncryptionKey après le stockage des identifiants.

Modèles, routage et points de terminaison API

Les modèles Build sont découverts à partir des capacités du compte, tandis que Web et Console utilisent des catalogues intégrés. Le README indique que la page des modèles ou GET /v1/models est la source de vérité ; il ne maintient pas de liste statique. Les noms publics omettent généralement le fournisseur, mais les routes peuvent être épinglées avec les préfixes Build/, Web/ ou Console/. L'API inclut /v1/responses, /v1/chat/completions, /v1/messages, /v1/images/generations et edits, et /v1/videos/*. Les réponses stockées et la compaction dépendent du fournisseur sélectionné. Les clés client prennent en charge les listes blanches de modèles et des limites facultatives de RPM, de concurrence, de dépenses et d'expiration. Swagger n'est disponible que si server.swaggerEnabled est vrai.

Périmètres de sortie, Cloudflare et comportement de nouvelle tentative

Les nœuds de sortie sont limités à Build, Web, Console ou aux actifs Web. La console d'administration prend en charge HTTP, HTTPS, SOCKS4/4A, SOCKS5/5H et Resin, avec import par abonnement et texte/Base64, sondes par lots, filtrage, affectation et équilibrage. Le repli par périmètre peut être aucun, direct ou un nœud fixe. Le mode pool de proxys évite un refroidissement global après un échec de connexion. La couche de sortie ne réessaie que les échecs de connexion connus pour se produire avant la soumission de la requête ; elle ne rejoue pas les requêtes de génération soumises ni les échecs d'authentification. Pour la clairance Cloudflare gérée pour Web/Console, un profil FlareSolverr est disponible, et le gardien de qualité de sortie est un sidecar facultatif qui exécute des sondes de modèle actives.

Modes de déploiement et protections en production

Une instance unique utilise SQLite et la mémoire, tandis que plusieurs instances nécessitent PostgreSQL, Redis et un répertoire média partagé. Les déploiements multi-instances nécessitent un deployment.instanceID unique par réplica et un clusterID partagé. Les identifiants PostgreSQL peuvent être injectés via GROK2API_DATABASE_URL, qui remplace database.postgres.dsn. La liste de contrôle de production inclut l'utilisation de HTTPS, l'activation de auth.secureCookies, la désactivation de Swagger sur les déploiements publics, la sauvegarde de config.yaml, de la base de données et du stockage média, et la mise en place d'un proxy inverse devant. Le README note également que config.yaml contient les paramètres de démarrage, tandis que les paramètres du fournisseur et opérationnels sont gérés dans la console d'administration et rechargés à chaud sauf indication contraire.

Conclusion éditoriale

Le README documente la configuration, les limites des fournisseurs, la gestion du trafic sortant et le déploiement, mais ne dit rien sur les benchmarks ou les performances en production. La licence MIT accorde une autorisation large mais décline toute garantie. Les métadonnées du dépôt listent 6 975 étoiles, 2 142 forks et 11 problèmes ouverts. Pour Grok2API : une passerelle multi-comptes pour Grok Build, Web et Console, le public visé doit pouvoir contrôler Grok2API est une passerelle Go avec une console d'administration React intégrée. Elle gère des pools dans un environnement de test et accepter les limites documentées; ce choix ne convient pas à une attente de garantie non écrite.

Sources officielles

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