Grok Build's Vercel AI SDK adapter, explained

On August 13, 2026, Vercel gave Grok Build an official route into AI SDK 7's HarnessAgent. That means a product can run Grok Build through the same application interface already used for five other coding-agent runtimes, without rebuilding the orchestration layer around each one.

What Vercel actually shipped

This is an adapter release, not a new Grok model.

The easiest way to understand it is to separate the layers. A model produces responses. A coding harness turns a model into a worker by managing files, tools, sessions, permissions, and the loop that keeps a task moving. Agent Client Protocol, or ACP, is the common language used between a client and a compatible harness. An adapter translates that protocol into the interface your application already knows.

Vercel's new package is @ai-sdk/harness-grok-build. It connects HarnessAgent to the Grok Build CLI through ACP, using the lower-level @ai-sdk/harness-acp package underneath.

So the path looks like this:

Your application → HarnessAgent → Grok Build adapter → Grok Build CLI inside a sandbox

The generic ACP layer is the plumbing. The Grok Build adapter is the finished connector with the package, executable, authentication mapping, launch command, and tool mapping already defined. If you want the deeper protocol mechanics, read the AI SDK ACP harness adapter explainer. This piece stays on the Grok Build path you can use.

Before this release, adding an ACP runtime meant defining that runtime profile yourself. Now Grok Build has an official adapter and runs through the same HarnessAgent session flow as Claude Code, Codex, Deep Agents, OpenCode, and Pi. That brings the supported list to six harnesses.

The phrase “same interface” matters more than “same agent.” You can keep the application contract. You do not get identical tool behavior, permissions, observability, or model output across all six runtimes.

Why this matters

The axis that moved is integration work.

HarnessAgent.generate() and HarnessAgent.stream() return AI SDK-compatible results. If your product already has an AI SDK chat or task interface, Grok Build can sit behind that existing result flow. The server-side harness changes. The user interface does not need a new response format just because the worker changed.

That gives a platform team a cleaner way to compare runtimes or route different jobs. The team can keep a shared session lifecycle and stream shape, then choose the harness that fits the task.

Nothing here makes Grok Build faster, cheaper, or more accurate. The release adds a supported connection. It also does not help someone who only uses Grok Build from its own CLI. This is for people building a product or internal system around coding agents.

Who can use it tomorrow

A devtools founder adding another runtime

Say you sell an AI code-review or repository-repair product built on AI SDK. You can add Grok Build as another server-side harness without creating a separate session API and streaming contract for it.

The concrete move is small: install the adapter, attach the same kind of sandbox, and choose Grok Build when that customer or task calls for it. The payoff is another runtime option without another product surface to maintain.

A platform engineer comparing six harnesses

A platform team can put the same bounded repository task through Grok Build and another supported harness, then compare completion quality and failure behavior using a shared application flow.

Keep the comparison honest. ACP version 1 does not always expose per-step usage, so this adapter cannot give you a clean token-by-token cost comparison when Grok does not return totals. You can compare outcomes and end-to-end behavior. You cannot assume every observability field is equally complete.

An internal-tools team repairing repositories

An internal-tools team can send a failed-test repair task into an isolated workspace, stream the agent's text back to an operator, and destroy the session when the job ends. The sandbox boundary protects the host, while the explicit lifecycle stops temporary sessions from becoming forgotten infrastructure.

The payoff is operational control. The code-changing worker runs in a bounded environment, and the application owns when that environment starts and ends.

A security or reliability lead reviewing the launch

This person has a real decision to make. Direct authentication uses XAI_API_KEY. AI Gateway authentication uses Gateway credentials. The default auto mode picks AI Gateway when those credentials are present and direct xAI authentication otherwise.

They also need to test permissions at the actual tool boundary. Grok Build does not advertise ACP session modes, and some safe built-in work may happen without an ACP permission request. A policy written for another harness is not proof that Grok Build behaves the same way.

Run the documented path

The shortest complete setup uses Vercel Sandbox and the adapter's default configuration.

1. 1

   Install the packages

   Add the common harness API, the Grok Build adapter, and the Vercel Sandbox implementation:

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

2. 2

   Provide sandbox and model credentials

   For the documented Vercel Sandbox path, make VERCEL_OIDC_TOKEN available. For direct Grok authentication, provide XAI_API_KEY. For the Gateway path, provide the relevant AI Gateway credential; AI_GATEWAY_BASE_URL is available when that route needs a base-URL override. The adapter's default auth: 'auto' selection chooses the available route.

3. 3

   Create, run, and destroy the session

   Use the current Grok Build harness example:

   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,
     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

   Expect a network install on the first session

   The first session needs outbound network access because the ACP harness installs the pinned @xai-official/grok@0.2.111 package inside the sandbox. A sandbox with no egress will fail before the agent gets useful work done.

The detail people will miss is the port. Grok Build needs a network sandbox with at least one exposed port for the ACP bridge. The example uses Node 24 and port 4000. A sandbox object without that network path is not an equivalent setup.

If you need more control, replace grokBuild with createGrokBuild(). You can select auth, a model, MCP servers, the bridge port, the startup timeout, or a custom bridge-token function. If you omit the model, Grok Build chooses its default.

The honest part

The adapter inherits ACP version 1's limits, and they matter in production.

• Usage is incomplete. ACP does not expose model-step boundaries or per-step usage. The adapter infers boundaries and reports unknown usage when Grok does not provide totals.
• You cannot portably steer a running turn. ACP has no common mid-turn steering or manual compaction API.
• Built-in tool filtering is limited. You can filter host tools, but trying to filter Grok's built-ins throws an unsupported-capability error.
• Tool catalogs can go stale. When your host-tool list changes, Grok Build has to refresh its ACP MCP list. If it keeps the old list, the turn fails explicitly.

There is also a release-management risk. AI SDK's harness packages are experimental, so breaking changes between releases are expected. The Grok adapter pins the CLI and ACP launch command internally, and createGrokBuild() does not let you override those details. That makes the supported path simpler, but it also means the adapter package controls when that pinned runtime changes.

The default bridge credential is a random 32-byte token. If you replace the token function, the replacement must return a properly secret value. This is a security control, not a convenient place for a readable development string.

Finally, this is not a pricing release. Your Grok authentication route and network sandbox still carry their own operating costs. The adapter reduces custom integration work. It does not remove the infrastructure underneath it.

What to do now

Act this week if you already run AI SDK 7 and want Grok Build as a selectable coding runtime. Start with a bounded repository task, keep the default adapter, test both the success and failure path, and verify session cleanup.

Run a short evaluation before production if you need several harnesses behind a product. Compare task outcomes, permission behavior, failure recovery, and total job cost. Do not use per-step usage as the deciding metric because ACP may not supply it.

Wait if manual compaction, mid-turn steering, exact per-step metering, or built-in tool allowlists are requirements. Those are protocol gaps, not configuration mistakes.

You are unaffected if you use Grok Build directly, call Grok models without a coding harness, or have no application that needs to switch agent runtimes.

If you want more practical breakdowns of the tools changing how teams ship, join the newsletter.