Gemini 3.8 Live: A Aposta Em Voz Que Ficou Na Sombra Do Flash

No dia 15 de setembro publiquei aqui um texto sobre o Gemini 3.8 Flash e a cadência de três lançamentos em seis semanas, falando de contexto de 1 milhão de tokens, preço promocional e roteamento entre modelo caro e barato. Naquele mesmo dia, o Google publicou outro anúncio da mesma leva, e eu passei reto por ele. Não por desinteresse: a pasta de release notes estava cheia e o título falava de "Live", que na minha cabeça ainda era sinônimo de recurso de conversa do app, não de produto para desenvolvedor.

Quem me fez voltar ao anúncio foi um colega que cuida de uma operação de atendimento. Ele me mandou uma pergunta curta num fim de tarde: "esse Gemini Live novo dá para colocar na URA ou ainda é brinquedo de demo?". Eu não sabia responder. E a pergunta é boa justamente porque a resposta honesta não é nem "sim" nem "não".

Para deixar claro logo de saída: este post não é sobre o Flash. É sobre o Gemini 3.8 Live e o Gemini 3.8 Live Extended Thinking, dois modelos de áudio para áudio lançados em 15 de setembro de 2026 para agentes de voz em tempo real. Mesma família, mesma semana, problema diferente. Não testei nenhum dos dois: o que segue é leitura do anúncio, do changelog e da página de preços da Gemini API e da cobertura especializada.

Vou passar pela diferença entre as duas versões, pela arquitetura audio-to-audio, pelo silêncio morto em agentes de voz, pelos 97 idiomas, pelos benchmarks (com atenção ao número menos lisonjeiro), por preço e SynthID e pelo que um time deveria avaliar antes de colocar isso na frente de um cliente.

O Que Foi Anunciado Em 15 De Setembro

O anúncio apresenta dois modelos. O Gemini 3.8 Live é a opção para escala e custo, focada em diálogo fluido. O Gemini 3.8 Live Extended Thinking é a versão para tarefas complexas, com raciocínio de múltiplas etapas, e concentra a narrativa de "raciocinar e falar ao mesmo tempo". No changelog da Gemini API, gemini-3.8-live aparece como a opção padrão para agentes de voz de baixa latência, com raciocínio intercalado e chamadas de função assíncronas; gemini-3.8-live-extended-thinking é o recomendado quando se precisa de mais raciocínio em background.

Segundo o 9to5Google e o FoneArena, o 3.8 Live alimenta o Search Live, no AI Mode da busca, e o Extended Thinking chega ao Gemini Live no app para assinantes, além de experiências de voz no Gmail, Docs e Keep. Desenvolvedores acessam os dois pela Gemini API e pelo AI Studio, com integrações em LiveKit, Pipecat, Agora, LangChain e Vercel, entre outras. Empresas têm preview privado no Gemini Enterprise.

A tabela abaixo resume o que as fontes consultadas dizem sobre cada um:

Vale notar o que a tabela revela sem dizer: quase todos os números de benchmark do anúncio são do Extended Thinking. O Live padrão, que é o que a maioria das operações de alto volume vai querer usar por causa de latência e custo, aparece com um único resultado, a segunda posição num ranking de preferência. Se o seu caso de uso é o do modelo barato, o número de qualidade que você está lendo quase sempre é do modelo caro.

Audio-To-Audio E O Custo Escondido Do Pipeline Em Três Etapas

Para entender por que a arquitetura importa, vale lembrar como a maioria dos agentes de voz foi construída até pouco tempo. O desenho clássico é um pipeline de três estágios: um modelo de reconhecimento de fala transcreve o áudio do usuário, um LLM de texto decide a resposta, e um sintetizador transforma a resposta em voz. Quando escrevi sobre os modelos de voz em tempo real da OpenAI, em maio, esse era exatamente o ponto: cada etapa adiciona latência e um ponto de falha, e colapsar o pipeline é boa parte do valor.

O esquema abaixo mostra a diferença de forma grosseira:

Pipeline clássico (cascata)
  áudio usuário -> [STT] -> texto -> [LLM] -> texto -> [TTS] -> áudio agente

Audio-to-audio (Gemini 3.8 Live, pela descrição do Google)
  áudio usuário -> [modelo único, sessão bidirecional] -> áudio agente
                   escuta, raciocina, chama ferramentas e fala
                   no mesmo fluxo; interrupção tratada no modelo

