Grok Voice Transcribe 2.0 Keeps Batch Audio at $0.10/Hour

What actually changed

xAI released Grok Voice Transcribe 2.0 on September 18, 2026. It replaces Grok Voice Transcribe 1.0 as the current speech-to-text model, which means it turns recorded or live speech into text for another product or workflow to use.

The two operating modes are straightforward. Batch sends a file or audio URL to a REST endpoint after the recording exists. Streaming sends audio over a WebSocket while the person is still speaking, so captions, agent replies, or live assistance can react before the call ends.

The release page says existing integrations can receive the 2.0 model with no code changes. That sounds painless, but it is exactly why operators need to pay attention. If your request does not name a model, the provider controls when your output changes.

The rate card did not change. Batch remains $0.10 per audio hour. Streaming remains $0.20 per audio hour. Speaker diarization, which assigns words to speakers, plus word-level timestamps and key-term biasing are included in those rates.

The API bill stays flat. The workflow bill might not

At the API layer, the math is clean:

Streaming costs twice the batch rate. Across 1,000 audio hours, the premium is $100. That premium earns its place when waiting for the finished recording would break the product, as it would for live captions, real-time call assistance, or a voice agent deciding what to say next.

If the audio is already sitting in storage, streaming does not make the transcript more useful by itself. A media archive, podcast backlog, recorded interview, or overnight call-review job should normally stay on batch and keep the lower rate.

The API line is only one part of the budget. The useful operating equation is:

Total transcription cost = audio API spend + human correction cost + downstream rework

The first term is known from the rate card. The second depends on reviewer time and the loaded hourly cost of that reviewer. The third appears when changed words, speaker labels, timestamps, or formatted numbers alter a caption file, quality score, CRM note, search index, or automated action.

That is the business consequence of this release. Your audio spend can remain exactly flat while the total cost of producing a usable transcript moves in either direction. Until representative audio is tested, lower correction time is a possibility, not a saving you can put into a forecast.

Who can use it, and what changes for them

A customer-support operations lead with stored calls

A support team can send recorded calls through batch at $0.10 per audio hour, turn on diarization, and pass product names as key terms. The direct API cost stays predictable. The migration question is whether 2.0 reduces or increases the minutes a reviewer spends fixing names, account details, and speaker assignments.

The payoff is not an abstract accuracy score. It is a smaller correction queue without more downstream mistakes. Measure both before changing the production pin.

A product team running a live voice agent

For a voice agent, waiting until the call ends defeats the product. Streaming at $0.20 per audio hour earns the higher rate because the transcript is part of the live control loop. The team should compare how both models handle pauses, numbers, interruptions, and key terms, then inspect the actions triggered from those transcripts.

A transcript can look cleaner to a person and still break a workflow if one formatted value changes a lookup or one turn boundary makes the agent respond too early. The acceptance test needs the downstream action, not just the text.

A media operations lead shipping captions

An agency processing interviews or client videos should use batch, keep the timestamp output in the comparison, and compare the same difficult names and overlapping speakers under both model pins. The payoff is measured in correction time and caption handoff quality, not the vendor's aggregate benchmark.

An API is a component, not an editing workspace. If your team needs a browser editor, meeting bot, subtitle workflow, or human escalation path, use the finished transcription tool comparison instead.

A multilingual SaaS support team

xAI says 2.0 is twice as accurate as 1.0 across its evaluations. It also reports that word error rate on its own multilingual short-phrase set fell from 20.6% to 6.8%. Those are vendor-run comparisons, not tests performed for this article.

A multilingual support team should sample its actual language mix, accents, phone lines, names, and code-switching. An aggregate gain does not tell you whether the languages carrying most of your ticket volume improved, or whether correction time changed enough to move staffing.

Pin the model, then test the output

The minimal batch call is small. This cURL example is the documented xAI request, with the 2.0 model named explicitly:

curl -X POST https://api.x.ai/v1/stt \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -F model=grok-voice-transcribe-2.0 \
  -F file=@audio.mp3

The important line is the model field. An explicit grok-voice-transcribe-2.0 pin makes the choice yours. For a temporary baseline, the current docs still allow grok-voice-transcribe-1.0. Keep the file field last in a multipart request because xAI warns that later option fields may be ignored.

Use the same request settings for both sides of the migration check. Changing the model, diarization, formatting, filler-word handling, and key terms at once leaves you unable to explain which change caused the output difference.

The honest part

The price is verified. The labor saving is not.

xAI's accuracy claims are useful reasons to test, but they are not a staffing model. Different audio mixes can produce different results, and a lower word error rate does not automatically mean fewer review minutes or safer automation.

The transition wording also moved faster than the announcement. The September 18 page says the default change is coming soon, while the current docs already show 2.0 as the omitted-model default. That disagreement is another reason to make the model explicit in production rather than relying on a moving alias.

Finally, the $0.10 and $0.20 rates cover audio processing. They do not price your review queue, integration work, storage, retries, or the cost of a wrong downstream action. Keep those lines separate so a cheap API does not hide an expensive workflow.

What to do now

Act this week if any xAI speech-to-text request omits the model, or if production is pinned to 1.0. Inventory the calls, run the representative set, and choose an explicit production pin.

Use streaming only when a transcript arriving during speech changes the product outcome. Use batch for recordings that can wait, because the included diarization, timestamps, and key-term options cost half as much at the audio layer.

Wait if you are only evaluating providers and have no xAI transcript feeding a live workflow. Keep 2.0 on the shortlist, but compare total correction and downstream cost on your own audio before migrating.

You are unaffected if your system does not use xAI speech-to-text, or if you already pin 2.0 and have validated its output. A pinned 1.0 integration is stable for the moment, but it is not a reason to postpone the migration test because xAI has already announced deprecation.

Your Monday move is simple: take representative audio, run 1.0 and 2.0 with the same settings, measure correction time and downstream differences, then pin the model that passes. The unchanged rate card makes the API budget easy. The transcript check protects the workflow around it.

For one practical breakdown when an AI price or workflow actually changes, join the newsletter.