Preços da API GPT Realtime: falar custa 4x mais que ouvir (medido)

Uma conversa por voz na Realtime API da OpenAI custa $0.0192 por minuto enquanto o usuário fala e $0.0768 por minuto enquanto o modelo responde. Falar custa exatamente quatro vezes mais que ouvir, e essa proporção explica a maior parte da conta de uma sessão de voz. Antes dos números, vale esclarecer os nomes: “GPT Live” é o recurso do ChatGPT para o consumidor e não oferece uma API. Os produtos de API por trás dele são gpt-realtime-2.1 e gpt-realtime-2.1-mini, e são eles que medimos neste artigo.

TL;DR

• gpt-realtime-2.1 cobra exatamente 1 token de áudio a cada 100 ms de fala do usuário e 1 a cada 50 ms de fala do modelo: $0.0192 por minuto para ouvir e $0.0768 por minuto para falar.
• Sessenta segundos de silêncio com server VAD não geraram nenhum token de entrada.
• O cache automático cobriu 93% da entrada no turno 30; excluir um item do histórico triplicou a entrada cobrada pelo preço integral durante um turno.
• Cancelar uma resposta falada longa após 2 segundos gerou cobrança por 4 segundos de áudio.
• gpt-realtime-2.1-mini usa a mesma mecânica de cobrança, com preços de áudio 3.2x menores.

Todos os números vêm de sessões WebSocket instrumentadas, executadas nos dois modelos em 2026-07-19, com registro de cada evento do servidor. Os dois modelos estão disponíveis no endpoint /v1/realtime do gateway da Synthorai, onde as sessões foram executadas. O protocolo e a cobrança são os mesmos de uma conexão direta com a OpenAI. O harness é um único arquivo Python que usa apenas a stdlib, e cada número abaixo pode ser rastreado até um registro bruto de uso em response.done.

Como se conectar à Realtime API?

Ao contrário das APIs de texto, a Realtime não usa o modelo de request/response sobre HTTP. Cada sessão abre um WebSocket e troca eventos JSON por essa conexão: o cliente envia o áudio do microfone em streaming, o servidor devolve áudio falado em streaming, e toda a conversa passa pela mesma conexão.

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

O ciclo da sessão que afeta a cobrança funciona assim: session.update define instruções, voz, tools e detecção de turno, formando o prefixo que pode entrar em cache; input_audio_buffer.append / commit adicionam o áudio do usuário; response.create dispara uma resposta; e cada response.done traz o detalhamento completo de uso daquela resposta. Há uma diferença de sintaxe importante: a API GA usa output_modalities e uma configuração aninhada em audio.input/audio.output; o campo response.modalities, usado na versão beta, é rejeitado com unknown_parameter.

Quanto custa o GPT Realtime por minuto?

As taxas oficiais de conversão bateram exatamente no nível do token: um trecho de 30.0 segundos gerou 300 tokens de áudio de entrada, ou 1 a cada 100 ms, enquanto uma resposta falada de 4.5 segundos gerou 90 tokens de áudio de saída, ou 1 a cada 50 ms. Aplicando essas taxas aos preços por token, chegamos ao custo por minuto:

A tabela não inclui dois custos. Primeiro, uma resposta falada também cobra pela saída de texto: a transcrição e os tokens de raciocínio (gpt-realtime-2.1 raciocina; output_token_details.reasoning_tokens retornou um valor diferente de zero em todas as execuções). Na resposta curta usada no teste, isso acrescentou cerca de 24% ao custo dos tokens de áudio, com cobrança pela tarifa de texto de $24/M.

Segundo, o adicional de transcrição é uma faixa de cobrança separada. Seu registro de uso contém {"type": "duration", "seconds": 30}: a cobrança é por duração, a $0.017 por minuto, independentemente dos tokens, e a transcrição nunca entra no input do modelo. Ativar apenas essa opção praticamente dobra o custo de entrada no 2.1 e quase o quadruplica no mini. Use-a somente quando um requisito de compliance ou do produto realmente exigir o texto.

Silêncio, interrupções e chamadas de tools têm custo?

Silêncio não custa nada. Enviamos 60 segundos de silêncio para uma sessão com server VAD habilitado e, em seguida, fizemos uma pergunta. O uso foi idêntico, byte por byte, ao de uma sessão de controle que não enviou áudio. O VAD só faz commit do áudio que identifica como fala. Música de espera, um cliente lendo um formulário ou uma linha ociosa aberta, portanto, geram zero token de entrada. Ruído de fundo real pode acionar o VAD; silêncio puro representa o custo mínimo, não uma garantia para chamadas ruidosas.

Interrupções são cobradas até o ponto em que a geração chegou, não até o que o usuário ouviu, e nunca incluem o trecho que ainda não foi gerado. Pedimos uma contagem falada lentamente até quarenta e cancelamos depois de ouvir 2.0 segundos: a cobrança foi de 81 tokens de áudio, equivalentes a 4.0 segundos. Essa diferença de 2 segundos corresponde ao quanto a geração estava à frente da reprodução quando response.cancel chegou. No mini, o mesmo experimento cobrou 6.3 segundos, pois o modelo menor gera mais à frente do tempo real. Na prática, envie response.cancel assim que o cliente detectar que o usuário começou a falar, porque a cobrança continua até o cancelamento chegar.

Chamadas de tools não alteram a cobrança. Uma sessão com uma definição de função emitiu a chamada, recebeu o resultado injetado e mostrou 99% da entrada seguinte cobrada pela tarifa de cache. Itens de chamada de função e suas saídas entram em cache como qualquer outro item adicionado ao histórico. As próprias definições das tools ficam no prefixo estático, que entra em cache a partir do turno 2.

