Preços da API Realtime da GPT: Falar Custa 4x Mais que Ouvir (Medido)

Uma conversa por voz na API Realtime da OpenAI custa US$ 0,0192 por minuto enquanto o usuário fala e US$ 0,0768 por minuto enquanto o modelo responde. Falar custa exatamente quatro vezes mais do que ouvir, e essa única proporção explica a maior parte da conta de uma sessão de voz. Uma observação sobre nomes antes dos números: “GPT Live” é o recurso do ChatGPT voltado ao consumidor e não tem API. Os produtos de API por trás dele são gpt-realtime-2.1 e gpt-realtime-2.1-mini, e são esses que este post mede.

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: US$ 0,0192 por minuto para ouvir, US$ 0,0768 por minuto para falar.
• Sessenta segundos de silêncio sob server VAD cobraram zero tokens de entrada.
• O cache automático cobriu 93% da entrada no turno 30; apagar um item do histórico triplicou a entrada a preço cheio em um turno.
• Cancelar uma resposta falada longa após 2 segundos cobrou 4 segundos de áudio.
• gpt-realtime-2.1-mini tem a mesma mecânica de cobrança, com preços de áudio 3,2x menores.

Todos os números aqui vêm de sessões WebSocket instrumentadas, executadas contra os dois modelos em 2026-07-19, com cada evento do servidor registrado. Os dois modelos estão no ar no endpoint /v1/realtime do gateway da Synthorai, que foi onde essas sessões rodaram; o protocolo e a cobrança são iguais aos de falar direto com a OpenAI. O harness é um único arquivo Python usando só a stdlib, e cada valor abaixo remonta a um registro de uso response.done bruto.

Como conectar à API Realtime?

Diferente das APIs de texto, a Realtime não é request/response sobre HTTP. Você abre um WebSocket por sessão e troca eventos JSON por ele: o cliente envia o áudio do microfone em streaming, o servidor devolve o áudio falado em streaming, e uma única conexão carrega toda a conversa.

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 de vida da sessão que importa para a cobrança: session.update define instructions, voice, tools e detecção de turno (isso vira o prefixo passível de cache); input_audio_buffer.append / commit adicionam áudio do usuário; response.create dispara uma resposta; e cada response.done carrega o detalhamento completo de uso daquela resposta. Uma observação sobre dialeto: a API GA usa output_modalities e uma configuração aninhada audio.input/audio.output; o campo response.modalities da era beta é rejeitado com unknown_parameter.

Quanto custa o GPT Realtime por minuto?

As taxas oficiais de conversão batem até o último token: um clipe de 30,0 segundos foi cobrado como 300 input audio tokens (1 a cada 100 ms), e uma resposta falada de 4,5 segundos foi cobrada como 90 output audio tokens (1 a cada 50 ms). Isso transforma a tabela de preços por token em cálculo por minuto:

Dois custos ficam de fora da tabela. Primeiro, uma resposta falada também cobra text output: a transcrição mais os reasoning tokens (gpt-realtime-2.1 faz reasoning; output_token_details.reasoning_tokens voltou diferente de zero em todas as execuções). Na nossa resposta de teste curta isso somou cerca de 24% em cima dos audio tokens, cobrados à taxa de texto de $24/M.

Segundo, o add-on de transcrição é uma faixa de cobrança própria. Seu registro de uso aparece como {"type": "duration", "seconds": 30}: cobrado por duração a $0.017 por minuto, independente de tokens, e a transcrição nunca entra no input do modelo. Ativar essa flag praticamente dobra o custo do lado de input no 2.1 e quase quadruplica no mini, então ligue apenas onde uma exigência de compliance ou de produto realmente precise do texto.

Silêncio, interrupção ou tool calling custam alguma coisa?

Silêncio não custa nada. Enviamos 60 segundos de silêncio em streaming para uma sessão com server VAD habilitado e depois fizemos uma pergunta: o uso foi idêntico byte a byte ao de uma sessão de controle que nunca enviou áudio. O VAD só faz commit do áudio que detecta como fala, então música de espera, um cliente lendo um formulário ou uma linha ociosa aberta cobram zero input tokens. A ressalva é que ruído de fundo real pode disparar o VAD; silêncio puro é o piso, não uma garantia para uma ligação barulhenta.

Interrupções são cobradas até a fronteira da geração, não até o ouvido do usuário, e nunca pelo restante que não foi gerado. Pedimos uma contagem falada lenta até quarenta e cancelamos após ouvir 2,0 segundos: a cobrança foi de 81 audio tokens, ou 4,0 segundos. Os 2 segundos de sobra são o quanto a geração adiantou em relação à reprodução antes de o response.cancel chegar. No mini o mesmo experimento cobrou 6,3 segundos, porque o modelo menor gera mais à frente do tempo real. A regra prática: envie response.cancel no instante em que o cliente detectar barge-in, porque o medidor roda até o cancel chegar.

