Repository Public
1# Cost optimization23> For the complete documentation index, see [llms.txt](/llms.txt). Markdown versions of documentation pages are available by appending `.md` to the page URL.45Choose your API to understand how usage is measured and find ways to manage6costs for your voice application.78910## GPT-Live usage and costs1112GPT-Live separates the voice conversation from the backend that reasons and13runs tools. Estimate these two costs separately: the voice session depends on14duration, while backend costs depend on the models and tools you use.1516### Voice session costs1718GPT-Live voice sessions are billed per second at the current [model rate](https://developers.openai.com/api/docs/models/gpt-live-1). Session duration is not rounded up to the next whole minute.1920Active session time includes time when the user speaks, the assistant speaks, both are silent,21or the backend is working.2223For estimates, count the active session from start through closure. Use the24duration reported by the API instead of timing only the audio you play. Muting25microphone input does not close the session. When the conversation is finished,26close the session and collect its final usage.2728See [API pricing](https://developers.openai.com/api/docs/pricing) for backend model and tool prices.2930### WebRTC initialization charges3132A `POST /v1/live/sessions` request to create a WebRTC session bills 15 seconds of voice duration while the session initializes. That amount is credited against duration charges once the session starts running. Don't add another 15 seconds to the running session's duration when estimating its cost.3334For example, the 90-second session below already includes the 15 seconds billed at initialization. It is not billed as 105 seconds. Account for session-creation charges when evaluating reconnects or applications that create sessions before the user is ready to speak.3536### Backend costs3738Backend calls are billed separately from the voice session, just as they are in39applications without voice. Include model input and output tokens, cached input40where supported, and any applicable image or tool charges. If your application41calls other services, include their costs in your estimate too.4243You can optimize this work separately from the voice frontend. Use the general44[cost optimization guide](https://developers.openai.com/api/docs/guides/cost-optimization) to reduce requests45and token usage. Use [prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching) for eligible46backend models by keeping reusable instructions, tool definitions, and other47stable content at the beginning of the prompt.4849Backend choices can also change the length of the conversation. Compare the50combined cost when an optimization makes the user wait longer or changes how51reliably the assistant completes the task.5253### Estimate conversation costs5455For a conversation with one voice session:5657**Total cost = (billable voice seconds ÷ 60 × voice rate per minute) + backend costs**5859For example, at an illustrative voice rate of $0.05 per minute, a 90-second voice session costs $0.075. If the backend model and tool costs total $0.02, the conversation costs $0.095:6061| Component | Calculation | Cost |62| ---------------------- | -------------------------- | ---------- |63| Voice session | 90 seconds ÷ 60 × $0.05 | $0.075 |64| Backend work | Total model and tool costs | $0.02 |65| **Conversation total** | **$0.075 + $0.02** | **$0.095** |6667The rates and backend cost above are examples; use the current voice rate, your measured backend usage, and the68applicable model and tool rates. If the task spans multiple voice sessions, add69their durations and include backend work performed between sessions.7071### Optimization strategies7273Focus on helping the user complete the task with less unnecessary conversation74and waiting. Keep the confirmations and checks the task requires.7576#### Provide relevant context before the session7778Gather information your application already has permission to use before79starting the voice session. For example, an assistant helping with an order can80start with the order number and current status, so the user does not need to81repeat them or wait for another lookup.8283Keep this context current and focused on the task. Give the voice model the84information it needs for the conversation; keep detailed records and workflows85in the backend. See [session configuration](https://developers.openai.com/api/docs/guides/live-conversations#session-configuration)86and [delegation and tools](https://developers.openai.com/api/docs/guides/live-delegation).8788#### Reduce time spent waiting for tools8990Shorter waits can improve the user experience and reduce voice-session costs.91For example, suppose your backend uses `gpt-5.6-luna` with92[Fast mode](https://developers.openai.com/api/docs/guides/fast-mode) and runs independent tool calls in93parallel. If these optimizations help the user finish and close the voice94session one minute sooner, you save $0.05 in voice charges. The total cost95falls if the additional backend cost is less than that saving.9697You can also [start a speculative lookup from transcript fragments](https://developers.openai.com/api/docs/guides/live-delegation#react-to-transcript-fragments)98before a delegation event arrives. Include unused speculative work in your99backend cost measurements.100101See [Reduce backend latency](https://developers.openai.com/api/docs/guides/live-delegation#reduce-backend-latency)102for model, connection, streaming, and tool optimizations. Validate useful spoken103response time and task success with [voice agent evaluations](https://developers.openai.com/cookbook/examples/audio/voice_agent_evaluation).104105#### Close the session during long tasks106107The voice frontend and your application-managed backend can run independently.108With client delegation, your backend worker can keep running while the voice109session is open or closed. Save the task state and conversation context before110[closing the voice session](https://developers.openai.com/api/docs/guides/live-conversations#usage-and-graceful-close).111112For the inactivity timeout, restart trigger, and context restoration workflow, see [Close idle sessions and resume](https://developers.openai.com/api/docs/guides/live-conversations#close-idle-sessions-and-resume).113114For an ambient agent, close the voice session while the backend handles a115long-running task, such as coding in goal mode. Offer a button labeled116**Resume conversation** to start a new voice session when the user returns, or use a backend117completion event to start a new session and notify the user that the result is118ready.119120Restore the conversation by starting a new session with saved context and the121verified task result in `input`. For example, send this startup event over a122[new WebSocket connection](https://developers.openai.com/api/docs/guides/voice-websockets?api=live):123124```json125{126 "type": "session.start",127 "session": {128 "model": "gpt-live-1",129 "instructions": "Help the user review completed work and delegate follow-up tasks.",130 "input": [131 {132 "type": "message",133 "role": "developer",134 "content": [135 {136 "type": "input_text",137 "text": "Saved task: add CSV export. Result: code is ready for review."138 }139 ]140 }141 ],142 "delegation": { "type": "client" }143 }144}145```146147Wait for `session.started` before streaming audio. See148[seed a session with prior conversation](https://developers.openai.com/api/docs/guides/live-conversations#seed-a-session-with-prior-conversation)149for the supported history format.150151If the earlier session was stored with `store: true`, you can also [fork that session](https://developers.openai.com/api/docs/guides/live-conversations#store-and-fork-a-session). Keep the verified backend task state in your application whichever approach you use.152153Closing saves $0.05 per minute of idle voice time; compare that saving with154reconnection costs and the interruption to the user's experience.155156#### Choose the right backend model157158Start with models that meet the task's accuracy and reliability requirements.159Then compare total conversation cost, including voice duration, model usage,160tool calls, and retries. The [model selection guide](https://developers.openai.com/api/docs/guides/model-selection)161describes how to balance these tradeoffs.162163A larger backend model can cost less overall if it completes the task faster164and the voice-session savings exceed its additional token costs. A cheaper165model can cost more overall if it takes longer, repeats tool calls, or fails166the task.167168Compare cost per successful task alongside completion rate and time to completion. Include failed attempts and retries in the total so a cheaper configuration does not look better because it completes less work. Use the [voice agent evaluation Cookbook](https://developers.openai.com/cookbook/examples/audio/voice_agent_evaluation) when planning your comparison.169170### Monitor actual usage171172Record voice duration and backend usage separately for each session. GPT-Live173reports cumulative voice duration in seconds:174175```json176{177 "type": "session.usage.updated",178 "event_id": "event_usage_1",179 "usage": { "seconds": 12 },180 "context_window": { "usage_ratio": 0.42 }181}182```183184Each update replaces the previous duration snapshot. Do not sum the snapshots.185After sending `session.close`, keep receiving events until `session.closed` and186record its final `usage.seconds` once. Follow the187[graceful-close procedure](https://developers.openai.com/api/docs/guides/live-conversations#usage-and-graceful-close)188so your application can collect final usage before disconnecting.189190For Responses delegation, read the backend response's `usage` from nested191`response.completed` events delivered through `response.event`. Count each192backend response once, using its response ID, and retain the input, output, and193cached-token details needed to apply that model's rates. For backend work your194application runs independently, collect usage from those requests too.195196Compare estimated and actual totals across representative conversations. Keep197evaluation-only model calls separate from application usage, and review cost198together with task success.199200 201202 203204205## Realtime API costs206207This document describes how Realtime API billing works and offers strategies for optimizing costs. Voice-agent sessions accrue input and output tokens across text, audio, and image modalities. Streaming translation and streaming transcription sessions are billed by audio duration. Prices vary per model, with prices listed on the model pages (for example, [`gpt-realtime-2`](https://developers.openai.com/api/docs/models/gpt-realtime-2), [`gpt-realtime-translate`](https://developers.openai.com/api/docs/models/gpt-realtime-translate), [`gpt-realtime-whisper`](https://developers.openai.com/api/docs/models/gpt-realtime-whisper), and [`gpt-realtime`](https://developers.openai.com/api/docs/models/gpt-realtime)).208209Conversational Realtime API sessions are a series of _turns_, where the user adds input that triggers a _Response_ to produce the model output. The server maintains a _Conversation_, which is a list of _Items_ that form the input for the next turn. When a Response is returned, the output is automatically added to the Conversation.210211Translation and transcription sessions use a different streaming architecture. The client streams audio continuously and receives translated audio, transcript deltas, or transcript events as the source audio arrives. These sessions don't use the normal Response lifecycle, so estimate and monitor them with their duration-based rates instead of per-Response token usage.212213## Per-Response costs214215Realtime API costs are accrued when a Response is created, and is charged based on the numbers of input and output tokens (except for input transcription costs, see below). There is no cost currently for network bandwidth or connections. A Response can be created manually or automatically if voice activity detection (VAD) is turned on. VAD will effectively filter out empty input audio, so empty audio doesn't count as input tokens unless the client manually adds it as conversation input.216217The entire conversation is sent to the model for each Response. The output from a turn will be added as Items to the server Conversation and become the input to subsequent turns, thus turns later in the session will be more expensive.218219Text token costs can be estimated using our [tokenization tools](https://platform.openai.com/tokenizer). Audio tokens in user messages are 1 token per 100 ms of audio, while audio tokens in assistant messages are 1 token per 50ms of audio. Note that token counts include special tokens aside from the content of a message which will surface as small variations in these counts, for example a user message with 10 text tokens of content may count as 12 tokens.220221### Example222223Here’s a simple example to illustrate token costs over a multi-turn Realtime API session.224225For the first turn in the conversation we’ve added 100 tokens of instructions, a user message of 20 audio tokens (for example added by VAD based on the user speaking), for a total of 120 input tokens. Creating a Response generates an assistant output message (20 audio, 10 text tokens).226227Then we create a second turn with another user audio message. What will the tokens for turn 2 look like? The Conversation at this point includes the initial instructions, first user message, the output assistant message from the first turn, plus the second user message (25 audio tokens). This turn will have 110 text and 64 audio tokens for input, plus the output tokens of another assistant output message.228229230231The messages from the first turn are likely to be cached for turn 2, which reduces the input cost. See below for more information on caching.232233The tokens used for a Response can be read from the `response.done` event, which looks like the following.234235```json236{237 "type": "response.done",238 "response": {239 ...240 "usage": {241 "total_tokens": 253,242 "input_tokens": 132,243 "output_tokens": 121,244 "input_token_details": {245 "text_tokens": 119,246 "audio_tokens": 13,247 "image_tokens": 0,248 "cached_tokens": 64,249 "cached_tokens_details": {250 "text_tokens": 64,251 "audio_tokens": 0,252 "image_tokens": 0253 }254 },255 "output_token_details": {256 "text_tokens": 30,257 "audio_tokens": 91258 }259 }260 }261}262```263264## Input transcription costs265266Aside from conversational Responses, the Realtime API bills for input transcriptions, if enabled. Input transcription uses a different model than the speech2speech model, such as [`whisper-1`](https://developers.openai.com/api/docs/models/whisper-1) or [`gpt-4o-transcribe`](https://developers.openai.com/api/docs/models/gpt-4o-transcribe), and thus are billed from a different rate card. Transcription is performed when audio is written to the input audio buffer and then committed, either manually or by VAD.267268Input transcription token counts can be read from the `conversation.item.input_audio_transcription.completed` event, as in the following example.269270```json271{272 "type": "conversation.item.input_audio_transcription.completed",273 ...274 "transcript": "Hi, can you hear me?",275 "usage": {276 "type": "tokens",277 "total_tokens": 26,278 "input_tokens": 17,279 "input_token_details": {280 "text_tokens": 0,281 "audio_tokens": 17282 },283 "output_tokens": 9284 }285}286```287288## Caching289290Realtime API supports [prompt caching](https://developers.openai.com/api/docs/guides/prompt-caching), which is applied automatically and can dramatically reduce the costs of input tokens during multi-turn sessions. Caching applies when the input tokens of a Response match tokens from a previous Response, though this is best-effort and not guaranteed.291292The best strategy for maximizing cache rate is keep a session’s history static. Removing or changing content in the conversation will “bust” the cache up to the point of the change — the input no longer matches as much as before. Note that instructions and tool definitions are at the beginning of a conversation, thus changing these mid-session will reduce the cache rate for subsequent turns.293294## Truncation295296When the number of tokens in a conversation exceeds the model's input token limit the conversation be truncated, meaning messages (starting from the oldest) will be dropped from the Response input. A 32k context model with 4,096 max output tokens can only include 28,224 tokens in the context before truncation occurs.297298Clients can set a smaller token window than the model’s maximum, which is a good way to control token usage and cost. This is controlled with the `token_limits.post_instructions` configuration (if you configure truncation with a `retention_ratio` type as shown below). As the name indicates, this controls the maximum number of input tokens for a Response, except for the instruction tokens. Setting `post_instructions` to 1,000 means that items over the 1,000 input token limit won't be sent to the model for a Response.299300Truncation busts the cache near the beginning of the conversation, and if truncation occurs on every turn then cache rate will be very low. To mitigate this issue clients can configure truncation to drop more messages than necessary, which will extend the headroom before another truncation is needed. This can be controlled with the `session.truncation.retention_ratio` setting. The server defaults to a value of `1.0` , meaning truncation will remove only the items necessary. A value of `0.8` means a truncation would retain 80% of the maximum, dropping an additional 20%.301302If you’re attempting to reduce Realtime API cost per session (for a given model), we recommend reducing limiting the number of tokens and setting a `retention_ratio` less than 1, as in the following example. Remember that there may be a tradeoff here in terms of lower cost but lower model memory for a given turn.303304```json305{306 "event": "session.update",307 "session": {308 "truncation": {309 "type": "retention_ratio",310 "retention_ratio": 0.8,311 "token_limits": {312 "post_instructions": 8000313 }314 }315 }316}317```318319Truncation can also be completely disabled, as shown below. When disabled an error will be returned if the Conversation is too long to create a Response. This may be useful if you intend to manage the Conversation size manually.320321```json322{323 "event": "session.update",324 "session": {325 "truncation": "disabled"326 }327}328```329330## Other optimization strategies331332### Using a mini model333334The Realtime speech2speech models come in a “normal” size and a mini size, which is significantly cheaper. The tradeoff here tends to be intelligence related to instruction following and function calling, which won't be as effective in the mini model. We recommend first testing applications with the larger model, refining your application and prompt, then attempting to optimize using the mini model.335336### Editing the Conversation337338While truncation will occur automatically on the server, another cost management strategy is to manually edit the Conversation. A principle of the API is to allow full client control of the server-side Conversation, allowing the client to add and remove items at will.339340```json341{342 "type": "conversation.item.delete",343 "item_id": "item_CCXLecNJVIVR2HUy3ABLj"344}345```346347Clearing out old messages is a good way to reduce input token sizes and cost. This might remove important content, but a common strategy is to replace these old messages with a summary. Items can be deleted from the Conversation with a `conversation.item.delete` message as above, and can be added with a `conversation.item.create` message.348349## Estimating costs350351Given the complexity in Realtime API token usage it can be difficult to estimate your costs ahead of time. A good approach is to use the Realtime Playground with your intended prompts and functions, and measure the token usage over a sample session. The token usage for a session can be found under the Logs tab in the Realtime Playground next to the session id.352353