# Grok STT 2.0 on OpenRouter: Cost and Transcript Checks

> Source: <https://www.digitalapplied.com/blog/grok-stt-2-openrouter-transcription-cost>
> Published: 2026-11-10 00:00:00+00:00

Grok STT 2.0 appeared in OpenRouter's catalogue on November 10, 2026, giving teams another route for converting audio into text. The model page displays $0.000028 per second and advertises word timestamps, optional speaker diarization and multichannel audio. The practical opportunity is inexpensive transcription with a route that may fit an existing application. The practical test is whether the resulting text is reliable enough for its intended use. [OpenRouter model listing](https://openrouter.ai/x-ai/grok-stt-2.0)

The date needs care. The direct provider's release notes introduced `grok-voice-transcribe-2.0` on September 17 and redirected the earlier version in October. November 10 is the new catalogue event, not the first release of the underlying transcription model. [Provider release notes](https://docs.x.ai/developers/release-notes)

For a content team, researcher or voice-application builder, the buying question combines three things: the API route, the correctness of important words and the labour required to approve the transcript. A very low audio-processing price can still produce an expensive workflow if people must repeatedly replay unclear passages or correct names and numbers.

1. 01Keep release dates distinctTreat November 10 as OpenRouter availability; preserve the direct model's earlier September release date.
2. 02Use the precise rateThe rounded per-second display corresponds to approximately $0.10 per hour, while direct streaming is listed separately at $0.20 per hour.
3. 03Check the endpointCompare the exact route and request format; direct WebSocket capabilities do not automatically transfer to a gateway endpoint.
4. 04Verify named attributionSpeaker labels distinguish detected voices or channels; they do not verify a person's identity.
5. 05Measure usable transcriptsEvaluate critical-word errors, timestamps and correction time alongside the cost of processing audio.

## 01 — Route identityIdentify the model and the *route separately*

OpenRouter names the route `x-ai/grok-stt-2.0`. The direct service uses `grok-voice-transcribe-2.0`. Store the identifier actually used in a job record rather than replacing both with a friendly display name. That makes it possible to investigate which service handled a transcript when an application changes providers later.

The distinction also explains the apparent release-date conflict. A model can be available directly before a gateway adds it. A catalogue's creation date answers when that route appeared, while the provider's announcement answers when the model became available through its own service. Neither date should silently replace the other.

