Como testar interrupção de voz em tempo real com o GPT-Live-1 na API?

Você corta a IA no meio da frase porque percebeu que perguntou errado

e ela continua falando, tranquila, respondendo a pergunta velha enquanto você já está tentando fazer a nova

Esse instante é o teste de verdade de qualquer app de voz, e não é sobre timbre bonito 🙂

A OpenAI anunciou em 10 de setembro de 2026 o GPT-Live-1 na API, trazendo conversas de voz full-duplex, melhor aderência a instruções, vozes customizadas e suporte a telefonia (tá tudo no anúncio oficial)

Nas requisições da API o identificador do modelo é gpt-live-1

E o que a gente vai fazer aqui não é montar um produto

é montar o MENOR teste possível de interrupção, olhar os eventos, medir e decidir com evidência se o modelo encaixa no seu caso

O que você precisa antes de conectar o GPT-Live-1

Existe um quickstart oficial de WebRTC pra esse modelo, e ele é um exemplo de navegador mais servidor: conecta entrada de microfone e saída de alto-falante, com um backend Responses capaz de buscar na web

Os pré-requisitos dele são chatinhos e todos importantes:

• microfone (e a gente vai voltar nesse item mais pra frente, porque ele dói)
• a página servida por HTTPS ou em localhost
• um servidor confiável com a chave de API do projeto OpenAI

Que "servidor confiável"? É aquele lugar que não é o navegador do usuário

chave de API em front-end é o clássico dos clássicos, e é o tipo de erro que só aparece quando alguém abre o DevTools 😛

WebRTC ou WebSocket? Essa escolha define quem corta o áudio:

As formas de conexão suportadas pra streaming de áudio são WebRTC, pra aplicações de voz no navegador (as media tracks levam o áudio e um data channel leva os eventos JSON), e WebSocket, pra integrações de áudio no servidor

E o SIP, onde entra? Ele não é uma dessas formas de conexão de streaming: SIP aparece como caminho de integração telefônica, e a gente volta nele lá no fim do post

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 118 aulas
• 4 projetos
• 9h 33min

Conhecer formação

Parece só detalhe de transporte, mas muda quem tem a responsabilidade mais crítica do teste de interrupção: saber quanto do áudio JÁ foi tocado

Ou seja: se você for de WebSocket, o trabalho de parar o playback e tratar a truncagem é SEU

se for de WebRTC, o servidor já tem essa contabilidade do lado dele

Escolha antes de escrever a primeira linha, porque metade do código do teste depende disso

Passo a passo: montando o teste de interrupção

A ideia é ter um app feio, de uma tela, que faça só duas coisas: deixar você falar por cima do modelo e registrar o que aconteceu

1. Escolha o transporte. Se o teste vai rodar no navegador, WebRTC. Se vai rodar no servidor (pensando em telefonia depois), WebSocket

O erro comum deste passo: começar no WebSocket "porque é mais simples de debugar" e esquecer que aí você herda o controle de playback e de truncagem, o que é justamente a parte difícil do teste

2. Crie a sessão. Modelo, voz e modo de delegação são escolhidos na criação da sessão. As instruções da conversa vão em session.instructions e o histórico de mensagens de texto anteriores vai em session.input

sessão:
  model: gpt-live-1
  voice: <a voz que você escolheu>
  delegação: por Responses  ou  pelo cliente
  session.instructions: <sua política de interrupção e estilo>
  session.input: <histórico de mensagens de texto anteriores>

O erro comum deste passo: jogar o histórico dentro das instruções, num paredão de texto só. Histórico tem lugar próprio (session.input), instrução é comportamento

3. Confirme o session.started. Depois de iniciar a sessão por WebRTC ou WebSocket, o servidor envia um evento indicando que a sessão está pronta

O erro comum deste passo: sair mandando áudio antes de ver esse evento e depois culpar o modelo pelo silêncio

4. Escreva a política de interrupção nas instruções. A doc de prompting orienta definir essa política no valor de session.instructions: instruir o modelo a parar de falar quando o usuário interrompe, e ela também oferece um template pronto, com descrição de personalidade e política de backchannel (usar backchannels moderados, pra reconhecer com naturalidade sem competir com a resposta principal)

