Grok Build in Vercels AI SDK: Was der Adapter wirklich leistet

Am 13. August 2026 hat Vercel Grok Build offiziell an den HarnessAgent von AI SDK 7 angebunden. Damit lässt sich Grok Build in einem Produkt über dieselbe Anwendungsschnittstelle ausführen, die Vercel inzwischen für neun unterstützte Coding-Harnesses aufführt – ohne die Orchestrierung für jede Laufzeit neu zu bauen.

Was Vercel für Grok Build tatsächlich veröffentlicht hat

Es handelt sich um ein Adapter-Release, nicht um ein neues Grok-Modell.

Am klarsten wird das, wenn man die einzelnen Ebenen trennt. Ein Modell erzeugt Antworten. Ein Coding-Harness macht daraus eine arbeitsfähige Instanz: Es verwaltet Dateien, Tools, Sitzungen und Berechtigungen und hält mit einer Steuerschleife die Aufgabe am Laufen. Das Agent Client Protocol, kurz ACP, ist die gemeinsame Sprache zwischen einem Client und einem kompatiblen Harness. Ein Adapter übersetzt dieses Protokoll in die Schnittstelle, die eine Anwendung bereits kennt.

Vercels neues Paket heißt @ai-sdk/harness-grok-build. Es verbindet den HarnessAgent über ACP mit der Grok Build CLI und setzt darunter auf das Basispaket @ai-sdk/harness-acp.

Der Pfad sieht also so aus:

Ihre Anwendung → HarnessAgent → Grok-Build-Adapter → Grok Build CLI in einer Sandbox

Die allgemeine ACP-Schicht übernimmt die technische Verbindung. Der Grok-Build-Adapter ist der fertige Konnektor, bei dem Paket, ausführbare Datei, Authentifizierungszuordnung, Startbefehl und Tool-Zuordnung bereits festgelegt sind. Wer die Protokollmechanik im Detail verstehen möchte, findet sie in der Erklärung zum ACP-Harness-Adapter des AI SDK. Hier geht es gezielt um den praktisch nutzbaren Grok-Build-Pfad.

Vor diesem Release musste das Laufzeitprofil für eine ACP-Runtime selbst definiert werden. Mit der Veröffentlichung vom 13. August erhielt Grok Build einen offiziellen Adapter und durchlief denselben Sitzungsablauf im HarnessAgent wie Claude Code, Codex, Deep Agents, OpenCode und Pi. Damit umfasste die damalige Liste sechs Harnesses.

Seit dem 31. August 2026 hat Vercels Ergänzung um fx die Auswahl auf neun Harnesses erweitert: Claude Code, Cline, Codex, Cursor, Deep Agents, fx, Grok Build, OpenCode und Pi. Der fx-Adapter vergrößert den Katalog, ändert aber nichts an der Funktionsweise des Grok-Build-Adapters.

Entscheidend ist eher die „gleiche Schnittstelle“ als der „gleiche Agent“. Der Vertrag mit der Anwendung bleibt bestehen. Tool-Verhalten, Berechtigungen, Beobachtbarkeit und Modellausgaben sind bei den neun unterstützten Harnesses deshalb noch lange nicht identisch.

Warum der Adapter wichtig ist

Verändert hat sich vor allem der Integrationsaufwand.

HarnessAgent.generate() und HarnessAgent.stream() liefern Ergebnisse, die mit dem AI SDK kompatibel sind. Verfügt ein Produkt bereits über eine Chat- oder Aufgabenoberfläche auf Basis des AI SDK, kann Grok Build den vorhandenen Ergebnisfluss im Hintergrund übernehmen. Das serverseitige Harness wechselt; die Benutzeroberfläche braucht nur wegen einer anderen Arbeitsinstanz kein neues Antwortformat.

Plattformteams können Laufzeiten dadurch sauberer vergleichen oder Aufträge gezielt verteilen. Sitzungslebenszyklus und Stream-Format bleiben einheitlich, während für jede Aufgabe das passende Harness gewählt wird.

Grok Build wird dadurch weder schneller noch günstiger oder genauer. Das Release ergänzt eine offiziell unterstützte Verbindung. Wer Grok Build ausschließlich über die eigene CLI nutzt, hat davon ebenfalls nichts. Gedacht ist der Adapter für Produkte oder interne Systeme rund um Coding Agents.

Wer Grok Build jetzt als Coding Agent einsetzen kann

Devtools-Gründer, die eine weitere Runtime integrieren

