SpaceXAI Ships Experimental TypeScript SDK for Multimodal Grok

SpaceXAI now has an official TypeScript SDK for Grok. On October 2, 2026, Eric Zakariasson (AI at SpaceXAI; early Cursor) announced an experimental package — @xai-official/sdk — that pulls text, voice, image, and video into one typed client, plus server-hosted tools such as real-time X search, web search, code execution, and remote MCP. The npm package hit 0.1.0 the same day and was already at 0.2.1 by evening UTC. Source is github.com/xai-org/xai-sdk-ts; behavior tracks docs.x.ai.

This is the API companion to the model stack explainx.ai has been covering: Grok 4.7's launch benchmarks and $2/$6 pricing, the Grok Bot persistent-agent beta, and the open-source Grok Build harness. The SDK does not replace those products. It is how Node applications call the same SpaceXAI REST surface without writing every request by hand.

TL;DR — what people are asking

How to install @xai-official/sdk

Requirements from the official README:

1. Node.js 22.13 or later
2. An ESM project ("type": "module" or .mjs / TS ESM)
3. A SpaceXAI API key from console.x.ai

npm install @xai-official/sdk
# or
pnpm add @xai-official/sdk

export XAI_API_KEY="your-api-key"

import { SpaceXAI } from "@xai-official/sdk";

const client = new SpaceXAI();

const response = await client.responses.create({
  model: "grok-4.7",
  input: "Explain why the sky is blue in one sentence.",
});

console.log(response.toText());

That is the entire happy path. The client reads XAI_API_KEY automatically. Pin an exact version in package.json — SpaceXAI explicitly says interfaces may change between pre-1.0 releases, and you should read CHANGELOG.md on every upgrade.

Streaming uses the same responses.create entry point with stream: true. Helper events include "text", "reasoning", "tool_call", "client_tool_call", "server_tool_call", "image", "citation", and "json" for partial structured output. Await stream.done() for the final response object; call stream.close() if you abandon a stream early.

What multimodal APIs does it expose?

The README frames the SDK as a typed ESM client built on the SpaceXAI REST API. Coverage today:

Built-in tools that run on SpaceXAI servers

Import helpers from @xai-official/sdk/tools. SpaceXAI executes these and folds results into the response:

• webSearch() — live web search (allowed_domains, excluded_domains, location, context size)
• xSearch() — posts on X (handle allow/deny lists, date windows, optional image/video understanding in posts)
• codeExecution() — sandboxed Python (code_interpreter)
• collectionsSearch() — RAG over collections (vector_store_ids)
• imageGeneration() — generate/edit images as a tool step inside a response
• mcp() — remote MCP servers over Streaming HTTP or SSE
• toolSearch() — load deferred tool definitions on demand

Your own function tools and shell commands still run in your process (client_tool_call while streaming). Server tools arrive as server_tool_call. That split is the main architectural story: one request can mix local functions with SpaceXAI-hosted search and code execution without you standing up a separate tool runner for those hosted capabilities.

import { SpaceXAI } from "@xai-official/sdk";
import { webSearch, codeExecution } from "@xai-official/sdk/tools";

const client = new SpaceXAI();

const response = await client.responses.create({
  model: "grok-4.7",
  input: "Latest commercial spaceflight news, then compute mean launch mass if three vehicles are 420, 550, and 610 tons.",
  tools: [webSearch(), codeExecution()],
});

console.log(response.toText());
console.log(response.usage.num_server_side_tools_used);

For media products that already track SpaceXAI's generative stack, the video helpers line up with Grok Imagine Video 1.5, and voice APIs sit next to the earlier Grok Voice / speech-to-speech surface — now reachable from the same SpaceXAI client instead of separate ad-hoc HTTP calls.

Experimental caveats (read these before you ship)

SpaceXAI is not soft-pedaling maturity. Treat these as adoption constraints, not footnotes:

1. Pre-1.0 interfaces. The README's experimental callout is explicit: coverage is early, and types/methods may change before 1.0. Pin 0.2.1 (or whatever you install today) rather than ^0.2.1 if you need reproducible builds.
2. Small public footprint. Secondary reporting noted a very small commit history at announcement time (~three commits when reviewed). That matches an early public release, not a years-old SDK with a long deprecation policy.
3. Node 22.13+ and ESM only. Older LTS Node and CommonJS apps need a bump or a thin bridge. There is no browser bundle path that accepts your long-lived API key.
4. Server-side key policy. The SDK blocks browser and Worker use by default. That is correct security hygiene — and it means every SPA still needs a backend that brokers calls.
5. Hosted-tool lock-in. Web search, X search, code execution, collections, and remote MCP run inside SpaceXAI's boundary. That cuts glue code and increases platform dependence. Price and rate limits follow API billing, not a separate SDK fee.
6. Async video jobs are fire-and-forget on cancel. videos.wait() timeouts and aborted signals do not cancel generation; the job keeps running and can still bill. There is no cancel API yet.
7. Docs lag on the JS quickstart. docs.x.ai still highlights Python xai-sdk and community JS patterns in places. For this package, the authoritative install path today is the xai-sdk-ts README plus the REST capability docs the README links.

