xAI Grok API

The xAI API is the developer surface for Grok — text, coding, voice, image, and video models behind one OpenAI-and-Anthropic-compatible endpoint. On a stack that defaults to local Ollama and pays for nothing without a reason, a hosted frontier API isn't a default; it's a specific tool for a specific gap. This page is the orient-and-decide surface — the official docs at docs.x.ai own the exact model IDs, the current price sheet, and the API contracts, all of which move faster than any page here should try to mirror.

What it is

A pay-per-token API to Grok, xAI's model family. You call it with the OpenAI Python client (or the Anthropic SDK) by changing one line — the base URL to https://api.x.ai/v1 — and pointing your key at xAI instead. The flagship, Grok 4.5, is positioned squarely at coding, agentic tool-calling, and knowledge work, and the pitch is as much economic as it is about intelligence: strong coding and low hallucination rates, served fast, at a price that undercuts the incumbents it's SDK-compatible with.

Two facts do most of the strategic work here:

1. Dual SDK compatibility. It speaks both the OpenAI and the Anthropic wire format. Any code already written against either can be repointed at Grok with a URL and a key — no client rewrite, no prompt re-plumbing. That makes it a genuinely low-switching-cost option rather than a lock-in bet.
2. Priced to move. The Grok 4.5 flagship lands around $2 per 1M input / $6 per 1M output tokens with configurable reasoning effort (low/medium/high). That's below the frontier models it's drop-in for — the whole play is "same interface, lower bill."

When to use it

Reach for it when:

• A task genuinely needs frontier-grade coding or agentic tool-calling and the local model isn't strong enough — the same role OpenRouter or a hosted key plays elsewhere on this stack: the escape hatch, not the default.
• You already have code written against the OpenAI or Anthropic SDK and want to A/B a cheaper backend without touching the client — the swap is a URL and a key.
• The workload is public-facing or non-sensitive (build-in-public content, published research, throwaway generation) where sending prompts to a third-party API carries no data risk.
• You want one endpoint across modalities — text, coding, Live Search, vision, image, video, voice — instead of stitching several providers together for a multimodal build.

Skip it when:

• The job runs fine on a local open-weight model — that's the $0 default here, and a hosted API only earns its bill when local demonstrably can't do the work (see Ollama).
• The prompt carries private operating data — personal logs, business internals, anything that shouldn't leave the machine. A closed cloud API tied to X is the wrong place for it (see Risks).
• You're optimizing for $0, not for the lowest paid price — "cheaper than OpenAI" is still not free, and every recurring paid call needs a reason it beats the local path.
• You need vendor neutrality or on-prem — this is a single-vendor, cloud-only dependency; the SDK compatibility softens lock-in but doesn't remove the runtime reliance.

At a glance

Product surfaces (per the docs)

Surface	What it's for
Responses API	Multi-turn text + chat — the general-purpose entry point (function calling, structured outputs, Live Search).
Code API / Grok Build	Agentic coding workflows — the flagship's headline strength, also wired into editors like Cursor.
Voice API	Realtime audio, text-to-speech, speech-to-text.
Imagine API	Image and video generation + editing.
Batch API	Bulk async jobs at reduced cost for non-interactive workloads.

Capabilities that matter for a build

• OpenAI + Anthropic SDK compatibility — the single most important integration fact. Adoption cost is near-zero if you're already on either.
• Function calling / tools and structured outputs — the primitives for agentic and typed-JSON work.
• Live Search — a first-party web-search tool, notably with access to the X firehose, which is the one data source a local model can't replicate.
• Multimodal — vision (image understanding), image + video generation, and voice, behind the same auth.
• Configurable reasoning effort and batch/caching paths for tuning cost against latency and quality.

Exact model IDs, context windows, and the full per-token / per-image / per-second price sheet live on the xAI pricing page and models page — treat those as canonical over any number quoted here, which will drift.

Where it fits on the GL stack

Framed conditionally — this is watching, not adopted, and the default answer to "should this call a paid model?" here is still no.

• The hosted escape hatch. When a GL surface hits a task a local Ollama model can't carry — hard agentic coding, a build that needs the X firehose via Live Search — Grok is a credible, cheap, low-switching-cost option to reach for, weighed against OpenRouter and a direct OpenAI/Anthropic key.
• A cost A/B, not a migration. Because it's SDK-compatible both ways, testing whether Grok does a given job as well for less is a URL swap and a metered run — cheap to evaluate, cheap to walk away from. That's the honest reason it's on the shelf.
• Public surfaces only, if at all. Anything touching private operating data stays off a third-party cloud API. builddaily.io-style public/build-in-public generation is the safe lane; the private internals are not.

Gotchas

• "Cheaper than the frontier" is still paid. The $2/$6 flagship pricing is attractive against OpenAI/Anthropic, but the baseline here is $0 on local hardware. The comparison that matters isn't Grok-vs-OpenAI; it's Grok-vs-Ollama-on-your-own-box.
• Model IDs and prices move. xAI ships fast — flagship names, context windows, and rates change release to release. Don't hardcode a model string or a price into a page or a config; read it from the docs at integration time.
• SDK-compatible ≠ behavior-identical. A URL swap runs your code, but prompts tuned for one model's quirks won't transfer their exact quality. Re-evaluate outputs after switching; don't assume parity because the call succeeded.
• Live Search is the real differentiator, and it's a lock-in vector. X-firehose search is the one capability with no local substitute — which is exactly why leaning on it makes the dependency stickier than the SDK compatibility suggests.

Risks

• Data leaves the machine. Every call ships your prompt to a closed third-party API tied to X. For a stack whose whole posture is local-first and data-stays-home, that's the headline risk, not a footnote — gate hard on what's allowed to go over the wire.
• Single-vendor cloud runtime. The SDK compatibility genuinely lowers switching cost, but at runtime you're still dependent on one vendor's uptime, pricing, and policy. A rate change or a policy shift is theirs to make, not yours.
• Spend creep. A metered API that's "cheap per call" is how a $0 bill quietly becomes a monthly line item. Any adoption needs a hard budget and a reason it beats the local path — not just "it worked."

Related

• Grok Build — xAI's terminal coding agent built on this API; the agentic wrapper around the same models.
• Ollama — the local-LLM substrate that is the $0 default this is measured against; reach for Grok only when local can't do the job.
• DSPy — model-agnostic by design: a compiled DSPy module can point at a local Ollama model or an OpenAI-compatible endpoint like xAI, so the swap-cost this page hinges on is real at the brain layer too.
• Coinbase Developer Platform — the other "one paid platform behind one auth surface" evaluated here, on the Web3 side.