O primeiro custo da cascata é latência acumulada. O STT precisa decidir que o usuário terminou de falar, o LLM precisa gerar os primeiros tokens e o TTS precisa sintetizar o primeiro trecho. Streaming ajuda em cada etapa, mas a soma raramente fica abaixo do ponto em que o usuário percebe a pausa, e em telefonia pausa longa soa como ligação caída.

O segundo custo é perda de prosódia. Quando o áudio vira texto, tom, hesitação e irritação desaparecem: o LLM recebe "tudo bem, pode cancelar" e não sabe se o cliente disse isso aliviado ou furioso. Um modelo com áudio na entrada e na saída tem, em princípio, acesso a esse sinal. Digo "em princípio" porque o anúncio não detalha quanto disso pesa nas decisões.

O terceiro custo é interrupção. Um agente que não sabe parar de falar quando o usuário começa é cansativo em segundos, e na cascata tratar o barge-in exige orquestração: detectar a fala durante o TTS, cortar a reprodução, descartar a resposta pendente, reconciliar o estado. O guia de lançamento do Developers Digest descreve a Live API como uma sessão WebSocket bidirecional em que a interrupção já vem embutida: o usuário começa a falar e o modelo para a resposta atual. É mover a responsabilidade para dentro do modelo, o que simplifica o código, mas tira parte do controle.

Esse ponto merece atenção. A cascata é pior em latência, mas cada etapa é inspecionável: você tem a transcrição, o texto do LLM e o áudio, e pode auditar, filtrar e trocar qualquer peça. No audio-to-audio, a decisão não passa mais por um texto que você controla antes de virar voz. Em setor regulado, isso pesa tanto quanto a latência.

O Silêncio Morto: Raciocinar Enquanto Fala E Ferramentas Em Background

Se eu tivesse que escolher uma única característica do anúncio para explicar ao colega da URA, seria esta: o modelo executa ferramentas e chamadas de API em background enquanto continua a conversa. Parece detalhe, mas ataca o problema mais irritante de agente de voz em produção, que é o silêncio morto.

Imagine um fluxo hipotético de segunda via de boleto: o agente consulta o CPF no cadastro, busca faturas em aberto na cobrança e gera o código de barras. Três chamadas com latência própria, e num agente síncrono o cliente ouve nada durante esse tempo. Quatro ou cinco segundos de silêncio bastam para um "alô?" ou para desligar. Os times contornam com áudio de espera ou um "só um momento" disparado por timeout, e tudo isso soa mecânico.

O que o Google descreve é diferente. O Extended Thinking usa pistas verbais antecipadas, como "deixa eu verificar isso", e narra o progresso em tarefas longas. E o modelo continua conversando enquanto a ferramenta roda: se o cliente pergunta outra coisa no meio da consulta, o agente responde sem perder a tarefa pendente. O changelog fala em chamadas de função assíncronas como padrão também no gemini-3.8-live.

Em arquitetura, isso muda o contrato com o backend. Numa chamada assíncrona, o resultado chega no meio de uma conversa que já avançou. Isso exige ferramentas idempotentes, um backend que tolere consultas que ficaram irrelevantes porque o cliente mudou de ideia e estado de sessão reconciliável. Não é muito diferente dos cuidados que discuti quando falei de Managed Agents na Gemini API e a execução em sandbox: quando o agente age sozinho em paralelo, o problema deixa de ser "o modelo sabe chamar a ferramenta" e passa a ser "o sistema aguenta o modelo chamando a ferramenta fora de ordem".

Há um risco que me preocupa mais do que a latência. Um agente que preenche o silêncio com "deixa eu verificar" soa competente, e isso é ótimo quando ele está certo. Escrevi recentemente sobre agentes que erram com a mesma confiança com que acertam, no contexto de código, e o padrão se transfere para voz com uma agravante: numa ligação não existe diff para revisar. O cliente ouve "sua segunda via foi enviada" e desliga satisfeito, mesmo que a ferramenta tenha falhado. Por isso eu trataria a narração de progresso como camada de experiência, não de verdade: qualquer afirmação de conclusão deveria depender de um resultado confirmado pelo backend.

97 Idiomas E O Que Isso Significa Para Atendimento No Brasil

