Grok Voice API

Executive Summary

Grok Voice API is a hosted service for realtime conversations with audio, text and tools. Its model page documents bidirectional WebSocket access, custom functions, web/X search, collections and remote MCP tools.^[1] It belongs in the agentic voice APIs comparison as a developer-facing conversation service, separate from the consumer Grok application's voice mode.

The useful evaluation extends beyond a voice sample. A production application must authenticate callers, coordinate playback with tool results, recover from interrupted connections and account for both directions of audio. Those responsibilities determine whether a convincing demo becomes a dependable workflow.

Product and Protocol

The current guide maps grok-voice-latest to grok-voice-think-fast-2.0; versioned names allow pinning. Reasoning effort accepts high or none, with high the documented default. The guide also lists differences from OpenAI Realtime, including cumulative transcription updates and unsupported events.^[2] Compatibility is a migration aid, not proof that every existing client behavior transfers unchanged.

The API reference defines audio append/commit events, function-call results and response cancellation. Server VAD automates turn creation and interruptions; manual cancellation serves non-VAD operation. Audio truncation can remove the unheard portion of an assistant message from conversation history.^[3] The table describes implementation responsibilities rather than a benchmark of how well any particular client performs them.

Authentication, State and Retention

For browser/mobile applications, a server mints a short-lived token through /v1/realtime/client_secrets; the client uses that token instead of embedding the account API key. Browser WebSockets pass it through the documented subprotocol mechanism. The token endpoint does not accept every field used by other providers' session endpoints.^[4]

Resumption is opt-in on both the original and reconnecting session. The guide says transcripts and tool results can be replayed, with history expiring after thirty minutes of inactivity.^[2] A recovered conversation still needs application-level reconciliation: a replayed request must not cause an already completed booking to be performed again.

The API privacy FAQ states that inputs and outputs are not used for training without permission. Default audit retention is thirty days; team-level zero-data-retention changes available stateful features, including voice conversation history.^[5] Evaluate retention and recovery together. Keeping a local business record and retaining a model conversation are separate design choices.

Phone Integration and Recovery

The direct SIP guide uses a customer-owned number, signed incoming-call webhooks and a WebSocket joined with the returned call ID. It does not support provisioning an xAI number through the API. The service exposes transfer and hangup operations; carrier/PBX configuration remains part of deployment.^[6]

A transfer is not complete merely because a request was sent. The guide defines HTTP 200 from refer as an answered destination; downstream rejection and timeout have other status codes. After a documented downstream rejection, the same session remains usable, and the application must decide how to tell the caller or try another path.^[6]

This makes transfer failure a useful acceptance test. The caller should reach a clear outcome even when the destination is busy, unavailable or rejects the request. Evaluate that behavior before measuring successful-call throughput.

Pricing and Limits

Published model-page rates checked September 15, 2026:

The text fee applies to conversation.item.create, except function-call outputs and audio items. response.create itself is not a billable text event.^[1]

For example, one minute of metered input plus one minute of metered output costs $0.16 in audio, before other applicable charges. Two billable text events add $0.008. This arithmetic example is not a measured call: silence, overlap, tools and carrier services must be reconciled with the actual invoice. The service is usage-billed access, not a downloadable model license.

A Worked Evaluation

Consider an appointment assistant with separate lookup_booking, list_times and change_booking functions. The developer guide recommends keeping prompt instructions consistent with tool schemas and specifying when a consequential action needs confirmation.^[7] Application authorization must enforce the permitted operation; a spoken instruction alone is not an access-control system.

A useful pilot would:

1. Ask for a booking lookup, then interrupt the spoken answer with a correction. Check both the audible result and stored conversation.
2. Return a deliberately slow tool result. Verify that the client does not play two responses over one another.
3. Disconnect after a confirmed change and reconnect. Check that the application reports the completed change without executing it twice.
4. Attempt an unavailable transfer. Keep the caller informed and preserve a usable fallback.
5. Record successful outcomes, unauthorized attempts, recognition errors, interruption recovery and actual billed units.

This is a proposed test, not a report of running the API. The guide specifically warns that requesting the next response while earlier audio is still playing can produce overlap.^[2] That is a concrete client-integration issue that a model-quality score would miss.

Developer Evidence and Fit

Agent Voice Response publishes a separate Grok connector that resamples telephony audio, forwards transcripts and interruptions, and gives each client its own upstream session.^[8] This is useful implementation evidence from another project; it is not an independent production-quality or latency benchmark. The connector's documented defaults also need checking against the current API before reuse.

The strongest fit is an engineering team comfortable operating a realtime client and business-tool layer. Compare it with OpenAI Realtime and Gemini Live using the same recorded tasks and acceptance criteria, rather than assuming a common protocol or a lower headline rate determines the result.

A team seeking a complete contact-center product should separately evaluate routing, human handoff, monitoring and support. The reviewed documentation establishes an API and integration path, not every surrounding operational feature. This report used public documentation and source material; it did not place calls or independently measure latency, voice quality or task success.

---

Research by Ry Walker Research • methodology