Papel: atendente de agendamento, objetivo e cordial
Estilo: frases curtas, uma ideia por vez, sem listas faladas
Interrupção: se o usuário começar a falar, pare imediatamente de falar e escute
Backchannel: reconhecimentos curtos e moderados, sem competir com a fala do usuário
Backend: envolva o backend quando precisar consultar ou alterar um agendamento

O espírito aqui é dar ao GPT-Live um objetivo e espaço pra conduzir a conversa: o prompt não precisa prescrever cada pergunta ou cada reconhecimento, mas precisa definir papel, estilo conversacional e quando envolver o backend

O erro comum deste passo: escrever um roteiro linha por linha do que o modelo deve dizer. Aí ele fica preso no roteiro, e um modelo preso em roteiro é péssimo em ser cortado no meio

5. Trate a truncagem. Truncar a última resposta do modelo significa remover da conversa a parte não reproduzida dessa resposta

Isso é sutil e é o coração do teste: se você não truncar, o modelo acha que falou coisas que o usuário nunca ouviu, e a conversa segue apoiada numa memória falsa

Em WebRTC (e também no caminho SIP de telefonia) o servidor mantém o buffer de áudio de saída e sabe quanto já foi tocado. Em WebSocket, o cliente gerencia a reprodução, então cabe a você parar o playback e tratar a truncagem

Tome cuidado! No GPT-Live por WebSocket os eventos session.output_audio.delta não têm campos de timing, e não existe um evento de output-audio-done. Por WebRTC o áudio chega pela media track

O erro comum deste passo: montar sua contabilidade de "quanto já tocou" em cima de um timing que esses eventos não entregam. Se você precisa desse controle no cliente, ele tem que sair do seu player de áudio, não do delta

6. Decida o que fazer com o trabalho do backend que está rodando. Interromper a fala do modelo NÃO cancela automaticamente o trabalho em andamento no backend

A aplicação precisa decidir: cancela, altera ou deixa terminar

O exemplo da própria doc é ótimo: se o usuário troca sexta por quinta, atualize a tarefa ativa e ignore os resultados atrasados que ainda vão chegar referentes a sexta

O erro comum deste passo: deixar o resultado velho voltar pra conversa. O modelo cala bonitinho, você comemora, e trinta segundos depois ele anuncia a disponibilidade de sexta com toda a confiança do mundo 😀

7. Ligue as transcrições. Pra acompanhar a conversa em tempo real existem session.input_transcript.delta pra fala do usuário e session.output_transcript.delta pra fala do assistente

// WebRTC: os eventos JSON chegam pelo data channel
canal.addEventListener("message", (e) => {
  const evento = JSON.parse(e.data)

  switch (evento.type) {
    case "session.started":
      marcar("sessao_pronta")
      break

    case "session.input_transcript.delta":
      // fala do usuário chegando: bom marco pra detectar o barge-in no seu log
      marcar("usuario_falando")
      break

    case "session.output_transcript.delta":
      marcar("assistente_falando")
      break
  }
})

O erro comum deste passo: testar de ouvido, sem log. Você vai jurar que "pareceu rápido" e não vai ter um único número pra defender a decisão depois

Responses ou cliente: qual modo de delegação usar no seu teste

Antes do porquê, o que é: o GPT-Live-1 é um modelo de voz full-duplex, ou seja, escuta e fala ao mesmo tempo, e ele DELEGA raciocínio e uso de ferramentas a um agente de backend

A parte que pensa não é a parte que conversa, e isso é proposital

Existem dois modos de delegação. Na delegação por Responses, o GPT-Live chama o modelo Responses que você escolheu, fornece o contexto da conversa e devolve os resultados pra conversa

Na delegação pelo cliente, a sua aplicação prepara o contexto, roda o agente ou workflow e devolve os resultados ao GPT-Live

A regra de bolso é simples: se o seu "cérebro" já existe e tem cara própria, delegação pelo cliente

se o seu cérebro é basicamente um modelo com ferramentas, delegação por Responses poupa encanamento

