OpenAI inclui gpt-realtime-1.5 na Realtime API

Introdução

A OpenAI adicionou o gpt-realtime-1.5 à Realtime API, palavra-chave central para quem constrói agentes de voz e fluxos multimodais com tool calling. O modelo é apresentado pela OpenAI como sua melhor opção de voz, com áudio como entrada e saída, suporte a ferramentas e foco em baixa latência, um pacote que mira desde assistentes de atendimento até copilotos em apps.

Na documentação oficial, o gpt-realtime-1.5 combina texto, imagem como entrada e áudio bidirecional, além de expor endpoints padronizados e preços específicos para tokens de texto, imagem e áudio. A proposta é clara, acelerar workflows de voz, reduzir a engenharia manual de integrações e aproximar o API do que se espera de um agente em produção.

Por que o gpt-realtime-1.5 muda o jogo para voz

O gpt-realtime-1.5 foi desenhado para experiência de fala em tempo real. Ele aceita áudio como entrada e produz áudio como saída, mantém baixa latência por WebRTC ou WebSocket e oferece contexto de 32 mil tokens com até 4.096 tokens de saída por resposta. Em termos práticos, isso permite manter histórico suficiente de chamadas longas, transcrever, raciocinar e responder por voz sem quedas bruscas de contexto.

Outro ponto que pesa na adoção é o suporte nativo a function calling, base para tool calling estruturado. Isso viabiliza que o agente de voz invoque ferramentas de forma previsível, como consultar um CRM, orquestrar um pagamento ou puxar dados de estoque, mantendo o diálogo contínuo no canal de áudio. Na documentação do modelo, function calling aparece como um recurso suportado, o que simplifica a implementação de pipelines consistentes.

No preço, a OpenAI lista valores diferenciados por modalidade. Para texto, a tabela mostra 4 dólares por 1 milhão de tokens de entrada, 0,40 para tokens em cache e 16 dólares por 1 milhão de tokens de saída. Para áudio, 32 dólares por 1 milhão de tokens de entrada, 0,40 em cache e 64 por 1 milhão de tokens de saída. Imagem como entrada parte de 5 dólares por 1 milhão de tokens, 0,50 para cache. Esses números ajudam a estimar custos por minuto e por sessão ao projetar contact centers ou assistentes embarcados.

![Microfone de estúdio para fluxos de voz]

O que há de novo na Realtime API para produção

Além do novo modelo, a OpenAI vem atualizando a Realtime API com recursos que reduzem trabalho de integração. Entre os destaques recentes estão o suporte a servidores MCP remotos, que permite apontar a sessão Realtime para um servidor de ferramentas e deixar o API gerenciar as chamadas para você, eliminando o fio a fio manual. Há também suporte a imagem como entrada, algo útil para ancorar a conversa naquilo que o usuário está vendo, e suporte a SIP, que conecta facilmente a rede telefônica pública e PBXs. Por fim, a ideia de prompts reutilizáveis ajuda a padronizar comportamento entre sessões.

Essas capacidades colocam a Realtime API em um patamar mais próximo do que times precisam para levar agentes de voz a produção, principalmente quando se fala de telefonia, roteamento e ferramentas corporativas. Em termos arquiteturais, a adoção de MCP e SIP reduz a necessidade de middlewares customizados e acelera iterações.

Arquitetura de referência, do browser ao contact center

A abordagem recomendada pela documentação é usar WebRTC no navegador para comunicação de baixa latência com o modelo Realtime, e WebSocket no servidor quando necessário. Para quem vai construir do zero, o ponto de partida sugerido é o Agents SDK para TypeScript, pensado para orquestrar sessões e mídia com o gpt-realtime-1.5. Essa base técnica resolve streaming, controle de sessão e event handling, deixando o time focar no domínio do negócio.

No contact center, a linha é parecida, mas com SIP na traseira. Conectar um PBX ou um provedor de telefonia e usar a sessão Realtime como cérebro do agente vai exigir mapear intents, desenhar ferramentas e criar salvaguardas. Com o suporte a MCP remoto, muitas dessas integrações viram configuração, não código. Isso tende a encurtar o tempo entre POC e produção, especialmente em ambientes que já possuem serviços expostos via MCP.

Preços, limites e impacto no TCO

Para dimensionar custos, os preços do gpt-realtime-1.5 publicados pela OpenAI ajudam a fechar a conta por canal. Como referência, texto a 4 dólares por milhão de tokens de entrada e 16 dólares por milhão de saída, áudio a 32 dólares por milhão de entrada e 64 por milhão de saída, imagem a 5 dólares por milhão de entrada. Em cenários de voz, o tráfego de áudio costuma dominar, então vale modelar duração média de chamadas, taxa de fala e compressão do codec para projetar o gasto mensal.

Em limites de uso, a página do modelo lista tiers com RPM, TPM e RPD variando por nível de consumo, com destaque de que o Realtime opera em múltiplos endpoints, incluindo v1/realtime, v1/responses e v1/chat/completions. Isso permite padronizar integrações, reaproveitar bibliotecas e gradualmente migrar workloads.

Uma decisão prática é habilitar caching de entrada quando fizer sentido, já que o preço de tokens em cache cai para 0,40 por milhão em texto e também há desconto em áudio e imagem. Em fluxos com prompts e contextos estáveis, esse ajuste reduz custo sem penalizar a experiência.

