Grok Build

Deux produits portent le nom Grok Build

Grok Build désigne d'abord l'agent de code en terminal de SpaceXSI, l'ancienne xAI, objet de cette fiche : commande grok, installation par script, interface plein écran dans le terminal. Depuis le 19 août 2026, le même nom couvre aussi le générateur d'applications intégré au chat Grok sur le web, iOS et Android : né « Build Mode » le 28 juillet 2026 en bêta pour les abonnés SuperGrok Heavy (« Tell Grok an idea, and it builds a working version live in your chat, on the web or your phone »), il est annoncé le 19 août comme « now available on every plan, on the web and on mobile », avec publication des applications sur une adresse grok.me et export vers GitHub. Ce billet renvoie à « Grok Build for the terminal » comme à un outil distinct, pour continuer un projet exporté. Les abonnements, les modèles et les limites des deux produits ne se confondent pas : la mention « tous les plans » du 19 août porte sur le générateur du chat. La fiche Grok couvre les modèles et l'éditeur.

Mai 2026 : la bêta de l'agent en terminal

Le billet « Introducing Grok Build », daté du 25 mai 2026, annonce : « Today we're launching an early beta of Grok Build, a powerful new coding agent for professional software engineering and complex coding work », « available now to all SuperGrok and X Premium Plus subscribers ». Engadget (15 mai) et The Verge (14 mai) avaient rapporté une première bêta limitée aux abonnés SuperGrok Heavy ; le billet ne mentionne pas cette étape. L'outil s'installe par un script (curl sur macOS et Linux, PowerShell sur Windows), se lance avec grok, tourne en mode headless avec l'option -p pour les scripts et la CI, et s'embarque dans un éditeur via l'Agent Client Protocol (ACP). Le billet cite le mode plan, où l'utilisateur approuve, commente ou réécrit le plan avant exécution, et des sous-agents parallèles qui peuvent travailler chacun dans son propre worktree Git.

Au 22 octobre 2026, SpaceXSI n'a publié aucune annonce de fin de bêta. Le dépôt public en donne toutefois la trace : la synchronisation du 7 août 2026 fait passer la version du binaire de 0.2.121 à 1.0.0, et celle du 29 septembre porte la 1.0.45. Le nom de l'éditeur varie d'une page à l'autre : SpaceXSI dans le titre du site, « SpaceXAI LLC » en pied de page, SpaceXAI dans le README du dépôt.

Modèles, palier gratuit et abonnements au 22 octobre 2026

Le modèle de l'agent a changé quatre fois en cinq mois. Les notes de version de docs.x.ai listent en mai 2026 un modèle « Grok Build 0.1 », identifiant grok-build-0.1, « Currently in early access », avec 256 000 tokens de contexte, 1 $ le million de tokens en entrée et 2 $ en sortie sous 200 000 tokens de prompt ; le billet « Use Grok in Warp » du 15 juin 2026 le nomme « the model powering Grok Build ». En juillet, le billet de Grok 4.5 annonce : « Grok 4.5 is now the default model in Grok Build. » Le 12 août, Grok 4.6 est « available today in Cursor and Grok Build », avec un quota doublé la première semaine. Le 21 septembre 2026, Grok 4.7 arrive dans les deux outils et le guide développeur le décrit comme « the default model of the coding agent » : 500 000 tokens de contexte, 2 $ en entrée et 6 $ en sortie sous 200 000 tokens, le double au-delà. Une variante Grok 4.7 Fast, même modèle servi deux fois plus vite, n'existe que dans Cursor et Grok Build, facturée par l'abonnement : « 2x the standard token rates, or 1.5x for long-context requests », le long contexte commençant à 200 000 tokens de prompt.

Un palier gratuit existe : le billet de Grok 4.7 invite à « try it in Grok Build for free » et le guide précise que Grok 4.7 Fast « is not included in Grok Build's free tier ». La documentation ne précise pas les limites de ce palier au 22 octobre 2026. Le 12 octobre 2026, SpaceXSI a remplacé ses abonnements par « The X Subscription » (Free, Plus à 8 $, Premium à 30 $, Super à 100 $, Ultra à 200 $ par mois), avec un quota de modèles Grok partagé entre Grok et Cursor ; ce billet ne nomme pas Grok Build, et la documentation ne précise pas, au 22 octobre 2026, quel palier donne accès à la CLI. La connexion passe par le navigateur au premier lancement, ou par la variable XAI_API_KEY pour un usage sans écran.

Contexte partagé : AGENTS.md, skills, plugins, hooks, MCP

Le billet du 25 mai 2026 pose la règle : « Your AGENTS.md, plugins, hooks, skills, and MCP servers all work out of the box. » La documentation va plus loin : Grok Build lit la famille de fichiers AGENTS.md du répertoire courant jusqu'à la racine du dépôt, et « automatically reads Claude Code marketplaces, plugins, skills, MCPs, agents, hooks, and instruction files », soit CLAUDE.md, CLAUDE.local.md et le dossier .claude/rules/. Les skills sont des dossiers avec un SKILL.md à en-tête YAML, cherchés dans .grok/skills/, ~/.agents/skills/ et les plugins activés ; les hooks d'un projet ne s'exécutent qu'après une commande /hooks-trust. SpaceXSI publie aussi un plugin pour Claude Code, xai-org/grok-build-plugin-cc, qui délègue revues et tâches de secours à la commande grok.