E se o seu backend é um workflow que já faz um monte de coisa fora do app, tipo notificações em tempo real pelo n8n, a delegação pelo cliente tende a encaixar melhor, porque o contexto e o controle já moram lá

Tem uma boa prática de payload que vale ouro no teste de interrupção: mantenha payloads estruturados grandes, saídas longas de ferramenta e Markdown de exibição no backend, entregando ao GPT-Live apenas os fatos relevantes pra ele escolher COMO dizer

Por que isso importa aqui? Porque o silêncio percebido durante a interrupção nasce justo nesse ponto

se o modelo recebe um caminhão de dados pra digerir e narrar, a retomada depois do corte fica pesada, e o usuário sente a pausa mesmo que tecnicamente tudo esteja funcionando

O que medir: métricas e marcos para decidir com evidência

Sem número, teste de voz vira debate de gosto. A doc de voice agents indica um conjunto bem direto:

1. Taxa de resposta, latência e interrupções, pra avaliar responsividade e turn-taking

2. Duração da fala, pra avaliar verbosidade (modelo prolixo é modelo que apanha mais na interrupção)

3. Silêncio durante a delegação, que é a métrica que expõe atrasos do seu backend, não do modelo

4. Defina um evento observado de início e um de fim pra cada métrica de latência. Essa é a regra que salva o teste de virar achismo, e é o mesmo cuidado de quem vai medir latência real no seu app em vez de olhar número de slide

Os marcos citados são: tempo até a primeira resposta audível, tempo até a delegação, cedência à interrupção (interruption yield), conclusão do backend e conclusão verificada da tarefa

O erro comum deste passo: medir "latência" como uma coisa só. Primeira resposta audível e cedência à interrupção são problemas diferentes, e um pode estar ótimo com o outro horrível

5. Suba a escada de complexidade em vez de tentar tudo de uma vez. Existe um guia de avaliação oficial no Cookbook pro GPT-Live, com três modos: CRAWL (áudio sintético), WALK (áudio gravado) e RUN (conversas multi-turno com interlocutores simulados)

Comece no CRAWL, sempre. É o modo onde você descobre que seu handler de truncagem nunca rodou 😛

O que aprendi testando app gerado por IA com microfone (e por que isso importa aqui)

Aqui eu preciso ser honesto sobre o escopo: essa experiência é com OUTRO produto, não com o GPT-Live-1

No vídeo eu mostro o novo Google AI Studio gerando um app fullstack, e usei a API Live do Google pra parte de conversa por voz

Nada ali envolve o GPT-Live-1 nem teste de barge-in

Ainda assim a lição é exatamente do tamanho deste post

Antes do primeiro prompt eu configurei o projeto escrevendo instruções de sistema fixas (stack, idioma da interface, idioma da conversa, login, persistência e uso de API de voz em tempo real), num arquivo de contexto que me lembrou muito um CLAUDE.md

Depois selecionei os serviços que queria integrar, incluindo banco de dados com autenticação e a opção de criar apps de conversa por voz

E aí veio a parte boa: 1 prompt (o inicial, antes das rodadas de correção de erro) já entregou login com conta Google e persistência funcionando

eu entrei, recarreguei a página e a sessão continuou de pé, massa

A parte de voz em tempo real, porém, simplesmente não respondeu

falei no microfone (que o navegador pediu e eu liberei) e nada voltou, nem depois do próprio ambiente detectar o erro no console e aplicar uma correção que eu dei como resolvida

Copiar o erro do framework e colar de volta no chat pedindo fix é um ciclo que apareceu mais de uma vez ali, e mesmo assim a voz ficou muda

O teste que fechou a questão foi comparativo: deixei 2 microfones abertos ao mesmo tempo, o do playground do próprio ambiente e o do app gerado

funcionou 1, o do playground, que captou a minha fala e transcreveu

o do app continuou mudo, o que isolou o problema no código gerado e não no meu microfone

Depois disso eu pivotei a tela de conversa e pedi um campo de texto na parte inferior, como alternativa pro usuário digitar caso não consiga usar a voz