Angenommen, ein auf AI SDK basierendes Produkt prüft Code oder repariert Repositorys. Grok Build lässt sich nun als weiteres serverseitiges Harness ergänzen, ohne dafür eine eigene Sitzungs-API und einen separaten Streaming-Vertrag zu entwickeln.

Der konkrete Schritt ist überschaubar: Adapter installieren, dieselbe Art von Sandbox anbinden und Grok Build auswählen, sobald Kunde oder Aufgabe danach verlangen. So kommt eine weitere Runtime-Option hinzu, ohne eine zusätzliche Produktoberfläche pflegen zu müssen.

Plattformentwickler, die neun Harnesses vergleichen

Ein Plattformteam kann dieselbe klar begrenzte Repository-Aufgabe von Grok Build und einem weiteren unterstützten Harness bearbeiten lassen. Abschlussqualität und Fehlerverhalten lassen sich anschließend innerhalb eines gemeinsamen Anwendungsablaufs vergleichen.

Dieser Vergleich braucht allerdings saubere Grenzen. ACP Version 1 liefert nicht immer Nutzungsdaten für jeden einzelnen Schritt. Wenn Grok keine Gesamtwerte zurückgibt, ermöglicht der Adapter deshalb keinen verlässlichen Token-für-Token-Kostenvergleich. Ergebnisse und End-to-End-Verhalten sind vergleichbar; eine gleich vollständige Beobachtbarkeit aller Felder darf nicht vorausgesetzt werden.

Teams für interne Tools, die Repositorys reparieren

Ein internes Tool kann die Reparatur fehlgeschlagener Tests in einen isolierten Arbeitsbereich schicken, die Textausgabe des Agenten an einen Operator streamen und die Sitzung nach Abschluss des Auftrags zerstören. Die Sandbox-Grenze schützt das Hostsystem; der ausdrücklich gesteuerte Lebenszyklus verhindert, dass temporäre Sitzungen als vergessene Infrastruktur weiterlaufen.

Der Vorteil liegt in der operativen Kontrolle. Die codeverändernde Instanz arbeitet in einer begrenzten Umgebung, und die Anwendung bestimmt, wann diese Umgebung beginnt und endet.

Verantwortliche für Sicherheit oder Zuverlässigkeit vor dem Start

Hier steht eine echte Entscheidung an. Für die direkte Authentifizierung wird XAI_API_KEY verwendet, für die Anmeldung über AI Gateway dessen Zugangsdaten. Der Standardmodus auto wählt AI Gateway, wenn passende Zugangsdaten vorhanden sind, und andernfalls die direkte xAI-Authentifizierung.

Auch die Berechtigungen müssen an der tatsächlichen Tool-Grenze geprüft werden. Grok Build weist keine ACP-Sitzungsmodi aus, und manche sicheren integrierten Arbeiten können ohne ACP-Berechtigungsanfrage ablaufen. Eine Richtlinie für ein anderes Harness beweist nicht, dass sich Grok Build genauso verhält.

So funktioniert der dokumentierte Grok-Build-Pfad

Die kürzeste vollständige Einrichtung nutzt Vercel Sandbox und die Standardkonfiguration des Adapters.

1. 1

   Pakete installieren

   Benötigt werden die gemeinsame Harness-API, der Grok-Build-Adapter und die Implementierung für Vercel Sandbox:

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

2. 2

   Zugangsdaten für Sandbox und Modell bereitstellen

   Für den dokumentierten Weg über Vercel Sandbox muss VERCEL_OIDC_TOKEN verfügbar sein. Die direkte Grok-Authentifizierung erfordert XAI_API_KEY. Für den Gateway-Pfad werden die entsprechenden Zugangsdaten von AI Gateway benötigt; AI_GATEWAY_BASE_URL steht bereit, falls diese Route eine abweichende Basis-URL braucht. Die Standardeinstellung auth: 'auto' des Adapters wählt den jeweils verfügbaren Weg.

3. 3

   Sitzung erstellen, ausführen und zerstören

   So sieht das aktuelle Harness-Beispiel für Grok Build aus:

   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

   Beim ersten Sitzungsstart mit einer Netzwerkinstallation rechnen

   Die erste Sitzung benötigt ausgehenden Netzwerkzugriff, weil das ACP-Harness das festgelegte Paket @xai-official/grok@1.0.5 innerhalb der Sandbox installiert. Ohne ausgehende Verbindungen scheitert die Sandbox, bevor der Agent sinnvolle Arbeit leisten kann.

Ein leicht zu übersehendes Detail ist der Port. Grok Build braucht eine Netzwerk-Sandbox mit mindestens einem freigegebenen Port für die ACP-Brücke. Das Beispiel verwendet Node 24 und Port 4000. Ein Sandbox-Objekt ohne diesen Netzwerkpfad ist keine gleichwertige Konfiguration.

