A voice conversation on OpenAI's Realtime API costs $0.0192 per minute while the user talks and $0.0768 per minute while the model talks back. Speaking is exactly four times listening, and that single ratio explains most of a voice session's bill. One naming note before the numbers: "GPT Live" is the ChatGPT consumer feature and has no API. The API products behind it are gpt-realtime-2.1 and gpt-realtime-2.1-mini, and those are what this post measures.
TL;DR
- gpt-realtime-2.1 bills exactly 1 audio token per 100 ms of user speech and 1 per 50 ms of model speech: $0.0192 per minute to listen, $0.0768 per minute to speak.
- Sixty seconds of silence under server VAD billed zero input tokens.
- Automatic caching covered 93% of input by turn 30; deleting one history item tripled full-price input for one turn.
- Cancelling a long spoken answer 2 seconds in billed 4 seconds of audio.
- gpt-realtime-2.1-mini has identical billing mechanics at 3.2x lower audio prices.
Every number here comes from instrumented WebSocket sessions run against both models on 2026-07-19, with every server event logged. Both models are live on the Synthorai gateway's /v1/realtime endpoint, which is where these sessions ran; the protocol and the billing are the same as talking to OpenAI directly. The harness is a single stdlib-only Python file, and each figure below traces back to a raw response.done usage record.
How do you connect to the Realtime API?
Unlike the text APIs, Realtime is not request/response over HTTP. You open one WebSocket per session and exchange JSON events over it: the client streams microphone audio in, the server streams spoken audio back, and one connection carries the whole conversation.
import websocket, json
ws = websocket.create_connection(
"wss://synthorai.io/v1/realtime?model=gpt-realtime-2.1",
header=["Authorization: Bearer sk-..."])
ws.send(json.dumps({"type": "session.update", "session": {
"type": "realtime", "output_modalities": ["audio"],
"audio": {"input": {"format": {"type": "audio/pcm", "rate": 24000}}}}}))
# stream mic audio as base64 chunks: {"type": "input_audio_buffer.append", ...}
# then either let server VAD end the turn, or commit and ask for an answer:
ws.send(json.dumps({"type": "response.create"}))
# read events until "response.done": billing usage rides on that event
The session lifecycle that matters for billing: session.update sets instructions, voice, tools, and turn detection (this becomes the cacheable prefix); input_audio_buffer.append / commit add user audio; response.create triggers a reply; and every response.done carries the full usage breakdown for that response. One dialect note: the GA API uses output_modalities and a nested audio.input/audio.output config; the beta-era response.modalities field is rejected with unknown_parameter.
How much does GPT Realtime cost per minute?
The official conversion rates hold to the exact token: a 30.0-second clip billed 300 input audio tokens (1 per 100 ms), and a 4.5-second spoken answer billed 90 output audio tokens (1 per 50 ms). That turns the per-token price list into per-minute arithmetic:
| Lane | gpt-realtime-2.1 | gpt-realtime-2.1-mini |
|---|---|---|
| Listening (user audio in, full price) | $0.0192/min | $0.0060/min |
| Speaking (model audio out) | $0.0768/min | $0.0240/min |
| Listening, cached replay | $0.00024/min (1/80th) | $0.00018/min |
| Transcription add-on (optional) | +$0.017/min | +$0.017/min |
Two costs hide outside the table. First, a spoken answer also bills text output: the transcript plus reasoning tokens (gpt-realtime-2.1 does reason; output_token_details.reasoning_tokens came back non-zero on every run). On our short test answer that added about 24% on top of the audio tokens, billed at the $24/M text rate.
Second, the transcription add-on is its own billing lane. Its usage record reads {"type": "duration", "seconds": 30}: duration-billed at $0.017 per minute, independent of tokens, and the transcript never enters the model's input. Flipping that one flag roughly doubles the input-side cost on 2.1 and nearly quadruples it on mini, so turn it on only where a compliance or product requirement actually needs the text.
Does silence, interruption, or tool calling cost anything?
Silence costs nothing. We streamed 60 seconds of silence into a session with server VAD enabled, then asked a question: the usage was byte-identical to a control session that never sent audio. VAD only commits audio it detects as speech, so hold music, a customer reading a form, or an open idle line bill zero input tokens. The caveat is that real background noise can trip VAD; pure silence is the floor, not a guarantee for a noisy call.
Interruptions bill to the generation frontier, not to the user's ear, and never for the un-generated remainder. We requested a slow spoken count to forty and cancelled after hearing 2.0 seconds: the bill was 81 audio tokens, or 4.0 seconds. The 2-second overhang is how far generation ran ahead of playback before response.cancel landed. On mini the same experiment billed 6.3 seconds, because the smaller model generates further ahead of real time. The practical rule: send response.cancel the instant your client detects barge-in, because the meter runs until the cancel arrives.
Tool calls are billing-neutral. A session with one function definition emitted the call, took the injected result, and the very next response showed 99% of its input billed at the cached rate. Function-call items and their outputs cache like any other appended history, and the tool definitions themselves sit in the static prefix that caches from turn 2 onward.
How does caching keep long sessions affordable?
The Realtime API re-reads the entire conversation as input for every response, so per-turn input grows linearly with session length. What keeps that affordable is automatic prefix caching: cached audio replays at $0.40/M instead of $32/M, 1/80th of full price. In our 30-turn session the cached share climbed steadily to 93% of input by turn 30:
The cached split is reported on every response.done:
"usage": {
"input_tokens": 891,
"input_token_details": {
"text_tokens": 891, "audio_tokens": 0,
"cached_tokens": 832,
"cached_tokens_details": { "text_tokens": 832, "audio_tokens": 0 }
}
}
Three specs the official docs do not state, all measured: caching engages at roughly 128 tokens of prefix (the text API's documented minimum is 1,024), it advances in 64-token blocks, and the static prefix is reusable across sessions on the same key. That last one matters for the 60-minute session cap: a new session's very first turn already billed its instructions at the cached rate, so rotation only pays full price to re-read conversation history, not the system prompt.
Editing history is the one way to lose the discount, and we measured the exact penalty. Deleting one early item mid-session collapsed the cached share for precisely one turn, then the cache rebuilt:
| Turn | Input | Cached | Full price |
|---|---|---|---|
| 8 (before delete) | 319 | 256 | 63 |
| 9 (first user item deleted) | 326 | 128 | 198 |
| 10 | 352 | 320 | 32 |
One more measured relief: the model's own spoken answers re-enter later inputs as text, not audio. In an 8-turn voice conversation, input audio grew by exactly the user's clip size each turn, while the assistant side reappeared as transcript tokens at $4/M. The expensive part of the compounding term is user audio only.
The playbook that falls out is short: keep history append-only, keep instructions and tool definitions byte-identical for the whole session (and across sessions), put anything dynamic in the latest user message instead of the prefix, and when you must trim, trim rarely and in large steps rather than every turn. For the general mechanics across providers, see our prompt caching guide and the measured cache minimums study.
gpt-realtime-2.1 vs mini: which should you pick?
Billing mechanics are identical on both models: same conversion rates, same 64-token cache quantization, same curve shapes. What differs is price and behavior:
| gpt-realtime-2.1 | gpt-realtime-2.1-mini | |
|---|---|---|
| Audio in / out (per 1M tokens) | $32 / $64 | $10 / $20 (3.2x cheaper) |
| Text in / out | $4 / $24 | $0.60 / $2.40 (6.7x cheaper) |
| Cached audio | $0.40 (1/80th) | $0.30 (1/33rd) |
| Text-turn latency (measured) | 0.5–0.9 s | 0.5–0.6 s |
| Verbosity on identical prompts | baseline | consistently higher output tokens |
| Barge-in overhang (2 s heard) | 4.0 s billed | 6.3 s billed |
Two details worth noticing. On the cached-replay lane the price gap nearly closes ($0.40 vs $0.30), so a highly cached long session narrows mini's advantage slightly, though fresh tokens still dominate the total. And mini's speed works against it on interruptions: it generates further ahead of playback, so each barge-in discards about twice as much generated audio. In dollars mini still wins every scenario we measured; the 3.2x price gap absorbs both effects.
Pick mini by default for short-command assistants, IVR, and high-concurrency support. Pick 2.1 when the session needs complex tool orchestration or multi-step reasoning; OpenAI positions it as the flagship for instruction following, which our cost harness deliberately does not judge.
What do common voice scenarios actually cost?
| Scenario | Dominant cost | What the measurements say |
|---|---|---|
| Voice chat, companions | Speaking lane + history compounding | Keep history append-only; the 60-min rotation re-reads history once at full price while the prompt stays cached |
| Live translation | Speaking ≈ listening duration | The dedicated gpt-realtime-translate SKU is $0.034/min flat; building translation on 2.1 runs roughly 3x that at list prices |
| Call center | Silence share of the call | Silence is free, so quiet minutes cost ≈$0; compliance transcription adds $0.017/min per leg and needs its own budget line |
| Device assistants | Connection setup + first turn | Keeping one line open beats reconnecting: idle is free, and session setup measured about 2.5 s of user-visible delay |
| Voice agents with tools | Tool round trips | Tool calls leave caching intact (99% cached on the following turn); keep definitions static |
| Meeting notes | Not a Realtime job | Duration-billed transcription plus a text model avoids the compounding term and the 60-minute cap entirely |
For interrupt-heavy scenarios, add the barge-in overhang to your per-interaction math: each interruption costs the audio the user heard plus a few seconds of generation lead.
FAQ
Is GPT Live the same as the GPT Realtime API?
No. GPT Live is the voice feature inside the ChatGPT apps and has no API or pricing page of its own. Developers who want that experience programmatically use the Realtime API models gpt-realtime-2.1 and gpt-realtime-2.1-mini, whose prices this post measures.
How long can a Realtime session last?
Sixty minutes is the hard cap, and a closed session cannot be resumed. Text history can be re-injected into a fresh session (billed once at full price, while the static prompt stays cached), but assistant audio cannot be replayed, so long-running voice products need a rotation plan before minute 60.
Is there an idle timeout between turns?
No idle timeout is documented, and silence bills zero tokens under server VAD in our measurement, so keeping a line open between interactions costs nothing except the connection itself. For sparse-use products this makes one long session cheaper and faster than reconnecting per interaction, since setup measured about 2.5 seconds.
What audio format does the API expect?
PCM16 at 24 kHz mono is the default for both input and output, configured via audio.input.format and audio.output.format in session.update. Billing does not depend on the format: audio tokens are a function of duration only, 1 token per 100 ms in and 1 per 50 ms out.
The engineering patterns for living with the 60-minute wall (rotation, history hand-off, what survives a reconnect) are their own topic, and this post's numbers are the inputs to that math. For how billed tokens decompose across families in the text API, the companion piece is our token usage anatomy.
Top comments (0)