Tool calls são neutras em cobrança. Uma sessão com uma definição de função emitiu a chamada, recebeu o resultado injetado, e a resposta seguinte mostrou 99% do input cobrado à taxa de cache. Os itens de function-call e suas saídas entram em cache como qualquer outro histórico anexado, e as próprias definições de tool ficam no prefixo estático que passa a ser cacheado a partir do turno 2.

Como o cache mantém sessões longas acessíveis?

A Realtime API relê toda a conversa como input a cada resposta, então o input por turno cresce linearmente com o tamanho da sessão. O que mantém isso viável é o cache automático de prefixo: o áudio em cache é cobrado a $0,40/M em vez de $32/M, ou seja, 1/80 do preço cheio. Na nossa sessão de 30 turnos, a fatia em cache subiu de forma constante até chegar a 93% do input no turno 30:

A divisão do cache é reportada 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 }
  }
}

Três detalhes que a documentação oficial não menciona, todos medidos por nós: o cache entra em ação com cerca de 128 tokens de prefixo (o mínimo documentado da API de texto é 1.024), avança em blocos de 64 tokens, e o prefixo estático pode ser reaproveitado entre sessões na mesma chave. Esse último ponto importa para o limite de 60 minutos por sessão: o primeiro turno de uma sessão nova já cobra as instruções na taxa de cache, então a rotação só paga preço cheio 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 exatamente essa penalidade. Apagar um item antigo no meio da sessão derrubou a fatia em cache por exatamente um turno, e depois o cache se reconstruiu:

Mais um alívio medido: as próprias respostas faladas do modelo voltam aos inputs seguintes como texto, não como áudio. Em uma conversa por voz de 8 turnos, o áudio de input cresceu a cada turno exatamente pelo tamanho do clipe do usuário, enquanto o lado do assistente reapareceu como tokens de transcrição a $4/M. A parte cara do termo que se acumula é só o áudio do usuário.

O manual que sai disso é curto: mantenha o histórico apenas com acréscimos, mantenha as instruções e definições de ferramentas byte a byte idênticas durante toda a sessão (e entre sessões), coloque tudo que for dinâmico na última mensagem do usuário em vez de no prefixo, e quando precisar cortar, corte raramente e em grandes passos em vez de a cada turno. Para a mecânica geral entre provedores, veja nosso guia de prompt caching e o estudo com os mínimos de cache medidos.

gpt-realtime-2.1 vs mini: qual escolher?

A mecânica de cobrança é idêntica nos dois modelos: mesmas taxas de conversão, mesma quantização de cache de 64 tokens, mesmo formato de curva. O que muda é preço e comportamento:

Dois detalhes que valem atenção. Na faixa de replay em cache a diferença de preço quase some ($0.40 vs $0.30), então uma sessão longa e muito cacheada reduz um pouco a vantagem do mini, embora os tokens novos ainda dominem o total. E a velocidade do mini joga contra ele nas interrupções: ele gera mais adiantado em relação à reprodução, então cada barge-in descarta cerca do dobro de áudio já gerado. Em dólares o mini continua ganhando em todos os cenários que medimos; a diferença de preço de 3,2x absorve os dois efeitos.

Use o mini por padrão em assistentes de comando curto, IVR e suporte de alta concorrência. Use o 2.1 quando a sessão exige orquestração complexa de ferramentas ou raciocínio de várias etapas; a OpenAI o posiciona como flagship para seguir instruções, algo que nosso harness de custo deliberadamente não avalia.

Quanto custam, de fato, os cenários de voz mais comuns?

Para cenários com muitas interrupções, some a sobra do barge-in à sua conta por interação: cada interrupção custa o áudio que o usuário ouviu mais alguns segundos de geração adiantada.

FAQ

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

Não. O GPT Live é o recurso de voz dentro dos apps do ChatGPT e não tem API nem página de preços própria. Quem quer essa experiência via programação usa os modelos da Realtime API gpt-realtime-2.1 e gpt-realtime-2.1-mini, cujos preços este post mede.

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. Dá para reinjetar o histórico de texto numa sessão nova (cobrado uma vez a preço cheio, enquanto o prompt estático continua em cache), mas o áudio do assistente não pode ser reproduzido de novo. Ou seja, produtos de voz de longa duração precisam de um plano de rotação antes do minuto 60.

Existe timeout por inatividade entre os turnos?

Não há timeout por inatividade documentado, e nas nossas medições o silêncio cobra zero tokens sob VAD do servidor. Manter a linha aberta entre interações não custa nada além da própria conexão. Para produtos de uso esparso, uma sessão longa fica mais barata e mais rápida do que reconectar a cada interação, já que a configuração medida levou cerca de 2,5 segundos.

Qual formato de áudio a API espera?

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

Os padrões de engenharia para conviver com o limite de 60 minutos (rotação, repasse de histórico, o que sobrevive a uma reconexão) são um tópico à parte, e os números deste post são as entradas para essa conta. Para entender como os tokens cobrados se dividem entre as famílias na API de texto, veja o post complementar sobre a anatomia do uso de tokens.

← Voltar ao blog