Gemini 2.5 desliga no Agent Platform — o mesmo modelo não tem o mesmo prazo em toda API

Um prazo de dois dias — mas não para toda chamada Gemini

O Google Cloud marca 20 de outubro de 2026 como data de desativação de `gemini-2.5-pro`, `gemini-2.5-flash` e `gemini-2.5-flash-lite` no Gemini Enterprise Agent Platform, camada que sucedeu o Vertex AI para esse fluxo de modelos. Em 18 de outubro, portanto, equipes com workloads nessa plataforma têm dois dias até o prazo publicado.

A mesma conclusão não vale automaticamente para a Gemini Developer API. A documentação do Firebase AI Logic diferencia explicitamente os provedores: na Developer API, os três modelos estão depreciados e limitados a projetos que já os utilizavam, mas nenhuma data de desligamento foi anunciada; no Agent Platform, a data é 20 de outubro.

Essa assimetria importa porque o identificador do modelo pode ser igual enquanto contrato, autenticação, quotas, região e política de ciclo de vida mudam conforme a superfície de consumo. Um inventário que registra apenas `gemini-2.5-flash` não responde à pergunta operacional mais urgente: por qual endpoint o sistema chama esse modelo?

A documentação não está perfeitamente sincronizada

A página atual de versões e ciclo de vida e as páginas individuais dos modelos apontam 20 de outubro. As notas de versão do Vertex AI, porém, ainda preservam um registro de 2 de abril que dizia que as datas de aposentadoria haviam sido atualizadas para 16 de outubro.

Isso não significa que dois desligamentos estejam programados. Significa que uma nota histórica e a tabela operacional atual não foram harmonizadas. Para execução, a evidência mais recente e específica é a página de ciclo de vida, que traz 20 de outubro e os substitutos recomendados. O conflito documental, contudo, é um alerta: calendários de modelo precisam ser monitorados como dependências vivas, não copiados uma vez para uma planilha.

Times em produção devem conferir também avisos do console e comunicações contratuais da própria conta. A matéria registra o prazo público atual; não presume extensão individual, garantia de continuidade ou desligamento simultâneo em todas as regiões.

O nome do modelo identifica capacidade. Plataforma, endpoint e contrato identificam o risco de continuidade.

O sucessor não é único — nem necessariamente o mais novo

O Google recomenda rotas diferentes. Para Gemini 2.5 Pro, a tabela aponta `gemini-3.8-flash` ou `gemini-3.5-flash`. Para 2.5 Flash, lista 3.8 Flash, 3.5 Flash-Lite ou 3.1 Flash-Lite. Para 2.5 Flash-Lite, inclui 3.8 Flash, 3.1 Flash-Lite ou Gemma 4.

Gemini 4 Argon, lançado em 13 de outubro como novo modelo de maior capacidade, não aparece nessa tabela como substituto direto da série 2.5. Isso separa lançamento de migração. O modelo mais recente pode ter preço, latência, comportamento de ferramentas e perfil de raciocínio incompatíveis com um workload construído para volume e baixo custo.

A escolha precisa partir do caso de uso: qualidade mínima, tempo de resposta, custo por tarefa, limite de contexto, suporte regional, function calling e previsibilidade de saída. Trocar o ID sem refazer esses testes converte uma mudança planejada em incidente silencioso.

O checklist para evitar uma queda no dia 20

Primeiro, localizar chamadas diretas e indiretas: código, variáveis de ambiente, nodes de automação, SDKs, funções serverless, notebooks, agentes e plataformas low-code. Depois, registrar para cada uso o provedor, projeto, região, endpoint, modelo e owner. É essa combinação — não o nome isolado — que determina o prazo.

Segundo, executar um conjunto de avaliações com o candidato de substituição. Comparar respostas, chamadas de ferramenta, JSON estruturado, latência, tokens e custo. Fluxos com ajuste fino ou comportamento calibrado precisam de atenção adicional; compatibilidade nominal não garante equivalência operacional.

Terceiro, implantar de forma reversível. Feature flag, roteamento percentual e fallback permitem comparar produção sem deslocar todo o tráfego. O rollback também precisa apontar para um modelo que continuará disponível: voltar ao 2.5 depois do prazo não é plano de contingência.

Por fim, criar um registro permanente de ciclo de vida. Cada dependência de IA deve ter data de revisão, alerta antecipado e responsável. Modelos agora mudam mais rápido que muitos sistemas que os incorporam; depreciação virou uma rotina de operação, não uma exceção de fornecedor.

Fato, análise e o que ainda está aberto

Fato: as páginas atuais do Google Cloud publicam 20 de outubro para os três modelos 2.5 no Agent Platform. Fato: a Developer API está depreciada, sem data pública final. Fato: a lista oficial oferece múltiplos substitutos e não apresenta Argon como troca automática.

Análise Fluxia: empresas precisam governar modelos como dependências versionadas, com inventário por endpoint e teste de regressão. A inferência é que equipes sem essa camada ficam expostas a interrupções ou mudanças de custo e comportamento, mesmo quando o provedor oferece um sucessor.

Permanece aberto se o Google atualizará novamente a data, dará tratamento específico a contratos ou esclarecerá rotas para modelos ajustados. Até isso ocorrer, a decisão segura é trabalhar com o prazo público de 20 de outubro e validar cada migração na superfície exata em que ela roda.