A notícia parece pequena: dois modelos saem do catálogo do GitHub Copilot em 31 de julho e o GitHub já aponta duas substituições. Só que, na prática, isso não é uma nota de manutenção. É uma mudança operacional.
Quando o catálogo de modelos muda dentro do Copilot, a conversa deixa de ser “qual modelo eu gosto mais?” e passa a ser “qual modelo meu time realmente pode usar, com qual custo, em quais clientes e sob qual política?”. É a mesma pressão que já apareceu quando o blog falou de como as contas do GitHub Copilot estão explodindo: a camada financeira e a camada de governança já viraram parte do produto.
O anúncio do GitHub diz que Gemini 2.5 Pro e Gemini 3 Flash serão descontinuados em todas as experiências do Copilot no dia 31 de julho de 2026. As alternativas sugeridas são Gemini 3.1 Pro e Gemini 3.5 Flash. Para quem administra Copilot em empresa, o texto ainda traz um recado importante: admins podem precisar habilitar esses modelos alternativos nas políticas da organização antes da virada.
Esse detalhe muda tudo. Não é apenas trocar um nome no seletor. É revisar política, fallback, documentação interna, treinamento de time e, em alguns casos, a conta.
O que o GitHub anunciou de fato
O changelog do GitHub é direto. A partir de 31 de julho, Gemini 2.5 Pro e Gemini 3 Flash saem de cena em Copilot Chat, inline edits, ask mode, agent mode e code completions. O próprio GitHub recomenda Gemini 3.1 Pro como sucessor do 2.5 Pro e Gemini 3.5 Flash como sucessor do 3 Flash.
Também chama atenção o que o comunicado não promete. O GitHub não diz que a troca é neutra em comportamento, preço ou governança. Diz apenas que os modelos antigos saem, que existem alternativas e que admins de Copilot Enterprise talvez precisem conferir se elas estão liberadas na política.
Isso conversa diretamente com a documentação de modelos suportados do Copilot, que hoje já mostra os modelos ativos, o histórico de aposentadorias e a ideia de que disponibilidade muda com o tempo. Em outras palavras: o catálogo do Copilot não é fixo. Ele é gerenciado como peça viva do produto.
O que muda no custo, e por que isso importa
Aqui está o ponto menos confortável dessa história. Os substitutos não são equivalentes em preço.
Na tabela de pricing do GitHub, o Gemini 2.5 Pro aparece com US$ 1,25 por 1 milhão de tokens de entrada e US$ 10 por 1 milhão de tokens de saída. O sucessor sugerido, Gemini 3.1 Pro, sobe para US$ 2 de entrada e US$ 12 de saída no tier padrão, com um tier ainda mais caro quando o contexto passa de 200 mil tokens.
No caso do modelo rápido, o salto é ainda mais fácil de ignorar do que deveria. Gemini 3 Flash custa US$ 0,50 de entrada e US$ 3 de saída. O recomendado no lugar dele, Gemini 3.5 Flash, vai para US$ 1,50 de entrada e US$ 9 de saída.
Ou seja: no papel, isso é um ajuste de catálogo. No orçamento, pode ser a remoção de uma opção barata e a obrigatoriedade de migrar para alternativas mais caras. Para times que já estão medindo custo por tarefa, isso não é detalhe. É mudança de regime.
É exatamente por isso que a discussão recente sobre custo invisível dos agentes ficou tão importante. O problema não é só assinar uma ferramenta. O problema é o quanto ela consome quando entra de verdade no fluxo diário.
O Auto não elimina a necessidade de governança
É tentador pensar que o Auto model selection resolve esse tipo de transição sozinho. E, de fato, a documentação do GitHub vende o Auto como uma camada inteligente de roteamento por complexidade, disponibilidade e eficiência. Em alguns casos, isso ajuda bastante.
Mas existe um limite claro: o Auto só trabalha com o conjunto de modelos que continuam disponíveis para aquele plano, naquele cliente e dentro das políticas permitidas pela organização. Se o modelo substituto não estiver liberado, atualizado ou compatível com a política da empresa, o Auto não faz mágica. Ele respeita as restrições.
Tem outro detalhe prático. O GitHub informa que o Auto tenta fazer roteamento com foco em eficiência e ainda oferece 10% de desconto em certos usos pagos. Só que isso não apaga o fato principal: se o catálogo disponível ficou mais caro, o piso econômico da operação também pode subir.
Essa é a mesma lógica que apareceu quando o blog analisou como o MAI-Code-1-Flash muda a conta entre custo, latência e escolha de modelo. O seletor de modelos deixou de ser cosmético. Ele virou política de operação.
O ponto que muita equipe vai descobrir tarde demais: cliente e versão
A documentação de modelos suportados do GitHub traz mais um alerta silencioso. Modelos Gemini recentes dependem de versões mínimas de IDE e plugin para aparecerem ou funcionarem direito em alguns ambientes. O próprio GitHub lista, por exemplo, VS Code 1.115.0 ou superior e versões mínimas equivalentes para outros clientes.
Na prática, isso significa que a migração não depende só de liberar um modelo na política. Também depende de o time estar em versões de cliente compatíveis. Senão o admin libera o substituto, o changelog diz que a alternativa existe, mas parte da empresa continua sem enxergar aquilo no dia a dia.
Esse tipo de atrito parece banal até virar chamado interno, documentação desatualizada e percepção de que “o Copilot sumiu com o modelo”. Não sumiu. O catálogo mudou e a superfície cliente não acompanhou.
Checklist curto para admins rodarem agora
Se a sua empresa usa Copilot Business ou Enterprise, esse é o tipo de mudança que merece revisão antes do prazo, não depois.
Primeiro, vale revisar quais políticas de acesso a modelos estão ativas hoje. Se Gemini 3.1 Pro e Gemini 3.5 Flash não estiverem explicitamente permitidos, o time pode perder os antigos sem receber substituição prática equivalente.
Depois, faz sentido checar quais workflows, guias internos e vídeos de treinamento citam Gemini 2.5 Pro ou Gemini 3 Flash nominalmente. Em muitas empresas, o problema não está no produto; está no legado operacional que continua ensinando o time a usar algo que vai desaparecer do seletor.
O terceiro ponto é orçamento. Se havia uso recorrente do 3 Flash como opção rápida e barata, a troca para 3.5 Flash merece simulação de consumo. Se havia equipes usando 2.5 Pro em tarefas grandes de contexto, o tier de long context do 3.1 Pro pode mudar a conta mais do que parece.
Por fim, vale validar cliente, plugin e superfície. O que aparece no GitHub.com nem sempre aparece igual no VS Code antigo, no JetBrains sem update ou em ambientes mais travados de TI.
O que isso diz sobre o Copilot agora
A leitura mais útil dessa notícia não é “o GitHub aposentou dois modelos do Google”. A leitura útil é outra: o Copilot está virando um catálogo governado, não uma interface estática de chat.
Quando isso acontece, modelo passa a funcionar como dependência operacional. Tem ciclo de vida, política, custo, compatibilidade de cliente e efeito direto em treinamento e suporte. É muito mais parecido com administrar plataforma do que com “deixar cada dev escolher no dropdown”.
Quem entender isso cedo vai tratar a mudança de 31 de julho como manutenção preventiva. Quem não entender tende a descobrir o problema no pior momento: quando o modelo antigo some, o novo custa mais, parte do time não vê a alternativa e a área inteira percebe tarde que governança de IA já virou trabalho de verdade.