Como o cache mantém sessões longas economicamente viáveis?

A Realtime API relê toda a conversa como entrada a cada resposta. Por isso, o input por turno cresce linearmente com a duração da sessão. O prefix caching automático controla esse custo: replays de áudio em cache custam $0.40/M, em vez de $32/M, ou 1/80 do preço integral. Na sessão de 30 turnos, a parcela em cache cresceu continuamente e chegou a 93% da entrada no turno 30:

A divisão entre tokens em cache e sem cache aparece em cada 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 }
  }
}

Medimos três características que a documentação oficial não especifica: o cache começa a ser aplicado com aproximadamente 128 tokens de prefixo, enquanto o mínimo documentado para a API de texto é 1,024; ele avança em blocos de 64 tokens; e o prefixo estático pode ser reutilizado entre sessões que usam a mesma key. Esse último ponto faz diferença por causa do limite de 60 minutos por sessão: já no primeiro turno de uma nova sessão, as instruções foram cobradas pela tarifa de cache. Assim, a rotação só paga o preço integral para reler o histórico da conversa, não o system prompt.

Editar o histórico é a única forma de perder o desconto, e medimos a penalidade exata. Ao excluir um item antigo no meio da sessão, a parcela em cache caiu durante exatamente um turno e depois se recuperou:

Também medimos outro fator que reduz o custo: as respostas faladas do próprio modelo voltam aos inputs seguintes como texto, não como áudio. Em uma conversa de voz com 8 turnos, o áudio de entrada cresceu exatamente na proporção do trecho enviado pelo usuário em cada turno. O lado do assistente reapareceu como tokens de transcrição a $4/M. Na parcela do custo que se acumula ao longo da sessão, apenas o áudio do usuário é caro.

As recomendações práticas são simples: mantenha o histórico append-only; preserve instruções e definições de tools byte por byte durante toda a sessão e entre sessões; coloque qualquer conteúdo dinâmico na mensagem mais recente do usuário, não no prefixo; e, quando precisar reduzir o histórico, faça cortes grandes e pouco frequentes, em vez de cortar a cada turno. Para entender a mecânica geral entre diferentes providers, consulte nosso guia de prompt caching e o estudo sobre mínimos de cache medidos.

gpt-realtime-2.1 ou mini: qual escolher?

A mecânica de cobrança é idêntica nos dois modelos: mesmas taxas de conversão, mesma quantização do cache em blocos de 64 tokens e curvas com o mesmo formato. Preço e comportamento são diferentes:

Dois detalhes merecem atenção. Na faixa de replay em cache, a diferença de preço quase desaparece ($0.40 contra $0.30). Assim, em uma sessão longa com alto aproveitamento de cache, a vantagem do mini diminui um pouco, embora os tokens novos ainda dominem o custo total. Além disso, a velocidade do mini o prejudica nas interrupções: como ele gera mais à frente da reprodução, cada interrupção descarta aproximadamente o dobro de áudio já gerado. Mesmo assim, o mini foi mais barato em todos os cenários medidos; a diferença de preço de 3.2x absorve os dois efeitos.

Use o mini por padrão em assistentes de comandos curtos, IVR e suporte com alta concorrência. Escolha o 2.1 quando a sessão exigir orquestração complexa de tools ou raciocínio em várias etapas. A OpenAI o posiciona como o modelo principal para seguir instruções, algo que nosso harness de custos deliberadamente não avalia.

Quanto custam, na prática, os cenários comuns de voz?

Em cenários com muitas interrupções, inclua o excedente da interrupção no cálculo por interação: cada uma cobra o áudio que o usuário ouviu mais alguns segundos de geração antecipada.

Perguntas frequentes

GPT Live é a mesma coisa que a GPT Realtime API?

Não. GPT Live é o recurso de voz dos aplicativos ChatGPT e não tem API nem página própria de preços. Para oferecer essa experiência via código, os desenvolvedores usam os modelos gpt-realtime-2.1 e gpt-realtime-2.1-mini da Realtime API, cujos preços medimos neste artigo.

Quanto tempo pode durar uma sessão Realtime?

O limite rígido é de sessenta minutos, e uma sessão encerrada não pode ser retomada. É possível reinjetar o histórico de texto em uma nova sessão, com uma cobrança única pelo preço integral enquanto o prompt estático continua em cache. O áudio do assistente, porém, não pode ser reproduzido novamente. Produtos de voz com execução prolongada precisam de um plano de rotação antes do minuto 60.

Existe timeout por inatividade entre turnos?

Não há timeout por inatividade documentado. Em nossa medição, o silêncio com server VAD gerou zero token. Manter a linha aberta entre interações, portanto, não custa nada além da própria conexão. Para produtos de uso esporádico, uma sessão longa é mais barata e mais rápida que uma nova conexão por interação, pois o setup levou cerca de 2.5 segundos.

Qual formato de áudio a API espera?

PCM16 mono a 24 kHz é o padrão tanto para entrada quanto para saída, configurado por audio.input.format e audio.output.format em session.update. A cobrança não depende do formato: os tokens de áudio são calculados apenas pela duração, à taxa de 1 token a cada 100 ms na entrada e 1 a cada 50 ms na saída.

Os padrões de engenharia para lidar com o limite de 60 minutos, como rotação, transferência de histórico e o que sobrevive a uma reconexão, merecem um artigo próprio. Os números deste artigo servem de base para esses cálculos. Para entender como os tokens cobrados se dividem entre as famílias da API de texto, consulte nosso artigo sobre a anatomia do uso de tokens.

← Voltar ao blog