Vercel AI SDK : l’adaptateur Grok Build expliqué

Le 13 août 2026, Vercel a officiellement ouvert à Grok Build l’accès au HarnessAgent de Vercel AI SDK 7. Un produit peut ainsi exécuter Grok Build via la même interface applicative que Vercel propose désormais pour neuf coding harnesses compatibles, sans reconstruire toute la couche d’orchestration pour chacun d’eux.

Ce que Vercel AI SDK apporte vraiment

Il s’agit d’un adaptateur, pas d’un nouveau modèle Grok.

Pour bien comprendre cette nouveauté, il faut distinguer les différentes couches. Un modèle génère des réponses. Un coding harness en fait un véritable exécutant en prenant en charge les fichiers, les outils, les sessions, les autorisations et la boucle qui fait avancer la tâche. Agent Client Protocol, ou ACP, fournit un langage commun entre un client et un harness compatible. Enfin, un adaptateur traduit ce protocole vers l’interface que l’application sait déjà utiliser.

Le nouveau package de Vercel est @ai-sdk/harness-grok-build. Il relie HarnessAgent au CLI Grok Build via ACP et s’appuie, en dessous, sur le package de plus bas niveau @ai-sdk/harness-acp.

Le parcours est donc le suivant :

Votre application → HarnessAgent → adaptateur Grok Build → CLI Grok Build dans une sandbox

La couche ACP générique constitue la plomberie. L’adaptateur Grok Build est le connecteur prêt à l’emploi : package, exécutable, correspondance des modes d’authentification, commande de lancement et mapping des outils sont déjà définis. Pour approfondir le fonctionnement du protocole, consultez l’analyse de l’adaptateur ACP pour les harnesses d’AI SDK. Ici, nous restons centrés sur le parcours Grok Build réellement utilisable.

Avant cette sortie, intégrer un runtime ACP obligeait à définir soi-même son profil d’exécution. Avec le lancement du 13 août, Grok Build a obtenu un adaptateur officiel et rejoint le même cycle de session HarnessAgent que Claude Code, Codex, Deep Agents, OpenCode et Pi. La liste comptait alors six harnesses.

Depuis le 31 août 2026, l’arrivée de fx chez Vercel a porté la liste à neuf harnesses : Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode et Pi. L’adaptateur fx élargit le catalogue, mais ne change rien au fonctionnement de l’adaptateur Grok Build.

L’expression « même interface » compte davantage que « même agent ». Le contrat applicatif peut rester inchangé. En revanche, les neuf harnesses pris en charge ne garantissent ni les mêmes outils, ni les mêmes autorisations, ni la même observabilité, ni les mêmes réponses du modèle.

Pourquoi cet adaptateur change la donne

C’est surtout le travail d’intégration qui évolue.

HarnessAgent.generate() et HarnessAgent.stream() renvoient des résultats compatibles avec AI SDK. Si le produit possède déjà une interface de chat ou de tâches fondée sur AI SDK, Grok Build peut s’insérer derrière le flux de résultats existant. Le harness change côté serveur ; l’interface utilisateur n’a pas besoin d’adopter un nouveau format de réponse simplement parce que l’exécutant n’est plus le même.

Une équipe plateforme dispose ainsi d’un cadre plus propre pour comparer plusieurs runtimes ou acheminer les tâches selon leurs besoins. Elle conserve un cycle de vie de session et un format de stream communs, puis choisit le harness le mieux adapté à chaque mission.

Rien dans cette sortie ne rend Grok Build plus rapide, moins cher ou plus précis. Elle ajoute une connexion officiellement prise en charge. Elle n’apporte rien non plus à qui utilise uniquement le CLI natif de Grok Build. Cet adaptateur s’adresse aux équipes qui bâtissent un produit ou un système interne autour d’agents de code.

À qui cet adaptateur peut-il servir dès demain ?

Une startup devtools qui ajoute un runtime

Imaginons un produit de revue de code par IA ou de réparation de dépôts, construit avec AI SDK. Grok Build peut devenir un harness serveur supplémentaire sans qu’il faille créer pour lui une API de session et un contrat de streaming distincts.

