GitHub Copilot vai aposentar seis modelos em setembro de 2026

O GitHub anunciou no changelog oficial (publicado em 31 de julho de 2026) a descontinuação de seis modelos em todas as experiências do Copilot: Copilot Chat, edições inline, os modos ask e agent e o autocompletar de código. A data de corte é 1º de setembro de 2026, e vale para todo mundo que hoje aponta workflows ou integrações para esses modelos.

O que sai e para onde migrar

A tabela da fonte é direta. Cada modelo aposentado vem com uma alternativa sugerida:

• Gemini 3.1 Pro → Gemini 3.6 Flash
• Claude Opus 4.5 e Claude Opus 4.6 → Claude Opus 4.7, 4.8 ou Opus 5
• Claude Sonnet 4.5 → Claude Sonnet 5
• Claude Sonnet 4.6 → Claude Sonnet 5
• Raptor Mini → MAI-Code-1-Flash

Vale notar uma exceção importante: o Claude Sonnet 4.6 continua disponível para assinantes individuais do Copilot em planos anuais, justamente para que eles não fiquem sem uma opção da família Sonnet. Ou seja, a aposentadoria do 4.6 não atinge esse recorte de clientes.

Por que isso importa na prática

Depreciação de modelo em ferramenta de IA não é como depreciar um endpoint de API tradicional, mas o raciocínio de manutenção é parecido: você tem uma dependência externa cujo comportamento vai mudar em uma data conhecida. A diferença é que aqui a substituição não é só um find & replace de string, ela pode alterar qualidade de resposta, latência e custo.

Repare que várias das alternativas sugeridas são modelos Flash (Gemini 3.6 Flash, MAI-Code-1-Flash), ou seja, variantes otimizadas para velocidade e custo mais baixo. Se o seu time escolheu um Pro ou Opus por um motivo específico (raciocínio mais denso em refactors grandes, por exemplo), trocar por um Flash sem testar é assumir que a tarefa vai render igual, o que nem sempre acontece. O caminho pragmático é medir antes: rode os mesmos prompts nos dois modelos e compare o resultado no seu contexto real, não no benchmark de marketing.

Quem precisa agir, e como

O GitHub deixa claro que não é preciso fazer nada para remover os modelos: eles simplesmente somem após a data. A ação necessária é do outro lado, garantir que o modelo de substituição esteja habilitado antes que o antigo desapareça, para não deixar o time no vácuo.

Para administradores de Copilot Enterprise, o ponto de atenção é a política de modelos. Segundo o changelog, pode ser necessário liberar o acesso à alternativa nas model policies dentro das configurações do Copilot. A verificação sugerida é objetiva:

1. Abra suas configurações individuais do Copilot e confirme que a política está habilitada para o modelo específico.
2. Com a política ativa, o modelo aparece no seletor do Copilot Chat, tanto no VS Code quanto no github.com.
3. Só então ajuste os workflows e integrações para apontar para o modelo suportado.

Se a política não estiver habilitada, o desenvolvedor simplesmente não enxerga a opção no seletor, e vai bater na parede exatamente no dia da virada. É o tipo de problema que se resolve em cinco minutos com antecedência e vira incidente se descoberto tarde.

Quando isso pode não ser problema pra você

Se o seu uso do Copilot é o padrão (autocompletar e chat com o modelo default), a transição tende a ser transparente, sem nenhuma configuração manual. A dor real está concentrada em dois grupos: quem fixou um modelo específico em automações, scripts ou configurações de projeto, e administradores enterprise que gerenciam políticas de acesso para times grandes. Para esses, tratar a mudança como uma tarefa de manutenção agendada, com janela de teste, é bem mais barato do que descobrir a quebra em produção.

O GitHub orienta clientes Enterprise com dúvidas a procurarem o account manager, e mantém a documentação de modelos disponíveis atualizada. O recado central é simples: a data está marcada, a lista de substitutos já existe, e o único erro caro é deixar para revisar as integrações depois do dia 1º.

Fonte: GitHub Changelog