Gemini 3.5 Pro foi cancelado: como sobreviver à próxima rotação

O Google pode ter enterrado silenciosamente o Gemini 3.5 Pro. E se a análise da Semi Analysis estiver certa — e tem tudo para estar — isso diz muito sobre como a Big Tech lida com pressão competitiva quando o ecossistema de desenvolvedores começa a migrar. Junho virou agosto, o modelo prometido em call com investidores nunca chegou de forma ampla, e o que vemos no playground oficial são versões “Flash” e “Lite” convenientemente mais baratas. Não vou fingir surpresa. Trabalho com a stack do Gemini há mais de um ano em produção. O que vou te mostrar aqui é o que isso significa na prática para quem constrói software de verdade — não para quem só cole prompt no ChatGPT.

O que realmente aconteceu com o Gemini 3.5 Pro

Segundo o portal Eurisko, a Semi Analysis publicou em agosto uma análise contundente: o Gemini 3.5 Pro foi arquivado internamente e o Google teria redirecionado recursos para o Gemini 4. O ponto sensível é que o modelo não era rumor — foi prometido por Sundar Pichai em junho, apareceu em materiais da Alphabet e foi descrito como evolução focada em codificação agêntica e tarefas longas.

Eu acompanhei essa promessa de perto. Em maio, no Google I/O, a narrativa era clara: o 3.5 Pro seria o “modelo de raciocínio” da família, focado em agentes e workloads pesados. Junho passou. Julho passou. O que saiu no lugar? O Gemini 2.5 Flash com preço agressivo e o Gemini 2.5 Pro Deep Think — uma variante, não o salto prometido. Quando uma empresa cancela o “flagship intermediário” e pula direto para a próxima geração, geralmente significa uma de duas coisas: ou o modelo ficou aquém do benchmark interno, ou a estratégia comercial mudou porque a concorrência apertou.

Aposto nas duas. O GPT-5 e o Claude Opus 4.1 roubaram holofotes em tarefas de raciocínio longo, e a Meta abriu o Llama 4 com pesos abertos. O Google não tem mais luxo de lançar um modelo “ok” — precisa de um salto real.

Por que isso importa para quem programa de verdade

A maioria dos devs que usa a API do Gemini hoje está rodando o 2.5 Pro ou o 2.5 Flash. Se você construiu um agente, um RAG ou um pipeline de código agêntico com a SDK @google/genai, precisa entender que o ciclo de depreciação ficou mais curto e mais imprevisível. Em 2024, modelos duravam 6 meses como “current”. Hoje, 3 meses é o novo normal.

Três implicações práticas que eu já estou aplicando nos meus projetos:

• Versionamento explícito por modelo, não por SDK. Não dependa do alias gemini-pro — pinar a versão como gemini-2.5-pro e documentar isso no README. Quando o Google rotacionar o default, seu código não quebra silenciosamente.
• Testes de regressão de prompts viraram CI obrigatório. Se você tem um sistema em produção, rode um eval set semanal comparando outputs entre versões. O custo de 200 chamadas é centavos; o custo de um prompt que degrada sem aviso é um cliente insatisfeito.
• Abstração de provider como estratégia, não como luxo. Quem ainda chama a API do Gemini direto no controller vai se arrepender quando precisar migrar. Eu uso uma camada fina de adapter — explico abaixo.

Comparativo honesto: onde o Gemini ainda ganha e onde perdeu

Não sou fanboy de ninguém. Uso os três grandes (Gemini, GPT, Claude) dependendo da tarefa. Hoje, na minha experiência rodando os modelos em workloads reais:

O Gemini continua imbatível em multimodal e janela de contexto por preço. Mas em raciocínio puro e codificação agêntica complexa, o 2.5 Pro já está atrás. O Gemini 4 precisa fechar essa distância — e rápido.

Na Prática: como blindar sua stack contra a próxima rotação de modelo

Vou te mostrar o padrão que adotei nos meus projetos depois de levar uma surra com a depreciação silenciosa do Gemini 1.5. É uma camada de adapter com fallback automático. Funciona em Node/TypeScript, mas a lógica vale para qualquer linguagem.

// llm-adapter.ts
// Camada fina que isola seu código do modelo específico

import { GoogleGenAI } from "@google/genai";
import OpenAI from "openai";

type Role = "code" | "reason" | "vision" | "long-context";

interface LLMResponse {
  text: string;
  model: string;
  tokensIn: number;
  tokensOut: number;
  provider: string;
}

class LLMAdapter {
  private gemini = new GoogleGenAI({ apiKey: process.env.GEMINI_KEY! });
  private openai = new OpenAI({ apiKey: process.env.OPENAI_KEY! });

  // Pinagem explícita: NUNCA use alias sem versão fixa
  private models = {
    code: { provider: "openai", name: "gpt-5" },
    reason: { provider: "openai", name: "gpt-5" },
    vision: { provider: "gemini", name: "gemini-2.5-pro" },
    "long-context": { provider: "gemini", name: "gemini-2.5-pro" },
  } as const;