Un dépôt outillé pour Claude Code, Codex ou OpenCode se pilote donc avec Grok Build sans réécrire son contexte versionné. Faire tourner plusieurs harnais sur le même projet mesure la qualité de ce contexte : si l'agent de SpaceXSI met le code à jour aussi bien que l'outil habituel, l'actif est dans les fichiers, pas dans l'outil. C'est le fil de la série sur les harnais ouverts.

Permissions en mode Ask, sandbox désactivée par défaut

La page des permissions donne le réglage par défaut : « Ask (default) », qui demande une validation pour tout ce qui n'est pas déjà autorisé ; auto laisse un classifieur approuver les outils jugés sûrs ; always-approve saute les demandes, les règles deny et les hooks restant actifs. Les règles se posent par motifs, « deny always wins over allow », et une autorisation mémorisée continue de demander confirmation pour des motifs dangereux comme rm ou git push. La sandbox est un mécanisme séparé, et sa page est nette : « Off by default ». Quatre profils intégrés existent (workspace, devbox, read-only, strict), appuyés sur Landlock sous Linux et Seatbelt sous macOS ; le blocage réseau des processus enfants n'est appliqué que sous Linux, et les appels au modèle et aux outils web ne sont jamais bloqués. Une entreprise peut imposer un profil via le fichier requirements.toml.

Juillet 2026 : le téléversement des dépôts, puis l'ouverture du code

Le 14 juillet 2026, The Register rapporte le travail du chercheur Cereblab : Grok Build empaquetait des dépôts entiers en bundles Git, historique compris, et les envoyait vers un bucket Google Cloud Storage de SpaceXAI, y compris quand l'agent avait pour seule consigne de répondre « OK » sans ouvrir de fichier. L'éditeur a réagi côté serveur en passant un drapeau disable_codebase_upload à vrai, et a déclaré que les utilisateurs en rétention zéro n'avaient laissé ni trace ni code, la commande /privacy coupant la rétention et supprimant les données déjà synchronisées pour les autres. Elon Musk a promis : « As a precautionary measure, all user data that was uploaded to SpaceXAI before now will be completely and utterly deleted. » The Register n'a pas pu vérifier la suppression, et Cereblab a objecté qu'un drapeau global silencieux n'est pas un réglage par défaut : « The right default is off. » Selon le chercheur, dont le dépôt cereblab/grok-build-exfil-repro permet de rejouer la capture sur sa propre machine, le comportement a été observé sur la version 0.2.93 de juillet 2026 ; l'éditeur n'a nommé aucune version corrigée au 22 octobre 2026.

Le 15 juillet 2026, SpaceXSI publie « Grok Build is Now Open Source » : « We're open-sourcing Grok Build, SpaceXSI's coding agent and TUI. » Le billet ne mentionne pas l'incident de la veille. Le dépôt GitHub xai-org/grok-build, créé le 14 juillet, contient le code Rust de la commande grok et de son runtime, sous licence Apache 2.0 pour le code maison (copyright 2023-2026 SpaceXAI) ; son README précise : « It is synced periodically from the SpaceXAI monorepo », avec un fichier SOURCE_REV qui enregistre le commit d'origine, et le fichier THIRD-PARTY-NOTICES signale des ports en arbre d'outils venus d'openai/codex et de sst/opencode. Au 22 octobre 2026, l'API GitHub renvoie 27 494 étoiles, une valeur qui bouge chaque jour et mesure l'attention, pas l'usage. Des binaires précompilés existent pour macOS, Linux et Windows ; les builds Windows depuis les sources ne sont pas testés selon le README.

Ne pas confondre avec les « grok-cli » communautaires

Plusieurs projets GitHub portent le nom « grok-cli » sans lien avec l'éditeur. Le plus visible, superagent-ai/grok-cli, créé le 14 juillet 2025 sous licence MIT, enveloppe l'API Grok dans un agent de terminal écrit avec Bun ; son README le dit « community-built, open-source, and not affiliated with, endorsed by, or sponsored by xAI Corp. » et rappelle que « Grok » est une marque déposée de xAI. Des interfaces de bureau non officielles pour Grok Build existent aussi. Pour l'outil de SpaceXSI, le point d'entrée reste x.ai/cli et le dépôt xai-org/grok-build.

Points de vigilance pour une DSI

Quatre sujets se lisent dans le contrat et la documentation avant un pilote : la rétention zéro, qui n'est effective que si elle est activée pour l'équipe ou l'entreprise ; la sandbox, désactivée par défaut, qu'un profil imposé par requirements.toml peut rendre obligatoire ; l'historique local des sessions, conservé dans ~/.grok/ sur chaque poste ; et le lieu d'inférence. Sur ce dernier point, l'API propose un point d'accès régional us.api.x.ai « which keeps inference in the United States », à 10 % de plus pour grok-4.7. La référence de configuration du dépôt expose une clé endpoints.xai_api_base_url (variable GROK_XAI_API_BASE_URL, verrouillable par l'entreprise) et un base_url par modèle dans config.toml, de quoi changer l'adresse de l'API ; la documentation ne décrit pas, au 22 octobre 2026, le pointage de la CLI vers ce point d'accès US, et aucune option de résidence en Europe n'est nommée au 22 octobre 2026.

• Vérifier que le fichier requirements.toml imposé par l'entreprise est bien lu sur les postes gérés, profil de sandbox compris.
• Tester les skills et hooks existants du dépôt avant de les déclarer compatibles.
• Comparer la facture par tâche, pas par token, avec l'outil déjà en place.