How this differs from the REST API builders already use

Builders have been talking to https://api.x.ai/v1 with raw fetch, OpenAI-compatible clients pointed at SpaceXAI's base URL, or third-party provider wrappers. @xai-official/sdk does not invent a new backend protocol. The README states it is built on the SpaceXAI REST API. The value is packaging:

So the decision is not "REST or SDK." It is "do you want SpaceXAI to own the typed client while the wire format stays REST?" Teams with a stable internal OpenAI-compatible adapter can keep that path and adopt the official SDK where multimodal helpers and hosted tools save the most code. Teams starting fresh on Grok multimodal apps should start with @xai-official/sdk and pin hard.

The mature official sibling remains the Python SDK (xai-sdk / xai-org/xai-sdk-python), which SpaceXAI documents as the gRPC-first path. TypeScript finally has a first-party answer; it is just earlier on the stability curve.

Relation to Grok 4.7

Grok 4.7 launched September 21, 2026 — larger base model, longer RL on hard tasks, same $2 / $6 list pricing as Grok 4.6, with strengths on EEBench and Harvey Legal and gaps vs Fable 5.1 on CursorBench and Terminal-Bench. The TypeScript SDK does not change those evals. It changes how Node apps call the model and the surrounding multimodal APIs.

Practical mapping:

• Model ID in every README quickstart: grok-4.7
• Agent products such as Grok Bot remain product surfaces with their own VM and credential model; the SDK is for your application server talking to the API
• Coding harness Grok Build is still the open Rust/TUI agent — complementary, not replaced
• Hosted tools (X search especially) are how an API-side agent gets Grok's realtime X advantage without bolting on a separate search vendor

If you already standardized on Grok 4.7 in Cursor or Grok Build, the SDK is the path to put the same model ID into a production TypeScript service with image input, Imagine output, voice, batch, and server tools under one client.

What people are asking after the announcement

Do I need a new API key?

No. Use an existing SpaceXAI / xAI key from console.x.ai. Set XAI_API_KEY. Billing is API usage, not an SDK subscription.

Can I use it from Next.js Route Handlers?

Yes, on the server — Route Handlers, Server Actions, or a separate Node service on Node 22.13+. Do not import SpaceXAI into client components with a live key. For browser realtime voice, create a short-lived secret with client.voice.clientSecrets.create() on the server and pass only that secret to the WebSocket client.

Is this the same as Grok Bot?

No. Grok Bot is a hosted persistent-agent product with per-bot VMs and tool logins. @xai-official/sdk is a library for calling SpaceXAI APIs from your code. You can build Bot-like workflows yourself with Responses + tools + MCP, but you own the runtime and security boundary.

Should I migrate off my OpenAI-compatible client this week?

Only if you need the multimodal and hosted-tool helpers enough to accept experimental churn. If you only call chat completions against api.x.ai, a working REST client is fine until the SDK approaches 1.0. If you are assembling search + code execution + Imagine + voice in one TypeScript service, start pinning @xai-official/sdk now and budget for interface churn.

Where do I file bugs?

github.com/xai-org/xai-sdk-ts/issues. The announcement explicitly asked for feedback while the team iterates.

Practical starter checklist

1. Upgrade the service Node runtime to 22.13+ and confirm ESM.
2. npm install @xai-official/sdk@0.2.1 (pin the version you tested).
3. Move keys to the server; smoke-test responses.create with grok-4.7.
4. Add one hosted tool (webSearch or codeExecution) and assert usage.num_server_side_tools_used.
5. If you need images or video, hit client.images / client.videos next — not a second HTTP client.
6. Watch CHANGELOG.md for breaking renames before you widen production traffic.

Related on explainx.ai

• Grok 4.7 launch: benchmarks, pricing, Cursor — the model this SDK's examples call
• Grok 4.6 launch: official evals and pricing — prior model generation on the same API
• Grok Bot early beta — persistent agents and credential risk — product surface vs API SDK
• Grok Build open source — Apache 2.0 harness — coding-agent harness, complementary to the TS client
• Grok Imagine Video 1.5 — video models the SDK's client.videos path targets
• Grok Voice Think Fast 2 — speech-to-speech — voice stack context for client.voice
• What is MCP? — protocol behind the SDK's mcp() helper
• X-hosted MCP servers for Cursor, Claude, and Grok — earlier MCP + Grok API coverage

Primary sources: @xai-official/sdk on npm · github.com/xai-org/xai-sdk-ts · docs.x.ai · console.x.ai · Eric Zakariasson announcement on X (October 2, 2026)

Package version, Node engine, and API surface above reflect @xai-official/sdk@0.2.1 and the xai-sdk-ts README as of October 3, 2026. Experimental SDKs change quickly — verify install commands, model IDs, and tool helpers against npm and GitHub before deploying. Follow @explainx_ai for updates.