Google descontinuau dois slugs Gemini Flash API e está roteando automaticamente o tráfego de cada nome antigo para um substituto mais recente, criando uma pequena alteração no catálogo de modelos com consequências maiores para gateways, análises e relatórios de clientes.

De acordo com as notas de versão Gemini API de Google datadas de 8 de outubro de 2026, gemini-3.7-flash foi descontinuado e substituído por gemini-3.8-flash. As solicitações enviadas para o slug Flash 3.7 obsoleto são roteadas automaticamente para o Flash 3.8. Google também foi descontinuado gemini-3.5-flash, substituindo-o por gemini-3.6-flash e com o mesmo comportamento de redirecionamento automático.

A empresa também descontinuou deep-research-pro-preview-12-2025 e diz que o agente de Deep Research será encerrado em 23 de outubro de 2026, com caminhos de migração para agentes de Deep Research mais recentes. Isso dá às equipes uma pequena janela para identificar o uso da produção, alterar IDs fixados e verificar o comportamento da saída antes que o antigo endpoint de visualização desapareça.

O que mudou em Gemini API

A mudança operacional imediata é direta: uma solicitação pode nomear um modelo enquanto Google atende outro. Isso não é a mesma coisa que um desenvolvedor editar deliberadamente um aplicativo de gemini-3.7-flash a gemini-3.8-flash. É uma substituição do lado do provedor.

Para aplicativos simples, a diferença pode ser invisível se as respostas permanecerem aceitáveis. Para equipes que executam avaliações, análises voltadas para o cliente, fluxos de trabalho regulamentados ou atribuição de custos, isso é importante. Uma entrada de log que registra apenas o modelo solicitado pode fazer parecer que um modelo obsoleto ainda está lidando com o tráfego. Um painel que registra apenas o modelo atendido pode ocultar o fato de que os clientes ainda estão ligando para um slug antigo. Ambas as visualizações estão incompletas.

É aqui que os aliases de modelos de IA se tornam mais do que uma conveniência para o desenvolvedor. Os gateways precisam distinguir pelo menos três casos: um alias de cliente estável criado pela plataforma, um alias de provedor que flutua intencionalmente e uma rota de descontinuação de provedor que mapeia silenciosamente um ID de modelo público antigo para um novo. Tratar todos os três como o mesmo campo cria análises ambíguas.

Por que o redirecionamento automático é útil, mas arriscado

O reencaminhamento automático reduz interrupções imediatas. Se um cliente tiver codificado gemini-3.7-flash, a rota de substituição de Google poderá manter as solicitações em execução enquanto a equipe atualiza a configuração. Essa é uma opção prática de continuidade de serviço, especialmente para aplicativos em que os IDs de modelo são distribuídos entre scripts, integrações de parceiros, prompts ou configurações de clientes.

A compensação é a perda de controle explícito. Uma substituição de modelo pode alterar a latência, o estilo de saída, o comportamento de segurança, os padrões de uso de ferramentas ou a confiabilidade de casos extremos, mesmo quando a chamada API ainda for bem-sucedida. Os desenvolvedores podem não perceber a mudança até que uma avaliação seja alterada, um prompt se comporte de maneira diferente ou um cliente pergunte por que o uso relatado não corresponde mais à documentação.

O risco é maior para plataformas que expõem Google modelos por meio de um gateway multimodelo API para equipes. Esses produtos ficam entre o provedor e o usuário final, então eles precisam decidir quanto do comportamento de roteamento do provedor será revelado. Um gateway que simplesmente encaminha o slug antigo e cobra a chamada resultante normalmente pode preservar a compatibilidade, mas deixa as equipes de suporte e finanças com uma trilha de auditoria fraca.

Quais gateways e plataformas de revenda devem registrar

O padrão mais limpo é armazenar o modelo solicitado, o modelo de provedor resolvido e a regra de alias que causou a resolução. Para a alteração de Gemini Flash, isso significa que um registro de uso deve ser capaz de mostrar que o cliente solicitou gemini-3.7-flash, Google atendeu gemini-3.8-flash e o motivo foi o redirecionamento da suspensão de uso de Google, em vez de uma regra de reserva definida pelo cliente.

Essa distinção afeta o suporte ao faturamento, o planejamento da migração e a confiança no produto. Se um cliente perguntar se seu aplicativo ainda está usando um modelo obsoleto, a resposta não deverá exigir arqueologia de log manual. Se um revendedor precisar notificar contas downstream, ele deverá ser capaz de segmentar por slug legado solicitado. Se um conjunto de avaliação interno começar a falhar, os engenheiros deverão ser capazes de comparar os resultados antes e depois da mudança do modelo servido sem adivinhar quando o tráfego foi movido.

Para produtos do estilo Model Gate, o trabalho prático é a análise de uso e relatórios de clientes. Um painel de análise de uso deve evitar o recolhimento do modelo solicitado e veiculado em um único rótulo. Ele também deve tornar os IDs obsoletos visíveis o suficiente para que os proprietários da conta possam realizar migrações antes que o suporte do provedor termine.

O encerramento do agente da Deep Research adiciona um segundo tipo de prazo. Ao contrário de um redirecionamento Flash, Google diz que deep-research-pro-preview-12-2025 será encerrado em 23 de outubro de 2026. As equipes que usam esse agente de visualização precisam migrar em vez de depender de roteamento de compatibilidade indefinida. Como os fluxos de trabalho de pesquisa profunda podem ser incorporados em pipelines de pesquisa ou automação de execução mais longa, a verificação de migração deve incluir prompts, suposições de ferramentas, formatos de saída e quaisquer listas de permissões de modelos armazenados.

O que permanece incerto

As notas de lançamento de

Google identificam os slugs obsoletos, as substituições e o comportamento de redirecionamento, mas não resolvem todas as questões operacionais para plataformas downstream. As notas não fornecem uma ampla comparação comportamental entre os modelos Flash antigos e de substituição na entrada citada do changelog. Eles também não indicam uma data de encerramento para os slugs Flash obsoletos da mesma forma que fazem para o agente de visualização do Deep Research.

Isso deixa as equipes com um problema familiar de gerenciamento API: a compatibilidade pode continuar por enquanto, mas o estado estável ainda é a migração. Os desenvolvedores devem atualizar as seleções explícitas de modelos, executar novamente avaliações críticas em relação aos IDs de substituição e garantir que os registros mantenham detalhes suficientes para explicar o que aconteceu durante a transição.

A lição mais ampla é que os IDs de modelo não são mais simples nomes de produtos. Eles podem ser versões estáveis, aliases móveis, correções de compatibilidade ou armadilhas de depreciação. Os gateways que desejam fornecer aos clientes um controle confiável precisam de um modelo de dados que possa representar essas diferenças diretamente.