La modification concrète est limitée : installer l’adaptateur, lui associer le même type de sandbox et sélectionner Grok Build lorsque le client ou la tâche le justifie. Le bénéfice est net : un runtime de plus, sans nouvelle surface produit à maintenir.

Une équipe plateforme qui compare neuf harnesses

Une équipe plateforme peut soumettre la même tâche, strictement délimitée dans un dépôt, à Grok Build puis à un autre harness compatible. Elle compare ensuite la qualité d’exécution et les modes d’échec au sein d’un même flux applicatif.

Encore faut-il comparer ce qui est réellement comparable. ACP version 1 ne fournit pas toujours la consommation à chaque étape ; lorsque Grok ne renvoie aucun total, l’adaptateur ne permet donc pas un calcul propre du coût token par token. Les résultats et le comportement de bout en bout restent comparables, mais rien ne garantit que tous les champs d’observabilité soient aussi complets.

Une équipe d’outils internes qui répare des dépôts

Une équipe chargée des outils internes peut envoyer la correction d’un test en échec dans un espace de travail isolé, transmettre le texte de l’agent en streaming à un opérateur, puis détruire la session à la fin de la tâche. La sandbox protège l’hôte ; un cycle de vie explicite évite que des sessions temporaires ne deviennent une infrastructure oubliée.

Le gain tient au contrôle opérationnel. L’agent qui modifie le code travaille dans un environnement borné, et l’application décide précisément quand cet environnement commence et se termine.

Un responsable sécurité ou fiabilité qui valide le lancement

Cette personne doit trancher sur des points concrets. L’authentification directe utilise XAI_API_KEY. L’authentification par AI Gateway utilise les identifiants de Gateway. En mode auto par défaut, l’adaptateur choisit AI Gateway lorsque ces identifiants sont présents ; sinon, il passe par l’authentification directe de xAI.

Les autorisations doivent aussi être testées à la frontière réelle des outils. Grok Build n’annonce aucun mode de session ACP, et certaines opérations natives sans risque peuvent s’exécuter sans demande d’autorisation ACP. Une politique conçue pour un autre harness ne prouve pas que Grok Build se comportera de la même façon.

Mettre en place la configuration documentée

Le chemin complet le plus court repose sur Vercel Sandbox et la configuration par défaut de l’adaptateur.

1. 1

   Installer les packages

   Ajoutez l’API commune des harnesses, l’adaptateur Grok Build et l’implémentation Vercel Sandbox :

   pnpm add @ai-sdk/harness @ai-sdk/harness-grok-build @ai-sdk/sandbox-vercel

2. 2

   Fournir les identifiants de la sandbox et du modèle

   Pour le parcours documenté avec Vercel Sandbox, rendez VERCEL_OIDC_TOKEN disponible. Pour une authentification directe auprès de Grok, fournissez XAI_API_KEY. Si vous passez par Gateway, fournissez l’identifiant AI Gateway approprié ; AI_GATEWAY_BASE_URL permet de remplacer l’URL de base lorsque ce parcours l’exige. La sélection auth: 'auto' par défaut retient automatiquement l’option disponible.

3. 3

   Créer, exécuter et détruire la session

   Utilisez l’exemple actuel du harness Grok Build :

   import { HarnessAgent } from '@ai-sdk/harness/agent';
   import { grokBuild } from '@ai-sdk/harness-grok-build';
   import { createVercelSandbox } from '@ai-sdk/sandbox-vercel';
   
   const agent = new HarnessAgent({
     harness: grokBuild,
     model: 'grok-build-0.1',
     sandbox: createVercelSandbox({
       runtime: 'node24',
       ports: [4000],
     }),
   });
   
   const session = await agent.createSession();
   
   let exitCode = 0;
   try {
     const result = await agent.stream({
       session,
       prompt: 'Check the test failures and fix the production code.',
     });
   
     for await (const part of result.stream) {
       if (part.type === 'text-delta') {
         process.stdout.write(part.text);
       }
     }
   } catch (err) {
     exitCode = 1;
     console.error(err);
   } finally {
     await session.destroy();
     process.exit(exitCode);
   }