Das aktuelle Beispiel übergibt model: 'grok-build-0.1' an den HarnessAgent. Für Einstellungen auf Adapterebene wird grokBuild durch createGrokBuild() ersetzt. Darüber lassen sich Authentifizierung, Weitergabe von Zugangsdaten, Reasoning-Aufwand, MCP-Server, Bridge-Port, Startzeitlimit oder eine eigene Funktion für das Bridge-Token festlegen. Fehlt reasoningEffort, verwendet Grok Build seine konfigurierte Standardeinstellung.

Wo die Grenzen des Adapters liegen

Der Adapter übernimmt die Einschränkungen von ACP Version 1 – und die sind im Produktivbetrieb relevant.

• Die Nutzungsdaten sind unvollständig. ACP bildet weder die Grenzen einzelner Modellschritte noch deren jeweilige Nutzung ab. Der Adapter leitet Schrittgrenzen ab und meldet eine unbekannte Nutzung, wenn Grok keine Gesamtwerte liefert.
• Eine laufende Ausführung lässt sich nicht portabel nachsteuern. ACP bietet weder eine gemeinsame API für Eingriffe während eines Turns noch für eine manuelle Komprimierung.
• Integrierte Tools lassen sich nur begrenzt filtern. Host-Tools können gefiltert werden; der Versuch, die integrierten Tools von Grok zu filtern, führt dagegen zu einem Fehler wegen einer nicht unterstützten Funktion.
• Tool-Kataloge können veralten. Ändert sich die Liste der Host-Tools, muss Grok Build seine ACP-MCP-Liste aktualisieren. Bleibt die alte Liste aktiv, schlägt der Turn ausdrücklich fehl.

Hinzu kommt ein Risiko im Release-Management. Die Harness-Pakete des AI SDK sind experimentell; zwischen Releases ist daher mit inkompatiblen Änderungen zu rechnen. Der Grok-Adapter legt CLI und ACP-Startbefehl intern fest, und createGrokBuild() bietet keine Möglichkeit, diese Details zu überschreiben. Das vereinfacht den offiziell unterstützten Weg, überlässt aber dem Adapterpaket die Kontrolle darüber, wann sich die festgelegte Runtime ändert.

Standardmäßig dient ein zufälliges 32-Byte-Token als Zugangsdaten für die Bridge. Wird die Token-Funktion ersetzt, muss auch ihr Rückgabewert ein angemessen geschütztes Geheimnis sein. Das ist eine Sicherheitskontrolle und kein geeigneter Ort für eine gut lesbare Entwicklungszeichenfolge.

Schließlich ist dies kein Preis-Release. Sowohl der gewählte Weg zur Grok-Authentifizierung als auch die Netzwerk-Sandbox verursachen weiterhin eigene Betriebskosten. Der Adapter senkt den Aufwand für individuelle Integrationen, beseitigt aber nicht die darunterliegende Infrastruktur.

Was jetzt zu tun ist

Wer bereits AI SDK 7 betreibt und Grok Build als auswählbare Coding-Runtime einsetzen möchte, sollte diese Woche aktiv werden. Sinnvoll ist der Einstieg mit einer klar begrenzten Repository-Aufgabe, dem Standardadapter, Tests für Erfolgs- und Fehlerpfad sowie einer Prüfung der Sitzungsbereinigung.

Wenn mehrere Harnesses hinter einem Produkt laufen sollen, empfiehlt sich vor dem Produktivbetrieb eine kurze Evaluation. Verglichen werden sollten Aufgabenergebnisse, Berechtigungsverhalten, Fehlerbehebung und Gesamtkosten pro Auftrag. Die Nutzung einzelner Schritte eignet sich nicht als entscheidende Kennzahl, weil ACP sie möglicherweise nicht bereitstellt.

Abwarten ist richtig, wenn manuelle Komprimierung, Nachsteuerung während eines Turns, exakte Messwerte pro Schritt oder Zulassungslisten für integrierte Tools zwingend erforderlich sind. Dabei handelt es sich um Protokolllücken, nicht um Konfigurationsfehler.

Keine Auswirkungen hat das Release auf die direkte Nutzung von Grok Build, auf Aufrufe von Grok-Modellen ohne Coding-Harness oder auf Anwendungen, die nicht zwischen Agenten-Runtimes wechseln müssen.

Wer weitere praxisnahe Einordnungen zu den Tools sucht, die verändern, wie Teams Software ausliefern, kann den Newsletter abonnieren.