GPT Audio Guide: Speech In, Speech Out Over Chat Completions

There are two common ways to make an application talk. One chains three models: speech-to-text, a text model, then text-to-speech. The other hands audio to a single model and gets audio back. gpt-audio is OpenAI's model for the second approach over an ordinary request-response API, and it trades some flexibility for a much simpler pipeline.

OpenAI's model page describes it as the company's first generally available audio model. It accepts text and audio, produces text and audio, and is used through the Chat Completions endpoint. That last part is what separates it from OpenAI's realtime voice models, and it is the first thing to understand before choosing it.

What gpt-audio is, and what it is not

The published specification is short:

• Input: text and audio. No image input.
• Output: text and audio.
• Context window: 128,000 tokens, with up to 16,384 tokens of output.
• Snapshot: gpt-audio-2025-08-28 is the default and only listed snapshot.
• Knowledge cutoff: 1 October 2023.
• Features: streaming and function calling.

Two of those lines deserve attention. The knowledge cutoff is old, so do not rely on the model for anything recent; pass current facts in the prompt or through a tool. And OpenAI's page lists only streaming and function calling as supported features. Some catalogues list structured outputs for this model. Where they disagree with the vendor, trust the vendor and validate any JSON yourself.

It is also not a reasoning model in the GPT-6 sense. There is no effort setting and no 1M window. It is a conversational model built around voice, and its context is sized for a conversation, not a codebase.

Audio tokens are priced differently

This is where budgets go wrong. OpenAI prices gpt-audio in two rates:

• Text tokens: $2.50 per million input, $10 per million output.
• Audio tokens: $32 per million input, $64 per million output.

Catalogue listings, including OpenRouter's at the time of writing, often show only the text rates. If you budget from those, a voice application will cost several times what you planned, because in a voice app most of the tokens are audio. Audio output is priced over six times the text output rate.

The ratio of audio to text tokens per second of speech is not something to guess. Send a dozen representative clips, read the token counts from the usage object in each response, and work out your own cost per minute of input and output speech. That single measurement is the most important number in a voice-app budget. Input vs output token pricing explains why the output side usually dominates.

Chat Completions, not Realtime

OpenAI's model page lists Chat Completions as the only supported endpoint. Realtime, the Responses API, Batch, fine-tuning and the dedicated speech and transcription endpoints are all listed as unsupported for this model.

In practice that means each turn is a complete request: you send the user's recorded audio, the model responds, and you play the result. Streaming helps you start playback before the response finishes, but this is not a live, interruptible conversation over a persistent connection. For a phone agent where users talk over the assistant, a realtime model is the better fit. For voice notes, audio replies in a messaging app, spoken summaries or turn-based assistants, the request-response model is simpler to build and easier to debug.

No Batch support also means no half-price asynchronous option. If you are processing a large archive of recordings offline, a transcription model followed by a cheap text model will usually cost far less.

gpt-audio or gpt-audio-1.5

OpenAI also documents gpt-audio-1.5, which it describes as its best voice model for audio in and audio out with Chat Completions. It has the same context, output limit, endpoint and prices as gpt-audio, with a later knowledge cutoff of 30 September 2024.

With identical pricing, the newer model is the sensible starting point for new work. Keep gpt-audio where you have already tuned prompts and voice behaviour against it, and pin the dated snapshot so the voice does not change under you. There is also a smaller sibling; the GPT Audio Mini guide covers when the cheaper option is enough.

When a three-model pipeline wins

A single audio model is not automatically better. A transcription model, a text model and a speech model chained together has real advantages:

• You can use a strong current text model for the reasoning, rather than one with a 2023 knowledge cutoff.
• You get a transcript for free, which you need for logging, search and moderation anyway.
• Each stage can be swapped or cached independently, and the text stage can use batch pricing.

The single-model approach wins on latency per turn, on fewer moving parts, and on preserving tone and emphasis that a transcript throws away. If your users care how the assistant sounds and how quickly it answers, gpt-audio is the simpler build. If they care most about what it says, the pipeline usually gives you a better answer for less money.

A practical starting checklist

1. Measure audio tokens per minute from real clips before quoting any cost.
2. Start on gpt-audio-1.5 unless you have a reason to stay on the older snapshot.
3. Give the model current facts through tools or the prompt; its own knowledge stops in 2023.
4. Validate any structured output in code rather than relying on a schema feature.
5. If you need interruption or full-duplex conversation, evaluate a realtime model instead.

Because it is served through Chat Completions, most OpenAI-compatible client libraries can call it with small changes. What OpenAI-compatible actually means covers the places where audio payloads are one of the first things to break across providers.