The direct notes say requests to version 1.0 were routed to 2.0 from October 2. A system still displaying an old configuration string may therefore already have changed its underlying behaviour. Inspect the current service contract and returned records before treating an old identifier as a frozen historical model. [Release and retirement record](https://docs.x.ai/developers/release-notes)

For procurement, maintain a short route record: provider, model identifier, endpoint, request format, required options and billing unit. Add the account and deployment conditions relevant to your application. This is more useful than a screenshot of a catalogue card when someone has to reproduce a failed request.

The broader [transcription-model comparison](https://www.digitalapplied.com/blog/openai-gpt-transcribe-stt-model-comparison-2026) can help build a shortlist. This article concerns the new Grok route and the evidence needed to decide whether it belongs in a particular workflow, rather than claiming a new accuracy ranking.

## 02 — Billing arithmeticConvert the rate without inventing *a surcharge*

OpenRouter rounds the displayed rate to $0.000028 per second. The catalogue's higher-precision value is $0.0000277777777778 per second, which gives approximately $0.10 for 3,600 seconds. Multiplying the rounded display instead gives $0.1008; that rounding difference is not evidence of a separate fee. [OpenRouter catalogue API](https://openrouter.ai/api/v1/models?output_modalities=all)

The direct provider lists $0.10 per hour for REST transcription and $0.20 per hour for streaming. These are distinct modes. Use the rate for the service actually called, rather than applying an offline-file price to a live stream. [Direct pricing](https://docs.x.ai/developers/pricing)

| Rate-only arithmetic for 100 hours at the published mode or route prices, checked November 10, 2026. Review and application costs are excluded. |  |  | 
|---|---|---|
| Mode or route | Published basis | Rate-only example for 100 hours | 
|---|---|---|
| OpenRouter transcription | Approximately $0.10/hour from precise per-second field | Approximately $10 | 
| Direct REST transcription | $0.10/hour | $10 | 
| Direct streaming transcription | $0.20/hour | $20 | 

The final column is arithmetic at the stated rates, not a quote for a complete production service. It excludes review, storage, data transfer, retries and any applicable account charges. Verify how the selected service meters the audio you submit, including the settings and channels used, before forecasting an invoice.

For a small illustration, a single 30-minute file corresponds to $0.05 at the direct REST rate. If an operator then spends five minutes checking it at a hypothetical labour rate of $30 per hour, review costs $2.50. Combined processing and review are $2.55 under those assumptions. The labour assumption is invented to explain the calculation, not a measured saving or a Digital Applied quotation.

This does not mean review is wasteful. It means the buying decision should target a usable transcript and identify where human attention changes its reliability.

## 03 — Interaction modeChoose file transcription or live *transcription deliberately*

A completed recording and a live voice interface have different requirements. A media editor can often wait for a full file to finish processing. A live captioning interface needs timely updates and a clear distinction between provisional text and words that the system considers final.

The direct service documents multipart REST uploads and a WebSocket streaming interface. OpenRouter's listed route uses a JSON transcription endpoint with base64 audio. These are different request contracts; a shared model family does not make one integration a drop-in replacement for the other. [Direct speech-to-text documentation](https://docs.x.ai/developers/model-capabilities/audio/speech-to-text), [OpenRouter route](https://openrouter.ai/x-ai/grok-stt-2.0)

Start from the application's interaction. If users upload finished interviews, test file size, supported format, response handling and recovery from interrupted uploads. If they need live captions, test session setup, changing partial text, completion signals and reconnect behaviour on the documented streaming surface.

Do not assume the router exposes every optional field or live feature documented for the direct provider. Establish support from the endpoint contract and a controlled integration check. If a required capability is not confirmed, keep it unresolved rather than filling the gap with a plausible parameter name.

For a live application, distinguish the time to first partial transcript from the time to a stable final segment. A quick provisional word can improve responsiveness but should not automatically trigger an irreversible action. The user experience needs to represent uncertainty honestly while the audio is still being interpreted.

A staged design can keep those concerns separate: show provisional captions, retain final transcript segments, then apply any downstream decision rules to the appropriate completed state. The transcription service alone does not define that application policy.

## 04 — Speaker evidenceUnderstand speaker labels before attributing *a statement*

Speaker diarization means separating a recording into contributions from detected speakers. It can help distinguish who spoke when, but a label such as speaker 0 is not proof of a person's real-world identity. Multichannel audio offers another route: if separate speakers were recorded on separate channels, the application may already know which channel corresponds to which source.

The direct API documents optional speaker fields on words and separate results for multichannel requests. Those structures help organise a transcript; the correctness of their assignment still needs evaluation for the recording conditions you use. [Speech-to-text response reference](https://docs.x.ai/developers/rest-api-reference/inference/speech-to-text)

Consider a hypothetical research interview with two participants who occasionally overlap. A transcript can preserve nearly every word but assign a statement to the wrong speaker. That matters if the output becomes a quotation, evidence summary or interview analysis. An aggregate text-quality score may not reveal the attribution error.

For a recorded panel, build the acceptance rule around the intended deliverable. If the article requires named quotations, verify the relevant audio and speaker identity before publication. If the output is an anonymous thematic summary, speaker grouping may be useful without requiring names. The threshold should follow the use, not the existence of a diarization option.

##### Retain channel mapping

Keep channel mapping with the source file. A stereo recording whose left and right channels switch across recording segments can defeat an otherwise sensible attribution rule. Treat that mapping as part of input preparation and validation, not as information the model must somehow infer.

##### Keep uncertainty visible

Where assignment is uncertain, preserve the uncertainty. A reviewer can resolve a flagged segment; a confidently invented speaker name can spread into later summaries before anyone notices the underlying mistake.

## 05 — Meaningful errorsTest the words that change *the meaning*

A transcript can read smoothly while getting the most consequential detail wrong. Names, dates, amounts, measurements, product identifiers and negations deserve attention because small changes can alter the meaning of a passage. An omitted “not” may matter more than several harmless punctuation differences.

Build a proposed evaluation set from authorised recordings that resemble the intended work. Include quiet speech, background noise, overlapping voices, specialised terms and relevant accents. Do not use a clean studio sample to stand in for field interviews, or a single language to establish multilingual reliability.

For each recording, prepare a trusted reference and mark critical spans. Compare the automated output with both the full reference and those marked details. Keep the original audio available to authorised reviewers so a disputed reference can itself be corrected rather than treated as unquestionable ground truth.

| Proposed transcript checks, not a completed model comparison. Keep the audio evidence and trusted reference with every critical correction. |  |  | 
|---|---|---|
| Check | Example failure | Useful evidence | 
|---|---|---|
| Critical terms | Product name becomes a common word | Audio segment and approved spelling | 
| Numbers and units | Fifteen becomes fifty | Source timestamp and intended value | 
| Negation | A refusal becomes agreement | Full sentence with surrounding context | 
| Speaker attribution | A response assigned to the interviewer | Audio and channel or speaker record | 

This is a proposed test design, not a completed Grok benchmark. Use enough examples to cover the errors that matter, and report the sample composition. A small pilot can reveal a serious failure mode without estimating the model's accuracy across every recording your organisation will ever receive.

The [transcript-verification reference](https://www.digitalapplied.com/blog/ai-transcript-verification-reference) provides a broader acceptance structure. Retain a distinction between the raw transcript, a corrected version and any later summary. A summary that sounds plausible cannot verify the words from which it was produced.

## 06 — Reviewer navigationMake timestamps and formatting useful *to reviewers*

Word timestamps can make correction faster by linking a questionable phrase to a location in the audio. They are useful when the reviewing application preserves that connection. If a downstream export drops timing information, the reviewer may still have to search manually through the recording.

Test the complete path from transcription response to the editor's working view. Selecting a word or segment should lead to the correct part of the source. Check the beginning and end of a file, pauses and any concatenated recording boundaries. A consistent offset can make an otherwise accurate transcript frustrating to verify.

Formatting changes also deserve a deliberate policy. Written numbers, punctuation and removed filler words can make a transcript easier to read while changing its relationship to a verbatim record. Decide whether the output is intended for captions, searchable notes, quotations or a cleaned reading copy before enabling transformations.

For an interview quotation, retain the source wording and an auditable correction history. For search indexing, a readable formatted transcript may be sufficient. For a subtitle export, timing and line breaks can be as important as prose readability. These are different deliverables even when they start from the same recording.

Keep the model response separate from subsequent edits. Store the settings used, the audio identifier and the final accepted version. That lets the team investigate whether a defect came from recognition, formatting, export or manual correction instead of blaming every issue on the model.

A useful review interface should also make uncertainty easy to mark. A reviewer who cannot resolve a noisy word should be able to retain a timestamped question rather than replacing it with a guess just to complete the form.

## 07 — Usable recordingsCompare the total effort per *usable recording*

Measure processing charges, review time and repair work against the same accepted-output definition. If one route produces a raw transcript and another produces an edited publication-ready document, their costs are not comparable until the remaining work is included.

Use a simple record for each source: audio duration, route, settings, attempts, returned status, correction minutes and acceptance decision. Include failed requests and rejected transcripts. Excluding those outcomes would make the successful route appear cheaper than the workflow actually experienced.

Report both transcription performance and labour. A route can reduce recognition errors without reducing review time if reviewers must still listen to every recording. Another can make timestamps more useful and reduce navigation effort even when the raw word count of errors changes little. Those are distinct benefits worth measuring separately.

The [audio and video processing-cost guide](https://www.digitalapplied.com/blog/ai-audio-video-processing-cost-per-hour-models-2026) explains the importance of keeping billing units visible. For this decision, add the cost of turning the returned text into the deliverable your team accepts. Model rates explain only one part of that amount.

Keep evaluation order balanced when comparing routes. If reviewers become familiar with a recording after correcting the first transcript, they may review the second faster regardless of its quality. Use a design that acknowledges that learning effect instead of attributing all speed differences to the service.

The final choice can be narrow. One route may suit searchable internal recordings, while another or additional review remains necessary for publication-quality quotations. A useful procurement result defines those boundaries rather than announcing a universal winner from a handful of files.

## 08 — Controlled adoptionPut the new route into a *controlled workflow*

Begin with recordings the team is authorised to process and a clear handling policy for the resulting audio and text. Confirm the selected account's retention and access terms. A low model price does not settle whether a particular recording belongs in that service.

Keep credentials on the application side and give the reviewing system only the access it needs. The transcript can contain sensitive information even when the recording filename looks harmless. Apply the same access controls to exports, corrected versions and later summaries.

Define what happens when a request fails or returns unusable text. A retry should keep the original job identity and avoid attaching duplicate transcripts to the destination. If the route is unavailable, a supported alternative or a visible review queue is more useful than silently dropping the recording.

For downstream automation, treat transcription as evidence about what was said, not automatic authority to act. A spoken instruction may still need confirmation, account checks or a separate approval. Recognition confidence and action permission solve different problems.

Finally, retain a small regression set with the settings that produced accepted results. Recheck it when the route, model, input preparation or export process changes. The September-to-November chronology illustrates why a display name alone is insufficient to establish that the same behaviour has been preserved.

## 09 — Next stepConclusion

### Choose the complete transcription workflow

Evaluate Grok STT 2.0 as a new available route with a very low audio-processing rate. Choose the correct file or streaming surface, preserve speaker and timing evidence, and measure the work required to approve the transcript. Adopt it where the complete workflow meets the standard your recording deserves.

Digital Applied's [AI transformation services](https://www.digitalapplied.com/services/ai-transformation) help teams connect speech models, review tools and application controls into a reliable workflow for content and voice interfaces.