O anúncio diz que o modelo detecta e transita automaticamente entre 97 idiomas durante uma conversa. Para quem opera no Brasil, isso tem duas leituras concretas.

A primeira é o atendimento a estrangeiros em turismo, hotelaria, aeroportos e hospitais de cidades com fluxo internacional. Hoje a saída comum é "para espanhol, digite 2" seguido de uma fila menor e mais lenta. Um agente que responde no idioma em que o cliente falou elimina o menu e a fila separada. O mesmo vale para empresas brasileiras que atendem a América Latina.

A segunda é a troca no meio da conversa. O caso clássico aqui é o portunhol: o cliente começa em espanhol, mistura português, volta ao espanhol quando a explicação fica técnica. Um STT configurado para idioma fixo transcreve mal esse cenário, e o LLM responde a um texto degradado. O anúncio, porém, não detalha qualidade por idioma, e 97 idiomas "suportados" não significa 97 com a mesma qualidade. Para português brasileiro com sotaque regional e ruído de celular, só teste com áudio real da sua operação responde.

Uma ressalva: troca automática de idioma é conveniente até o dia em que o modelo decide trocar sem que o cliente tenha pedido. Um nome próprio em inglês, uma marca estrangeira, um termo técnico, e o agente muda para inglês no meio de uma explicação para um cliente que só fala português. Se a operação é monolíngue, vale verificar se dá para fixar o idioma da sessão, ou pelo menos instruir o modelo a manter o idioma inicial a menos que o cliente peça explicitamente a troca.

Os Benchmarks São Do Google, E O Número Mais Honesto É 35,1%

A ressalva de sempre: todos os resultados abaixo foram publicados pelo Google no anúncio. Alguns vêm de avaliações de terceiros, como Artificial Analysis e Sierra, mas a seleção do que mostrar é do fornecedor. Não encontrei avaliação independente que os reproduza.

A leitura rápida impressiona, mas a tabela conta outra história lida de cima para baixo: conforme o benchmark se aproxima de atendimento real, o número cai. Responder perguntas em áudio fica perto de 98%. Tarefas agênticas por voz genéricas caem para 68,6%. Tarefas agênticas num domínio com regras de negócio de verdade, o bancário, caem para 35,1%.

Traduzindo: se o τ-Voice-Banking representasse o seu cenário, o melhor modelo do Google concluiria corretamente pouco mais de uma em cada três tarefas. É uma leitura simplificada, porque o anúncio não detalha a métrica nem a configuração, e a família τ da Sierra é deliberadamente difícil, com usuários simulados, políticas e bancos de dados a modificar. Banco pesa porque combina autenticação em etapas, política que vale mesmo quando o cliente insiste e números ditados em que um dígito errado é erro total.

Acho saudável que o Google tenha publicado esse número; ele é, na minha leitura, o dado mais útil do anúncio, porque desmonta a ideia de que voz natural e baixa latência bastam para substituir o atendente em tarefa transacional. A fluência está muito à frente da confiabilidade, e como a fluência é o que se percebe numa demo, essa distância é o que surpreende times na passagem para produção.

Preço, SynthID E O Que Ainda Não Está Claro

O post oficial do Google não menciona preço. A página de preços da Gemini API, porém, lista os dois modelos com a mesma tabela, sem diferenciar Live e Extended Thinking, e o guia do Developers Digest cita os mesmos valores a partir dessa página. Existe um nível gratuito, e no nível pago os valores são estes, em dólares:

O Developers Digest estima uma chamada de suporte de 10 minutos, cobrando 10 minutos de entrada e 10 de saída, em cerca de US$ 0,23. É um teto razoável, mas a conta real depende de como a sessão contabiliza silêncio, espera e contexto acumulado, e isso não está detalhado. Para dar escala: uma operação hipotética com 5 mil ligações de 10 minutos por dia gastaria perto de US$ 1.150 diários só com o modelo, sem telefonia e backend. Barato ou caro depende do que substitui.

Vale lembrar o histórico recente. No Gemini 3.7 Flash como workhorse de pipeline de agentes, o detalhe mais importante era um preço promocional que dobra em 1º de janeiro de 2027. Não achei indicação de que o preço do 3.8 Live seja promocional, nem garantia do contrário. Em contrato anual de atendimento, confirme por escrito.

