API full-duplex GPT-Live: arquitetura de agentes de voz

Um agente de voz que espera o silêncio para começar a pensar pode até ser rápido, mas ainda assim transmite uma sensação robótica. O GPT-Live enfrenta essa limitação na própria arquitetura: mantém escuta e fala em um fluxo contínuo, enquanto buscas, ferramentas e raciocínios mais complexos rodam ao lado — e não dentro — do loop de áudio. O resultado é uma interação mais natural, mas também um sistema muito mais difícil de operar.

A arquitetura da API full-duplex GPT-Live em um minuto

O GPT-Live não é simplesmente um endpoint de speech-to-speech mais rápido. A OpenAI o descreve como um sistema de voz full-duplex, capaz de processar áudio de entrada enquanto gera áudio de saída, tomar decisões de interação várias vezes por segundo e delegar tarefas mais profundas a um modelo de fronteira. Segundo o material de engenharia da OpenAI, o sistema foi construído sobre inferência em streaming, uma conversa com estado, transporte via WebRTC e processamento assíncrono fora do caminho de mídia.

Na prática, o modelo fica assim:

A mudança mais importante está em quem controla o tempo. Em um agente de voz convencional, a aplicação espera o turno do usuário, envia o conteúdo a um modelo e reproduz a resposta. No design do GPT-Live, a sessão de voz continua ativa enquanto vários tipos de trabalho acontecem ao mesmo tempo.

A velha lógica baseada em turnos deve ficar em segundo plano

Sistemas de voz em cascata executam speech-to-text, um modelo de linguagem e text-to-speech em sequência. Os modelos nativos de speech-to-speech eliminam algumas dessas transferências, mas um detector de atividade de voz separado ainda pode decidir que o usuário terminou antes de a inferência começar. Uma pequena pausa para pensar pode parecer o fim do turno; um ruído de fundo pode ser interpretado como o início de outro.

A abordagem full-duplex do GPT-Live transfere esse problema de timing para o próprio modelo de voz. Ele pode continuar escutando enquanto fala, perceber uma interrupção, pausar, retomar ou emitir uma confirmação breve. Isso não elimina os limites de turno em todos os contextos. A diferença é que esses limites deixam de bloquear o loop de áudio ao vivo.

O que o GPT-Live muda no caminho em tempo real

Inferência contínua substitui o bloqueio por turnos

Em uma sessão full-duplex, entrada e saída são fluxos, não blocos de áudio alternados. O modelo pode receber uma nova fala enquanto a resposta anterior ainda está sendo reproduzida. Ele decide se o áudio recebido é uma interrupção relevante, uma confirmação curta ou apenas ruído de fundo.

Isso muda a lógica do cliente. Ele precisa estar preparado para enviar, receber, cancelar e substituir eventos de áudio simultaneamente. Uma abstração única como await response() não combina bem com esse comportamento, porque esconde justamente os eventos mais importantes: início da fala, início do áudio do assistente, interrupção detectada, ferramenta solicitada, resposta cancelada e encerramento da sessão.

Os desenvolvedores ainda devem manter os sinais de atividade de voz para a interface, as análises e a segurança. O erro de arquitetura é usar o VAD como única autoridade para decidir quando a inferência do modelo pode começar.

Mantenha a mídia rápida e tire o restante do caminho

O relato de engenharia da OpenAI separa o caminho dedicado de áudio da lógica da aplicação. O áudio trafega diretamente entre o cliente e o modelo de voz, enquanto chamadas de ferramentas, verificações de políticas, persistência e operações de backend atravessam uma fronteira assíncrona.

Essa fronteira estabelece uma regra simples: uma consulta lenta ao CRM pode atrasar a própria resposta, mas não deve impedir que os frames de áudio cheguem no prazo. O WebRTC fornece o transporte de mídia de baixa latência; os serviços da aplicação não devem ficar de forma síncrona entre cada frame do microfone e o modelo.

A camada de voz pode dizer algo breve enquanto uma tarefa delegada é executada, mas uma fala de preenchimento não substitui uma tarefa com limites bem definidos. Estabeleça prazos, regras de cancelamento e um estado seguro de resultado para cada ferramenta.

A delegação separa capacidade de resposta e inteligência

O GPT-Live pode delegar buscas, raciocínios mais profundos ou tarefas complexas a um modelo de fronteira. Os posts de lançamento e de engenharia da OpenAI identificam o GPT-5.5 como o modelo delegado no lançamento. O modelo de voz continua responsável pela interação imediata; o modelo de fronteira assume o trabalho que não cabe confortavelmente em um loop de fala de baixa latência.

