xai-grok
High-level async Rust client for the xAI Grok API, built on the
stream-rsstreaming toolkit.
xAI hosts an OpenAI-compatible REST API at https://api.x.ai/v1. This crate
speaks that wire format and uses stream-rs for the part most LLM clients get
subtly wrong: byte-accurate Server-Sent Events parsing of streamed
completions. Chunk boundaries, multi-line data: fields, partial UTF-8, and
interleaved tool-call deltas are handled correctly no matter how the bytes are
framed on the socket — a property covered by offline tests that split events
mid-stream.
Capabilities
| Feature | API |
|---|---|
| Chat (buffered) | [GrokClient::chat] |
| Realtime streaming | [GrokClient::chat_stream] → Stream<Item = Result<ChatChunk>> |
| Streaming + assembly | [GrokClient::chat_stream_collect] (live token callback + folded result) |
| Tool calling | [Tool] / [ToolCall] / [ToolChoice] |
| Vision | multimodal [Content::Parts] with image URLs / data: URIs |
| Structured outputs | [ResponseFormat::json_schema] |
Embeddings: xAI does not currently expose a public
/v1/embeddingsREST endpoint (embeddings exist only server-side inside the Collections API), so this crate intentionally does not ship an embeddings method rather than invent one.
Install
[]
= "0.1"
= { = "1", = ["macros", "rt-multi-thread"] }
= "0.3"
TLS backend is selectable: rustls (default, pure-Rust, no OpenSSL) or
native-tls.
Quick start
use ;
# async
Streaming
use StreamExt;
use ;
# async
Examples
All four are runnable with a live key (export XAI_API_KEY=xai-...):
Why build on stream-rs?
A streaming LLM response is an SSE body whose TCP reads have no relationship to
event or token boundaries. The offline test survives_chunk_boundary_mid_event
feeds the same logical stream split inside a JSON string and across the
\n\n terminator, and asserts the assembled output is identical — exactly the
guarantee stream-rs is designed and fuzzed for.
License
MIT