Latest in AI
Grok Voice 3.0 API: Pricing, Benchmarks and What Changes From 2.0
The new voice model keeps the same API price, but automatic upgrades and session billing deserve a closer look.
SpaceXSI released Grok Voice 3.0 on October 14, bringing a new speech-to-speech model to its Voice Agent API at $0.08 per minute. Existing applications using grok-voice-latest have already moved to the new model, so some developers need to check a change that happened without a deployment.
The launch announcement emphasizes faster responses and customer-service performance. For builders, the practical questions are more specific: what changes in an existing integration, what does a call actually cost, and which benchmark improvements are likely to survive a real workflow?
Grok Voice 3.0 pricing
The API pricing page lists the same rates for Grok Voice 3.0 and the now-deprecated 2.0 model. Prices are in US dollars.
| Charge | Grok Voice 3.0 |
|---|---|
| Audio | $0.08 per minute |
| Audio equivalent per hour | $4.80 |
| Billable text input message | $0.004 |
A ten-minute session using the default voice-activity detection mode therefore costs $0.80 in audio charges. That calculation excludes text-message charges and anything your application pays separately for telephony or its own infrastructure. A low model rate should not become a claim about the total cost of running a support line.
There is also an important distinction in the speech pricing documentation: the default server_vad mode is billed for session duration. Push-to-talk is billed for audio sent and received. Server VAD means the service detects when the user is speaking rather than requiring a button press.
If someone pauses to find an order number, a duration-billed connection can keep accumulating cost. The interaction design affects the bill even when the model price stays the same. For a hands-free agent, that may be a reasonable tradeoff. For an occasional voice command, leaving an idle session open deserves more scrutiny.
The $0.004 text fee applies to client-sent conversation.item.create events, with exceptions for server-requested function_call_output items and items containing input_audio or audio. Audio items use the audio meter instead. response.create itself is not a billable text input. Avoid counting every protocol event as a separate text charge.
How to upgrade from Grok Voice 2.0
The speech-to-speech guide says the endpoint, session parameters and events are unchanged. Applications pinned to grok-voice-2.0 should change the model to grok-voice-3.0. The grok-voice-latest alias already selects 3.0.
The WebSocket endpoint accepts the model as a query parameter: wss://api.x.ai/v1/realtime?model=grok-voice-3.0. Client-side applications should use short-lived ephemeral tokens; the documentation reserves direct API-key authentication for the server.
Protocol compatibility still leaves behavior to test. If a support agent has already been evaluated, replay the difficult cases after the upgrade: interrupted answers, corrected addresses, ambiguous requests and failed tool calls. A voice that sounds more natural can still make a different decision about when to act.
A versioned model name makes a release choice explicit; a latest alias delegates that choice to the provider. Either can be sensible, depending on how quickly your team detects regressions. The important part is knowing which policy your production application is using.
What the benchmarks actually show
SpaceXSI reports an 86.9 score on Artificial Analysis's combined Speech-to-Speech Index and under-one-second latency. Those are reported results, rather than a response-time guarantee for your network, tools or application.
The independently published Speech Agent Arena adds useful context. On October 14, 2026, Grok Voice 3.0 had a 1070 preference Elo and 94.8% task success, with 637 samples listed. Its displayed preference rank was third, with an estimated rank range of second through sixth.
That does not contradict a lead on a different combined index. It shows why a broad “best voice model” label can hide the choice of measurement. Preference, task completion and response time answer different questions, and uncertainty intervals matter when comparing nearby scores.
For an appointment-booking agent, I would care about whether the correct time was actually reserved, how often the caller had to repeat themselves, and whether the agent handled a correction before confirming. These checks connect a benchmark result to the job the product has to do.
Where production teams should be careful
The published speech API limits are ten concurrent sessions per team and a maximum session duration of 120 minutes. Teams expecting many simultaneous calls should confirm their available capacity before promising a rollout. The model's availability alone does not settle that operational question.
Start with a bounded workflow where the expected result is easy to verify. A booking system should check the reservation record; a support agent should check whether the promised action completed. Keep a route to a person when the request falls outside those boundaries.
The useful next measurement is cost per correctly completed call, including retries and handoffs. A faster conversation earns its place when it gets the caller to a reliable outcome with less work left for everyone else.
I'm Paras. I work at the intersection of AI, engineering and distribution.
If you're building an AI product and want help turning technical launches into clear stories that developers and founders read and share, I'd be happy to talk.