Uma implementação de produção deve tratar a delegação como um pipeline próprio:

1. Detecte que a solicitação exige uma busca, raciocínio ou ferramenta.
2. Confirme o recebimento ou faça uma pausa sem bloquear o caminho de mídia.
3. Inicie a tarefa em segundo plano com o contexto relevante da conversa.
4. Cancele a tarefa se o usuário mudar de direção ou encerrar a sessão.
5. Valide o resultado na aplicação.
6. Insira um resultado conciso de volta na sessão ao vivo.

Pré-inicializar a sessão de inferência delegada, manter a afinidade da sessão e armazenar em cache contextos repetidos pode reduzir o tempo até a chegada de uma saída útil. O orçamento de ponta a ponta inclui roteamento, processamento do prompt, inferência do modelo, chamadas de ferramentas e cada ida e volta entre modelo e ferramenta — não apenas a latência dos tokens do modelo.

Sessões com estado exigem uma segunda arquitetura

Uma chamada de voz longa não é uma sequência de requisições descartáveis. O contexto cresce, os workers do modelo mudam e a sessão pode precisar de compactação. A OpenAI descreve o aquecimento de uma nova instância do modelo, o preenchimento dela com o contexto atual e a troca somente quando estiver pronta. Assim, uma transição de infraestrutura não se torna audível para quem está na chamada.

A compactação de contexto cria um problema semelhante. Resumir turnos anteriores altera o contexto que sustenta o cache de chave-valor do modelo. Reconstruir esse cache em primeiro plano provocaria uma pausa. Um design mais seguro compacta o contexto em paralelo, prepara uma instância substituta e mantém a instância antiga atendendo até que a transferência esteja pronta.

Por isso, o estado de uma sessão no backend de um agente de voz deve incluir mais do que uma transcrição:

• Estado atual do áudio e da resposta
• Chamadas de ferramentas ativas e tokens de cancelamento
• Afinidade com a instância do modelo ou com o worker
• Mensagens provisórias e finalizadas
• Status da compactação de contexto
• Estado de reconexão e recuperação
• Estado de segurança e confirmação

O contrato da API é um sistema de eventos, não de requisição e resposta

O full-duplex muda o protocolo interno, mesmo que a API externa ofereça posteriormente métodos familiares no SDK. A aplicação precisa distinguir explicitamente eventos que costumam ser confundidos:

O GPT-Live pode operar continuamente, mas o restante do produto ainda precisa de mensagens para a interface, as análises e os sistemas de segurança. A OpenAI descreve a manutenção de uma visão especulativa, que pode ser revisada à medida que as transcrições chegam, e de um registro autoritativo, finalizado posteriormente. É um padrão útil: mostre legendas responsivas sem tratar cada transcrição parcial como um fato imutável.

O que as equipes de agentes de voz precisam reprojetar

Separe o adaptador de mídia da orquestração do agente

Coloque o transporte específico do provedor e o tratamento de eventos atrás de um adaptador. A aplicação deve consumir eventos normalizados, como user_audio_started, assistant_interrupted, tool_requested, confirmation_required e response_completed.

Mantenha ID do modelo, voz, prompts, esquemas de ferramentas e limites de custo em configuração. Isso não serve apenas como proteção contra migrações. Também permite que a equipe teste hoje um modelo Realtime documentado, preservando um alvo explícito para os semânticos do GPT-Live no futuro.

Para ferramentas, o modelo propõe e a aplicação valida. Pagamentos, alterações de conta, cancelamentos, edição de endereços, triagem médica, operações financeiras e fluxos de identidade precisam de regras de confirmação fora da confiança transmitida pela fala do modelo.

Escolha o transporte de acordo com quem controla o áudio

O WebRTC é a escolha natural para clientes web e mobile que capturam e reproduzem áudio diretamente. O WebSocket ainda pode ser útil em pipelines de mídia controlados pelo servidor, mas as equipes não devem presumir que todo modelo em tempo real aceite o mesmo formato de sessão em qualquer transporte.

Uma issue de integração do OpenClaw documenta um problema prático: tratar o gpt-live-1 como uma sessão comum de WebSocket da API Realtime GA produziu uma resposta invalid_model, enquanto o fluxo de navegador proposto para o GPT-Live usava um formato de sessão WebRTC diferente. A issue é um relato de implementação, não um contrato da API da OpenAI, mas reforça a regra de design: identifique a família do modelo e negocie explicitamente o tipo de sessão compatível.