  async generate(prompt: string, role: Role): Promise {
    const config = this.models[role];

    try {
      if (config.provider === "gemini") {
        const result = await this.gemini.models.generateContent({
          model: config.name,
          contents: prompt,
        });
        return {
          text: result.text ?? "",
          model: config.name,
          tokensIn: result.usageMetadata?.promptTokenCount ?? 0,
          tokensOut: result.usageMetadata?.candidatesTokenCount ?? 0,
          provider: "gemini",
        };
      }
      // fallback OpenAI
      const completion = await this.openai.chat.completions.create({
        model: config.name,
        messages: [{ role: "user", content: prompt }],
      });
      return {
        text: completion.choices[0].message.content ?? "",
        model: config.name,
        tokensIn: completion.usage?.prompt_tokens ?? 0,
        tokensOut: completion.usage?.completion_tokens ?? 0,
        provider: "openai",
      };
    } catch (err) {
      console.error(`[LLMAdapter] Falha em ${config.provider}/${config.name}`, err);
      // fallback automático para o outro provider
      throw err; // aqui você implementa retry com o provider alternativo
    }
  }
}

export const llm = new LLMAdapter();

O ponto é: quando o Google lançar o Gemini 4 (ou rotacionar o default do gemini-pro), você muda uma linha no objeto models. O resto do código nem percebe. Em produção, isso já me salvou três vezes em 2025.

Erros Comuns que vejo devs cometendo com a API do Gemini

Atendo clientes que contratam consultoria de IA aplicada e, semanalmente, vejo os mesmos deslizes. Anota aí:

• Confiar no alias padrão. Chamar model: "gemini-pro" sem versão é pedir para quebrar. O Google já rotacionou o default silenciosamente duas vezes em 2025. Pinar versão sempre.
• Ignorar o thinking_budget. Muita gente acha que o Gemini “pensa sozinho” igual Claude. Não pensa. Você precisa configurar thinkingConfig: { thinkingBudget: 1024 } para ativar raciocínio. Sem isso, você está pagando preço de Pro e recebendo resposta de Flash.
• Subir arquivos para o File API sem expirar. Arquivos no File API expiram em 48h. Se seu pipeline demora mais, o upload falha. Faça upload sob demanda dentro da janela de processamento, não no boot da aplicação.
• Usar JSON mode sem schema. O responseMimeType: "application/json" retorna JSON, mas sem responseSchema ele inventa campos. Em produção, sempre passe o schema Zod ou JSON Schema explícito.
• Não monitorar custo por feature. Adicione telemetria de tokens por endpoint. Já peguei cliente queimando $4k/mês em um único endpoint que podia rodar no Flash por $200.

O que esperar do Gemini 4 (e quando)

Não tenho bola de cristal, mas os sinais são claros. Pelo padrão do Google, se o 3.5 Pro foi morto, o Gemini 4 deve aparecer antes do Google I/O 2026 — provavelmente entre fevereiro e abril. O foco deve ser:

• Fechar o gap em raciocínio matemático e lógico com GPT-5 e Claude Opus.
• Expandir a janela de contexto para 2M+ tokens com custo decente.
• Agentes mais estáveis: loops longos sem degradação de contexto.
• Provável integração nativa com o Gemini CLI e o Jules (agente de coding do Google).

Na minha leitura, o Google está repetindo o playbook do Gemini 1.5 → 2.5: pula uma versão intermediária quando precisa de um salto qualitativo. Em 2024 funcionou. Em 2026, com a concorrência mais madura, a régua subiu.

FAQ — Perguntas que devs reais estão fazendo

1. O Gemini 3.5 Pro foi oficialmente cancelado ou é só atraso?

Oficialmente, o Google nunca admitiu cancelamento. Mas a ausência por três meses consecutivos, somada à análise da Semi Analysis citando fontes internas, indica arquivamento. O silêncio corporativo aqui é a mensagem.

2. Devo migrar meus projetos do Gemini 2.5 Pro para outro modelo agora?

Não. Se o Gemini 2.5 Pro está rodando bem e o custo compensa, mantenha. A migração só vale se você identifica gap real de qualidade. O 2.5 Pro ainda é excelente em multimodal e contexto longo. Não migre por hype — migre por métrica.

3. Como me preparar para a chegada do Gemini 4 sem reescrever código?

Implemente o adapter que mostrei acima. Centralize a escolha de modelo em um único arquivo. Quando o Gemini 4 sair e você quiser testar, é uma linha. Acompanhe o canal oficial Release Notes da SDK @google/genai e o repositório no GitHub.

4. O Gemini 4 será open source como o Llama 4?

Improvável. O Google abriu o Gemma como contraponto estratégico, mas a linha Gemini Pro permanece proprietária. Se você precisa de pesos abertos, o caminho continua sendo Llama 4, Mistral ou Qwen.

5. Vale a pena assinar o Google AI Studio Pro agora?

Se você usa diariamente para prototipagem, sim — o custo compensa pelo limite expandido. Se usa esporadicamente, o tier free é suficiente. Não assine esperando pelo Gemini 4; a política de preços muda com lançamento.

A real é essa: o Google está sob pressão real e isso é bom para nós, devs. Modelos melhores, preços mais agressivos, ciclos de inovação menores. Quem se adapta rápido ao padrão “modelo como adapter versionado” sai na frente. Quem ainda tem o nome do modelo hardcoded no controller vai chorar a cada release do Google.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto. Se quiser que eu faça um benchmark real entre Gemini 2.5 Pro, GPT-5 e Claude Opus 4.1 em tarefas de codificação agêntica, comenta aí que monto o post na sequência.