Tool calling na prática, do function calling ao MCP

Na camada de ferramentas, dá para começar com function calling tradicional, definindo schemas e deixando o modelo decidir quando e como chamar a função. Isso cobre desde checar status de pedido até agendar um horário. Quando o portfólio de integrações cresce, o suporte a MCP remoto simplifica, já que a sessão aponta para um servidor MCP e a Realtime API orquestra as chamadas. Essa abordagem tende a padronizar autenticação, logging e segurança.

Alguns padrões que funcionam bem em produção:

Encapsular cada sistema backend em uma ferramenta com schema validado.
Usar um barramento de eventos para auditar chamadas de ferramentas e respostas.
Definir SLAs por ferramenta e timeouts específicos, com fallback de resposta amigável.
Manter prompts reutilizáveis com variáveis de negócio e guardrails claros.

Qualidade de voz e UX, lições do campo

A camada de UX tem tanto peso quanto a do modelo. Em voz, silêncio é latência perceptível. O WebRTC reduz esse tempo, mas a aplicação precisa sinalizar turn-taking com efeitos sonoros leves, partial responses e barge-in controlado. A Realtime API foi projetada para esse loop de diálogo, então vale testar interrupção, overtalk e detecção de fim de fala em condições reais, como ruído de rua ou call center.

Também é prudente calibrar a persona de voz, as vozes disponíveis e o estilo de resposta por canal. Para suporte, respostas mais diretas resolvem objeções rápidas. Para vendas consultivas, respostas que confirmam intenção e oferecem opções tendem a melhorar conversão. O recurso de prompts reutilizáveis ajuda a manter consistência.

![Visualização de waveform para agentes de voz]

Segurança, privacidade e governança

A OpenAI descreve camadas de segurança para o Realtime, incluindo monitoramento automatizado e revisão humana de conteúdo sinalizado, além do alinhamento com avaliações do Preparedness Framework. Em ambientes sensíveis, é recomendável adicionar mascaramento de PII antes de enviar áudio ao modelo, guardar somente metadados não sensíveis e registrar tool calls para auditoria. Essas práticas reduzem risco de vazamento e apoiam compliance.

Para governança, sugere-se estabelecer trilhas de auditoria de sessão, versionar prompts e snapshots de modelos quando disponíveis, além de políticas de retenção de áudio e texto. Em cenário multi-equipe, um catálogo de ferramentas MCP com donos claros acelera evolução sem perder controle.

Roadmap de adoção em 30, 60 e 90 dias

Dias 0 a 30, MVP com WebRTC no navegador, gpt-realtime-1.5 como motor, uma ferramenta simples de dados internos via function calling e medição básica de latência ponta a ponta.
Dias 31 a 60, integrar SIP para um piloto telefônico, estruturar prompts reutilizáveis por jornada, ligar um servidor MCP remoto com duas ou três ferramentas e iniciar logging de tool calls.
Dias 61 a 90, expandir catálogo de ferramentas, ativar caching para contextos estáveis, incluir imagem de entrada quando útil e definir SLAs por canal, com alarmes em tempo real.

Benchmarks e limites práticos

O gpt-realtime-1.5 expõe um conjunto de limites úteis para planejamento de capacidade. A página do modelo mostra janelas de contexto de 32 mil tokens, máximo de 4.096 tokens de saída e diferentes níveis de rate limit por tier. Esses números, junto de testes de latência com infraestrutura real, guiam dimensionamento de canais simultâneos e políticas de fila.

Em cenários com picos previsíveis, como campanhas ou contas corporativas, faz sentido negociar aumento de limites por tier e preparar degradação graciosa quando o sistema se aproximar do teto, por exemplo, alternando para respostas mais curtas quando a fila crescer.

Exemplos práticos de uso

Atendimento ao cliente, autenticação por voz, verificação de status e abertura de tickets com tool calling, mantendo o usuário em áudio, sem redirecionamentos.
Agentes em apps móveis, push to talk com WebRTC, análise de imagens enviadas pelo usuário e execução de ações via MCP, como checar frete e estoque.
Suporte técnico interno, triagem por voz, leitura de screenshots e automação de passos em ferramentas internas com logs centralizados.

Métricas que importam

Latência média do primeiro byte de áudio gerado, alvo abaixo de 300 ms em redes estáveis.
Taxa de interrupção bem sucedida, barge-in sem perda de contexto.
Precisão de tool calling, proporção de execuções corretas por intenção.
Custo por sessão e por minuto de voz, combinando preços de texto e áudio do gpt-realtime.

Considerações finais

O gpt-realtime-1.5 chega alinhado ao que o mercado de agentes de voz vinha pedindo, mais controle, integrações maduras e custos previsíveis. A combinação com SIP, MCP e prompts reutilizáveis tira atrito de engenharia e abre espaço para que equipes foquem em UX e automação de ponta a ponta. Para quem precisa de voz natural, rápida e acionável, a direção é promissora.

A recomendação é experimentar cedo, medir obsessivamente e padronizar ferramentas. Com base nos preços e limites da própria OpenAI e no design de baixa latência da Realtime API, a curva de adoção pode ser mais curta do que em projetos de NLU clássicos. O resultado esperado é um agente de voz que ouve, vê, fala e age em tempo real, com governança adequada e custo sob controle.