Meça frames entregues no prazo, não apenas latência de tokens

O post de engenharia da OpenAI relata que um componente de suporte do streaming atingiu o limite antes da capacidade de GPU nos testes de produção. A unidade de capacidade relevante foi o número de sessões simultâneas sustentáveis com entrega de frames no prazo — não o número de requisições por GPU.

Acompanhe pelo menos:

• Atrasos e perdas de frames de áudio
• Tempo até o primeiro áudio reproduzível
• Tempo entre a interrupção e a parada
• Sessões simultâneas por região
• Reconexões e chamadas duplicadas de ferramentas
• Tempo de conclusão da delegação
• Taxas de timeout e cancelamento de ferramentas
• Correções entre transcrições provisórias e finais
• Sessões abandonadas e gasto por sessão

A naturalidade também envolve um problema de controle. Usuários reais podem gostar do comportamento de interrupção e confirmação em um contexto e considerá-lo invasivo em outro. Um relato inicial de usuário resumiu o risco sem rodeios: “It's literally cutting her off constantly lmao” (@AutismCapital). Use isso como um lembrete para ajustar a política de barge-in com base em conversas reais, e não em demonstrações roteirizadas.

GPT-Live versus o design Realtime disponível hoje

O catálogo oficial de modelos da OpenAI agora posiciona o GPT-Live 1 para conversas de voz naturais e expressivas, destacando também o tratamento suave de interrupções. Esse catálogo não equivale a um contrato completo de integração: a página separada da API GPT-Live analisada aqui continua sendo um formulário de notificação, sem detalhes sobre endpoint, limites de taxa ou outras restrições. Antes de fechar um plano de lançamento, as equipes devem confirmar a documentação atual para desenvolvedores e a habilitação da conta.

Vale adotar essa arquitetura mesmo antes de o modelo estar disponível para todas as contas. Mídia contínua, eventos normalizados, ferramentas assíncronas e cancelamento explícito melhoram qualquer agente de voz construído sobre um modelo realtime convencional.

FAQ sobre a API full-duplex GPT-Live

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

Não. A OpenAI apresenta o GPT-Live como uma família distinta de modelos para conversas de voz, enquanto o GPT-Realtime é a família documentada de APIs em tempo real. Recursos de áudio semelhantes não garantem semântica de sessão, transportes ou IDs de modelo idênticos.

Full-duplex significa que o modelo nunca espera?

Não. Significa que o sistema pode escutar e falar simultaneamente. O modelo ainda pode pausar, permanecer em silêncio, pedir esclarecimentos ou atrasar um resultado delegado quando isso for mais seguro ou útil.

Os desenvolvedores ainda precisam de VAD?

Sim, para a experiência de mídia, análises, legendas e sinais de segurança. O VAD não deve ser o único mecanismo que força o modelo a seguir uma sequência rígida de turno do usuário e turno do assistente.

Qual transporte um agente de voz deve usar?

Use o transporte compatível com o cliente e o modelo específicos. O WebRTC geralmente é adequado para áudio direto no navegador ou no mobile; pipelines de mídia no backend podem usar WebSocket quando houver documentação para isso. Não deduza o suporte a transporte pelo nome do modelo.

O que deve ser construído antes da confirmação do acesso?

Construa o adaptador, o esquema de eventos normalizados, a camada de validação de ferramentas, o modelo de cancelamento, a telemetria de custos, os mecanismos de fallback e a recuperação de sessões longas. Esses componentes continuarão úteis se o contrato final da API GPT-Live mudar.

Escolha a arquitetura, não o nome do modelo

A decisão que permanece válida é parar de tratar voz como uma camada de requisição e resposta sobre um modelo de texto. Mantenha o caminho de áudio sempre disponível, coloque o trabalho lento atrás de fronteiras assíncronas, trate interrupções e cancelamentos como eventos de primeira classe e mantenha uma transcrição que possa ser revisada antes de se tornar autoritativa.

O compromisso do GPT-Live é claro: uma sobreposição mais natural e a delegação de tarefas exigem mais estado, mais observabilidade e menos dependência de limites simples entre turnos. As equipes dispostas a lidar com essa complexidade já podem projetar para o contrato full-duplex; quem precisa de um endpoint de produção documentado deve lançar com o Realtime, mantendo as mesmas fronteiras orientadas a eventos.