O anúncio afirma que todo áudio gerado pelos produtos de IA do Google recebe marca d'água SynthID, imperceptível e embutida na saída. Isso ajuda a identificar voz sintética em golpes, problema bem conhecido no Brasil. Mas o cliente não detecta SynthID de ouvido: informar que ele fala com um agente continua sendo decisão de produto e, em vários contextos, obrigação regulatória.

Restam lacunas. O Developers Digest cita tempo até o primeiro áudio de cerca de 1,18 segundo no Live e 1,35 no Extended Thinking, mas esses números não estão no anúncio oficial e não sei em que condições foram medidos. Segundo o mesmo guia, no Vertex AI os modelos ainda não tinham disponibilidade geral com data pública, o que importa para quem precisa de SLA e residência de dados.

O Que Um Time Deveria Avaliar Antes De Colocar Na Frente Do Cliente

Voltando à pergunta do colega da URA: dá para começar, mas não pelo lugar óbvio, que é substituir de uma vez o fluxo transacional de maior volume. O 35,1% sugere que é justamente ali que o modelo tem mais chance de errar com confiança.

Três cenários hipotéticos ajudam a separar os riscos. Numa URA de operadora de saúde com quatro níveis de menu, usar o 3.8 Live só para entender o motivo da ligação e rotear é baixo risco: se errar, custa uma transferência. Num suporte técnico de provedor de internet, em que o agente diagnostica, consulta o status da conexão em background e agenda visita, o risco é médio, com ações reversíveis. Num banco em que o agente faz contestação de compra no cartão, o risco é alto, e é exatamente o tipo de tarefa que o benchmark bancário mostra longe de resolvida.

Antes de qualquer piloto, eu olharia para quatro coisas. A primeira é latência real, medida na sua telefonia, com sua rede até a região do Google e suas ferramentas de backend; ligação de celular com ruído de trânsito não é a condição do lançamento. A segunda é custo por minuto efetivo, calculado sobre gravações reais, separando fala do cliente, fala do agente, espera e silêncio.

A terceira é fallback humano desenhado desde o primeiro dia: o agente precisa desistir depois de duas tentativas sem entender, quando o cliente pede uma pessoa, quando a ação passa de certo valor ou quando o backend falha, e a transferência precisa levar o contexto. A quarta é observabilidade, comparando o que o agente disse que fez com o que o backend registrou; é aí que aparecem os erros confiantes. E, por baixo de tudo, um conjunto de ligações reais anonimizadas com desfecho anotado, que vale mais do que qualquer benchmark.

Conclusão

O Gemini 3.8 Live passou mais despercebido do que merecia. Pelo que o Google descreve, ele ataca problemas reais de agentes de voz: latência da cascata, perda de prosódia, interrupção e, principalmente, o silêncio morto enquanto as ferramentas rodam. A troca entre 97 idiomas tem aplicação concreta no Brasil, e o preço de centavos de dólar por minuto coloca a conta numa faixa viável para volume.

Mas o número que eu levaria para uma reunião de decisão não é o 97,7% nem o primeiro lugar em qualidade de fala. É o 35,1% no τ-Voice-Banking. Ele diz, com os dados do próprio fornecedor, que um agente de voz consegue soar pronto muito antes de estar pronto para tarefas transacionais com regra de negócio. A fluência e a confiabilidade andam em velocidades diferentes, e a arquitetura audio-to-audio, ao tornar a conversa mais natural, torna essa diferença ainda mais difícil de perceber de ouvido.

Não tenho resposta fechada para o colega da URA. O razoável me parece começar pelos fluxos em que errar custa pouco, medir latência e custo no tráfego real, desenhar o fallback humano antes do piloto e tratar cada "pronto, está resolvido" do agente como afirmação a verificar no backend. Se os benchmarks de tarefa agêntica por voz subirem no ritmo dos lançamentos do Google, essa cautela vai parecer excessiva em um ano. Hoje, ainda parece o mínimo.

Fontes:

• Google Blog — Gemini 3.8 Live e Gemini 3.8 Live Extended Thinking
• 9to5Google — Gemini 3.8 Live announced
• Developers Digest — Gemini 3.8 Live Extended Thinking release guide
• FoneArena — Google Gemini 3.8 Live and 3.8 Live Extended Thinking
• Google AI for Developers — Gemini API changelog
• Google AI for Developers — Gemini API pricing