Research-backed calculator guide
OpenAI Audio Billing Meters: Reconcile Realtime Tokens, Live Transcription, Translation, and Session Charges
A dated, practical method for reconciling OpenAI Realtime audio and text tokens with live transcription, translation, GPT-Live seconds, and separate backend charges.
Quick answer
OpenAI audio billing is not one universal “price per minute.” For a conversational Realtime response, reconcile the usage object by modality: fresh audio input tokens, cached audio input tokens, audio output tokens, text input tokens, cached text input tokens, and text output tokens. Apply the model’s current per-1-million-token rates to each row. If you also enable input transcription or a streaming translation session, add its duration-priced meter separately. If you use GPT-Live, add the voice-session seconds and then add backend model and tool work separately. The same audio should not be charged twice merely because you converted it to an illustrative per-minute estimate. [1] [2] [3]
As checked on November 2, 2026, the OpenAI pricing page lists gpt-realtime-2.1 at $32 per 1 million audio input tokens, $64 per 1 million audio output tokens, $4 per 1 million text input tokens, $24 per 1 million text output tokens, and $0.40 per 1 million cached input tokens. Its mini variant is listed at $10 and $20 per 1 million audio input and output tokens, with $0.30 cached audio input; text input and output are $0.60 and $2.40 per 1 million tokens, with $0.06 cached text input. These are vendor rates, not estimates. [1]
The first operational question is which product path you are using. Realtime speech-to-speech uses modality token usage per Response. Dedicated live transcription and live translation use duration-based rates. GPT-Live uses active session seconds, without rounding to a whole minute, while backend model and tool work remains a separate bill. A recorded-file transcription is another path again, with its own model and per-minute or token-based rate. [1] [3] [4] [5]
The meters to reconcile
Start a ledger with one row per meter rather than one “voice minutes” field. This prevents a common error: applying a duration rate to a Realtime audio-token row, or adding a transcription charge when the application never enabled transcription.
| Meter or component | What to record | Current example rate checked 2026-11-02 | How to calculate | Output in the ledger |
|---|---|---|---|---|
| Realtime fresh audio input | input_token_details.audio_tokens not marked cached | gpt-realtime-2.1: $32 / 1M tokens | tokens ÷ 1,000,000 × rate | Fresh audio-input cost |
| Realtime cached audio input | Cached audio tokens in the input details | gpt-realtime-2.1: $0.40 / 1M tokens | cached tokens ÷ 1,000,000 × cached rate | Cached audio-input cost |
| Realtime audio output | output_token_details.audio_tokens | gpt-realtime-2.1: $64 / 1M tokens | tokens ÷ 1,000,000 × rate | Spoken-output cost |
| Realtime text input/output | Text token counts, split by direction and cache state | $4 / $24 per 1M for gpt-realtime-2.1 | tokens ÷ 1,000,000 × applicable rate | Text context and response cost |
| Live transcription | Stream duration | $0.017 / minute for gpt-live-transcribe | minutes × duration rate | Separate transcript cost |
| Live translation | Stream duration | $0.034 / minute for gpt-realtime-translate | minutes × duration rate | Separate translation cost |
| GPT-Live voice session | Final active seconds | $0.05 / minute for gpt-live-1 | seconds ÷ 60 × rate | Voice-session cost |
| Backend model and tools | Each backend response, retry, and tool call | Depends on selected models/tools | Apply each applicable rate | Separate backend cost |
The pricing page labels the Realtime rates as prices per 1 million tokens and lists GPT-Live at $0.05 per minute. It also lists recorded transcription examples such as gpt-transcribe at $0.0045 per minute, gpt-4o-transcribe at $0.006 per minute, and gpt-4o-mini-transcribe at $0.003 per minute. Treat those as current rate-card entries checked on the date above, not as a promise that a future model alias will keep the same price. [1]
For Realtime audio, “per minute” is a derived estimate. OpenAI’s cost guide says audio in user messages is one token per 100 milliseconds and audio in assistant messages is one token per 50 milliseconds, with small variations from special tokens. That implies about 600 user-audio tokens per minute and 1,200 assistant-audio tokens per minute before message overhead. It does not mean that the invoice is priced directly by minutes. [3]
A reliable reconciliation workflow
First, identify the product and model for every event. A Realtime conversation, a gpt-live-1 voice session, a dedicated gpt-live-transcribe stream, and a recorded transcription request are not interchangeable. Put the model ID, endpoint, session ID, and UTC time range in the ledger. Model aliases and regional or cloud-provider deployments can have different rates, so do not join rows by a friendly label such as “voice.”
Second, capture final usage rather than timing audio at the client. In Realtime, the billable response is created when the model produces a Response. The usage object splits input and output by modality and identifies cached input. The entire conversation can be included as input for later turns, so a five-second spoken answer can carry substantial historical input. Prompt instructions and tool definitions can also be part of that input. [3]
Third, split fresh and cached input before multiplying by rates. Cached input is not free, and it is not the same as the current user’s spoken duration. It represents repeated context recognized as a cache hit. Caching is best effort; changing a stable instruction prefix or tool definition can reduce the cacheable portion. Use the usage object’s cached counts instead of assuming that every prior token was cached. [2] [3]
Fourth, add optional duration meters only when the corresponding workflow ran. Realtime input transcription is billed separately and can report duration usage, while a dedicated Realtime transcription session streams audio and returns transcript events without a spoken assistant response. The transcription guide recommends gpt-live-transcribe for live microphone or call audio and gpt-transcribe for a committed-turn workflow. Record the actual seconds or minutes passed to that service, not the duration of an unrelated assistant response. [1] [5]
Fifth, keep session and backend rows separate. GPT-Live’s session cost is based on active duration from session start through closure, including time when the user or assistant is silent and time when the backend is working. The API says to use the final reported duration, and a WebRTC initialization request bills 15 seconds that are credited against the running duration rather than added again. Backend model tokens, tool calls, retries, and other services are separate costs. [3]
Finally, reconcile the ledger to provider usage and the invoice period. A derived estimate is useful for planning, but the final comparison should use model-specific usage events, rate-card version, timezone, and any cloud-provider or regional uplift. Keep a variance column. Investigate large variance in this order: model or endpoint mismatch, conversation history re-read, cached versus fresh classification, duplicate retries, optional transcription or translation, and backend/tool calls.
Worked cost example
Consider one 10-minute Realtime conversation on gpt-realtime-2.1. Assume the user speaks for four minutes and the assistant speaks for three minutes. The remaining time is turn-taking or silence. Assume the response usage reports 2,000 fresh text-input tokens, 8,000 cached text-input tokens, and 900 text-output tokens across the response set. These context numbers are assumptions for an inspectable example; they are not a forecast of what every session will report.
Using OpenAI’s documented audio timing, four minutes of user speech is approximately 4 × 60 × 10 = 2,400 audio input tokens. Three minutes of assistant speech is approximately 3 × 60 × 20 = 3,600 audio output tokens. Apply the current gpt-realtime-2.1 rates:
| Step | Inputs and assumption | Calculation | Estimated cost |
|---|---|---|---|
| 1 | Fresh audio input: 2,400 tokens | 2,400 ÷ 1,000,000 × $32 | $0.0768 |
| 2 | Audio output: 3,600 tokens | 3,600 ÷ 1,000,000 × $64 | $0.2304 |
| 3 | Fresh text input: 2,000 tokens | 2,000 ÷ 1,000,000 × $4 | $0.0080 |
| 4 | Cached text input: 8,000 tokens | 8,000 ÷ 1,000,000 × $0.40 | $0.0032 |
| 5 | Text output: 900 tokens | 900 ÷ 1,000,000 × $24 | $0.0216 |
| 6 | Realtime response subtotal | Sum of rows 1–5 | $0.3400 |
| 7 | Optional live transcription for four minutes | 4 × $0.017 | $0.0680 |
| 8 | Illustrative backend/tool work | Measured or quoted separately; assumed here | $0.0300 |
| 9 | Total with transcription and backend assumption | $0.3400 + $0.0680 + $0.0300 | $0.4380 |
The $0.4380 total is an estimate under the stated assumptions. It is not a vendor quote, and it excludes live translation, taxes, telephony, storage, and any retries. If the same four minutes also use gpt-realtime-translate, add 4 × $0.034 = $0.136, producing $0.574 under this example. Do not add that line merely because the assistant speaks a different language; add it when the translation session or meter actually ran.
This example also shows why a “cost per conversation minute” headline can mislead. The Realtime response subtotal is $0.3400 across a 10-minute wall-clock session, but only seven minutes contain the assumed speech. More importantly, the $0.2304 assistant-audio line is driven by 3,600 audio tokens, while the cached text line is driven by prior context. A later turn may cost more than a short first turn because the conversation is sent again. A session with more cache hits can be cheaper than the same apparent dialogue with a cache miss.
For a recorded file instead of a live conversation, replace the Realtime token rows with the selected transcription model’s rate and recorded minutes. For GPT-Live, replace the Realtime token rows with final active seconds and then add measured backend usage. Do not combine all three product paths into one blended “audio minute” rate.
Run your scenario
Turn this framework into an editable estimate.
Use dated, source-linked assumptions and see cost per request, successful task and month.
What not to count twice
Do not multiply a Realtime audio-token count by both the documented audio-token price and a derived $/minute figure. The per-minute figure is only a readability conversion from token timing. Use either the provider-reported token count or a planning estimate based on seconds, not both.
Do not assume a transcription transcript is free because it is returned as text. When input transcription is enabled in a Realtime conversation, its transcription model and usage are billed separately from the speech-to-speech model. Conversely, do not add a transcription charge to a speech-to-speech session that did not enable that feature.
Do not sum cumulative GPT-Live usage snapshots. The cost guide says each session.usage.updated snapshot replaces the previous duration snapshot. After closing, record the final usage once. Similarly, count each backend response once by response ID when the application receives delegated backend events. [3]
Do not hide tool work inside a voice-session number. A tool may call another model, a search service, a database, or a paid telephony provider. Keep each provider’s invoice evidence in a separate row and label internal allocations as estimates.
FAQ
Is OpenAI Realtime billed per minute or per token?
Realtime speech-to-speech responses are billed using input and output token counts split by modality and cache state. Audio tokens can be translated into an estimated per-minute figure using documented timing, but the minute figure is derived. The exact ledger should use the usage object and the rate for the model and endpoint that ran. [1] [3]
How many audio tokens are in one minute?
OpenAI’s cost guide gives a planning approximation of one audio token per 100 milliseconds for user messages and one per 50 milliseconds for assistant messages. That is about 600 user-audio tokens and 1,200 assistant-audio tokens per minute before special-token variation. Use actual reported usage for reconciliation because turn structure, overhead, VAD behavior, and context replay can change the result. [3]
Does cached input mean the whole previous conversation is free?
No. Cached input is billed at a lower rate, not at zero. Only the cache-hit portion reported by the usage object should receive the cached rate. Cache matching is best effort, and changing the stable beginning of the prompt can reduce the hit. Fresh current-turn audio, uncached history, output, and other meters still contribute to cost. [2] [3]
Is Realtime input transcription included in the audio-token price?
No. When input transcription is enabled, OpenAI documents it as a separate model and rate path. Depending on the transcription model, usage can be duration-based or token-based. For a duration-based example, a four-minute gpt-live-transcribe stream at $0.017 per minute would add $0.068 before other charges. Confirm the model and usage event before adding the row. [1] [3] [5]
How should I price a live translation session?
Treat streaming translation as its own duration meter. The current pricing page lists gpt-realtime-translate at $0.034 per minute. Multiply the actual translated-audio duration by that rate, then keep any Realtime conversation, transcription, backend, or telephony charges in separate rows. A translation estimate is not evidence that a voice session ran for the same number of minutes. [1]
What is the difference between GPT-Live session cost and Realtime audio cost?
GPT-Live charges the voice session by active seconds and separates that voice charge from backend model and tool work. Realtime conversational responses use modality token counts and can re-bill conversation context on later turns. Both can be used for voice applications, but their ledgers have different primary meters. [1] [3]
Why did a short Realtime turn produce a large input bill?
A later turn can include the prior conversation, system instructions, tool definitions, and the new user input. The response is priced on the resulting input-token totals, not just on the seconds of the latest utterance. Inspect fresh and cached input tokens separately, look for repeated tool definitions, and check whether retries or multiple responses were created. [3]
Which number should finance use for the invoice forecast?
Use a range built from measured sessions, with separate assumptions for user speech seconds, assistant speech seconds, turns, text context, cache-hit rate, optional transcription or translation, backend work, retries, and deployment. Keep the current rate-card date and model ID beside every assumption. For actual close, replace estimates with provider usage and invoice rows. The AI API invoice reconciliation calculator can help organize that comparison, while the AI token cost calculator is useful for token-rate sensitivity checks.
Related calculations
A Realtime bill is easiest to explain when the usage units are explicit. For a broader monthly budget that includes calls, users, and non-API operating costs, use the LLM cost calculator. To compare model rates and avoid mixing a legacy model with a current alias, see the model pricing comparison. If you are reconciling a provider export against an internal estimate, keep the usage ledger and invoice evidence together in the AI API invoice reconciliation calculator.
The calculator can estimate a scenario, but it cannot know your actual cache-hit behavior, retries, silence handling, session closure, or endpoint-specific usage. Those fields must come from logs and final provider events. This is also why a clean per-minute conversion is helpful for communication but insufficient as the accounting record.
Primary sources checked
Pricing and product behavior can change. These sources support the time-sensitive claims in this guide; verify current provider terms before committing spend.