Puxando pro nosso assunto: captura de microfone é o ponto de falha mais banal e mais frequente de app de voz

e sem áudio de entrada confiável NENHUMA métrica de interrupção significa nada

se o session.input_transcript.delta não traz nada, você não está medindo cedência à interrupção, você está medindo um microfone quebrado

Por isso o teste de dois microfones lado a lado virou hábito aqui: um caminho conhecido que funciona, e o seu, pra comparar

No vídeo você vê o fluxo completo: as instruções de sistema antes do prompt, o app subindo com login e banco, as rodadas de colar erro e pedir correção, e o momento do teste com os dois microfones abertos

O GPT-Live-1 serve para o seu caso? Sinais de sim e de não

A razão técnica citada pra melhora no tratamento de interrupção é bem concreta: um único modelo raciocina sobre o áudio de entrada e de saída em conjunto, evitando a latência e os handoffs frágeis de arquiteturas encadeadas de STT, LLM e TTS

Quem já montou pipeline de voz na mão sabe do que estamos falando: cada costura entre etapas é um lugar onde a interrupção se perde

Tem também um resultado relatado por cliente na avaliação inicial, e a atribuição é da Speak, não minha: a Speak relatou que o GPT-Live-1 deu mais tempo pro aluno pensar antes do tutor responder, reduzindo interrupções em quase 80% em relação aos sistemas anteriores baseados em turnos

É um caso de uso específico (tutoria de idioma), e vale ler como sinal, não como promessa pro seu domínio

Do lado da conta: a sessão de voz custa US$ 0,05 por minuto, cobrado por segundo, e o uso do modelo de backend e das ferramentas é cobrado separadamente

Então o cálculo nunca é só o minuto de voz

Sinais de sim: você já tem um agente de backend que funciona, a conversa é curta e reativa, e o que te derruba hoje é o assistente atropelando o usuário

Sinais de não: se o seu gargalo é o backend, o silêncio durante a delegação vai aparecer igual

modelo de voz melhor não conserta consulta lenta, ele só entrega a espera com uma voz mais agradável 🙂

Antes de plugar em telefonia: o que observar

Há suporte a telefonia e SIP pra caminhos de integração telefônica, e existe um guia de integração de parceiros pra aplicações feitas com LiveKit, Twilio, Telnyx ou Daily/Pipecat

Se você já usa um desses, esse guia é a primeira parada antes de sair inventando encanamento próprio

Um detalhe que muda o seu código: em SIP o servidor mantém o buffer de áudio de saída, igual no WebRTC

ou seja, quem trata a truncagem não é mais o cliente, e aquele trabalho todo que você fez no WebSocket muda de mão

vale testar interrupção de novo depois da migração, porque o caminho do áudio não é o mesmo

Sobre voz: com o GPT-Live-1 a OpenAI amplia de um conjunto pequeno de vozes em tempo real pra uma seleção maior de acentos, dialetos e idiomas

e as vozes customizadas seguem limitadas a clientes elegíveis, então não planeje sua marca sonora em cima disso antes de confirmar o seu acesso

Conclusão

Teste de voz em tempo real não é sobre o modelo falar bonito

é sobre ele CALAR na hora certa, e sobre o seu backend não continuar respondendo a pergunta antiga depois que o usuário já mudou de ideia

O próximo passo concreto é pequeno e cabe numa tarde: rode o modo CRAWL do guia de avaliação usando o quickstart de WebRTC, com o identificador gpt-live-1 na sessão e a política de interrupção em session.instructions

registre dois números primeiro, cedência à interrupção e silêncio durante a delegação

e só depois suba pra WALK e RUN, quando você já souber que o seu microfone e a sua truncagem estão de pé

Ah, e antes de qualquer métrica: abre dois microfones lado a lado e confirma que o áudio está entrando mesmo… esse conselho é de graça e já me salvou de um diagnóstico errado 😀

até o próximo post!

Nota técnica: a documentação de sessões GPT-Live distingue os intervalos temporais de transcrição dos deltas de áudio. Os campos de tempo da transcrição não devem ser atribuídos a session.output_audio.delta.