4. 4

   Prévoir une installation réseau à la première session

   La première session a besoin d’un accès réseau sortant, car le harness ACP installe le package épinglé @xai-official/grok@1.0.5 dans la sandbox. Sans sortie réseau, l’exécution échoue avant que l’agent puisse accomplir un travail utile.

Le détail facile à manquer concerne le port. Grok Build exige une sandbox réseau avec au moins un port exposé pour le pont ACP. L’exemple utilise Node 24 et le port 4000. Une sandbox privée de ce chemin réseau n’offre pas une configuration équivalente.

L’exemple actuel transmet model: 'grok-build-0.1' à HarnessAgent. Pour accéder aux réglages de l’adaptateur, remplacez grokBuild par createGrokBuild(). Vous pourrez choisir l’authentification, la transmission des identifiants, l’effort de raisonnement, les serveurs MCP, le port du pont, le délai de démarrage ou une fonction personnalisée de génération du token du pont. Si reasoningEffort est omis, Grok Build applique sa valeur configurée par défaut.

Les limites à connaître

L’adaptateur hérite des limites d’ACP version 1, et elles comptent en production.

• La consommation reste incomplète. ACP n’expose ni les frontières entre les étapes du modèle ni la consommation propre à chacune. L’adaptateur les déduit et signale une consommation inconnue lorsque Grok ne fournit aucun total.
• Impossible de réorienter de façon portable un tour en cours. ACP ne définit aucune API commune pour intervenir en milieu de tour ou déclencher une compaction manuelle.
• Le filtrage des outils natifs est limité. Les outils de l’hôte peuvent être filtrés, mais toute tentative de filtrer ceux intégrés à Grok déclenche une erreur de capacité non prise en charge.
• Le catalogue d’outils peut devenir obsolète. Lorsque la liste des outils de l’hôte change, Grok Build doit actualiser sa liste MCP via ACP. S’il conserve l’ancienne, le tour échoue explicitement.

La gestion des versions présente un autre risque. Les packages de harnesses d’AI SDK sont expérimentaux : des ruptures de compatibilité entre deux versions sont donc prévisibles. L’adaptateur Grok épingle en interne le CLI et la commande de lancement ACP, sans permettre à createGrokBuild() de les remplacer. Le parcours pris en charge est plus simple, mais c’est aussi le package de l’adaptateur qui décide quand ce runtime épinglé évolue.

Par défaut, le pont utilise comme identifiant un token aléatoire de 32 octets. Si vous remplacez la fonction qui le génère, elle doit toujours renvoyer une valeur convenablement secrète. Il s’agit d’une mesure de sécurité, pas d’un emplacement pratique pour une chaîne lisible réservée au développement.

Enfin, cette annonce ne concerne pas les tarifs. Le mode d’authentification choisi pour Grok et la sandbox réseau conservent leurs propres coûts d’exploitation. L’adaptateur réduit le travail d’intégration sur mesure ; il ne supprime pas l’infrastructure sous-jacente.

Que faire maintenant ?

Passez à l’action cette semaine si AI SDK 7 est déjà en production et que Grok Build doit devenir un runtime de code sélectionnable. Commencez par une tâche bien délimitée dans un dépôt, conservez l’adaptateur par défaut, testez aussi bien la réussite que l’échec et vérifiez la destruction de la session.

Avant une mise en production avec plusieurs harnesses, menez une évaluation courte. Comparez le résultat des tâches, le comportement des autorisations, la reprise après échec et le coût total de chaque job. N’utilisez pas la consommation par étape comme critère décisif : ACP peut ne pas la fournir.

Attendez si la compaction manuelle, la réorientation en cours de tour, une mesure exacte à chaque étape ou des listes d’autorisation pour les outils natifs sont indispensables. Ce sont des lacunes du protocole, pas des erreurs de configuration.

Vous n’êtes pas concerné si vous utilisez Grok Build directement, appelez les modèles Grok sans coding harness ou ne possédez aucune application devant basculer entre plusieurs runtimes d’agents.

Pour recevoir d’autres analyses pratiques des outils qui transforment la livraison logicielle, abonnez-vous à la newsletter.