SpaceXAI ships an experimental TypeScript SDK for Grok and hosted tools

The package combines text, voice, image and video APIs with server-run search and code tools, but its interfaces may change before version 1.0.

By · Published

Primary source: X

Why it matters

The SDK brings Grok models and xAI-operated tools into application code through one TypeScript client, while its experimental status and server-side requirements make API stability and platform dependence immediate adoption considerations.

A developer types at a laptop beside headphones, illustrating xAI’s experimental TypeScript SDK release.

Eric Zakariasson, who works on AI at SpaceXAI after joining Cursor early, announced an experimental TypeScript SDK for the xAI API on October 2nd. The package, @xai-official/sdk, gives developers one client for Grok text responses, voice, image and video generation, plus tools that xAI runs on its own servers.

https://x.com/ericzakariasson/status/2106090512210088361

poster=/api/storage/public-objects/tweet-videos/spacexai-experimental-typescript-sdk-grok-hosted-tools-poste-68aacbaa.jpg|Video from @ericzakariasson on X
Video from the original post on X.

Zakariasson described the release as early and asked developers for feedback as the team iterates. The open-source repository confirms that warning: the SDK is pre-1.0, and its interfaces may change between releases. The repository showed three commits when reviewed. That is a small public footprint for a package intended to connect applications to a broad set of production APIs, so developers adopting it should pin a version and expect to revisit integrations.

The package covers more than the text-and-chat basics. Its documentation lists streaming responses, structured output, function calling, image input, image and video generation, file uploads, batch processing, speech synthesis, transcription, multi-turn conversations, tokenization, and model and account lookup. The client is typed and built for ESM projects using Node.js 22.13 or later. It has no runtime dependencies, according to the repository.

The most consequential distinction is where some tools run. Developers can define and execute their own functions in their application, while xAI-hosted options include web search, real-time X search, code execution, image generation, file and collection search, and remote MCP servers. That can reduce the work required to assemble an agent around Grok: an application can send a request, let the model call an xAI-operated tool, and receive the result through the same API flow. It also puts more of that workflow inside xAI's service boundary.

The SDK blocks browser and Worker use by default because putting an API secret in client-side code would expose it to users. The documentation instructs developers to keep API keys on the server. That design is a practical security safeguard, but it also means a browser-based product needs its own backend to broker calls. The package itself is available through npm; the source materials do not establish a separate SDK charge or specify API costs, which depend on xAI's API pricing.

Zakariasson's background gives the launch a developer-tools focus. His personal site describes him as an early Cursor employee before his current AI work at SpaceXAI. The SDK packages several modalities and hosted tools behind a familiar TypeScript interface, aiming to make the API usable from applications rather than only through Grok's consumer-facing products.

The timing follows xAI's integration into SpaceX: SpaceX said it acquired xAI on February 2nd, 2026. The SDK repository still identifies its target as the xAI API, while Zakariasson's post uses the SpaceXAI name. The package is a developer-facing release from that combined corporate orbit, not evidence that the APIs, billing, or product roadmap have been consolidated under one name.

The package's breadth is also its main adoption question. One SDK can simplify access to text, media generation and hosted tools, but those conveniences tie application code to xAI's API shapes and hosted services. With the interfaces explicitly experimental, teams testing it will need to weigh that integration work against the benefit of calling several capabilities through one client. The release offers an official route into the API; the project has yet to show how quickly its maintainers will stabilize the interface or how much developer use it will attract.

Reader comments

Conversation for this story loads after sign-in.