O GitHub marcou para 2 de outubro de 2026 a descontinuação de quatro modelos no GitHub Copilot: Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code e Claude Opus 4.7. A mudança vale para as experiências do Copilot citadas pelo GitHub, incluindo Chat, edições inline, modos ask e agent e completions. Para evitar uma troca de última hora, a migração deve ser tratada em duas frentes: escolher o substituto adequado ao tipo de tarefa e confirmar que o novo modelo está liberado pelas políticas da organização ou da empresa.
O anúncio oficial de 3 de setembro já traz um substituto recomendado para cada modelo: Gemini 3.8 Flash para as duas versões Gemini que saem, Kimi K3 para Kimi K2.7 Code e Claude Opus 5 para Claude Opus 4.7. O GitHub também avisa que administradores de Copilot Business e Copilot Enterprise podem precisar habilitar os modelos alternativos nas políticas de modelos. A referência principal é o changelog de descontinuação do GitHub.
Quais modelos saem e qual migração o GitHub recomenda
| Modelo descontinuado | Data | Alternativa sugerida pelo GitHub | Cenário de uso mais próximo |
|---|---|---|---|
| Gemini 3.5 Flash | 02/10/2026 | Gemini 3.8 Flash | Respostas rápidas, pequenas edições, dúvidas de sintaxe e tarefas leves ou repetitivas |
| Gemini 3.6 Flash | 02/10/2026 | Gemini 3.8 Flash | Respostas rápidas, pequenas edições, dúvidas de sintaxe e tarefas leves ou repetitivas |
| Kimi K2.7 Code | 02/10/2026 | Kimi K3 | Fluxos agentic de várias etapas e trabalho com contexto longo em bases de código maiores |
| Claude Opus 4.7 | 02/10/2026 | Claude Opus 5 | Raciocínio profundo, depuração complexa e análise de problemas com múltiplas etapas |
A coluna de cenário não é apenas uma aproximação por nome. A própria documentação de comparação do Copilot classifica Gemini 3.8 Flash como opção de ajuda rápida para tarefas simples ou repetitivas; Kimi K3 como modelo voltado a coding agentic e contexto longo; e Claude Opus 5 como modelo de raciocínio profundo e debugging. Consulte a comparação oficial de modelos antes de padronizar uma escolha para toda a equipe.
Gemini 3.5 e 3.6 Flash: a migração mais direta é para Gemini 3.8 Flash
Para quem usa Gemini 3.5 Flash ou Gemini 3.6 Flash em tarefas curtas, a troca sugerida é a mais direta do grupo. O GitHub lançou Gemini 3.8 Flash no Copilot em 3 de setembro e o descreve, na documentação de comparação, como adequado a respostas rápidas e tarefas leves. Isso faz sentido para fluxos que priorizam baixa latência: pequenas alterações, funções utilitárias, perguntas de sintaxe, explicações curtas e protótipos rápidos.
Em Copilot Business e Enterprise, Gemini 3.8 Flash pode já estar disponível quando a política de habilitação padrão de modelos lançados está ativa. No anúncio de disponibilidade do modelo, o GitHub informa que novos modelos são habilitados automaticamente sob a política padrão, salvo quando o administrador desativa essa regra global ou bloqueia explicitamente o modelo. Portanto, a ação do admin não é necessariamente “ligar” o Gemini 3.8 Flash, mas confirmar o estado real da política no ambiente antes do prazo.
Kimi K2.7 Code: Kimi K3 exige atenção especial dos administradores
A migração de Kimi K2.7 Code para Kimi K3 merece um cuidado adicional. O GitHub posiciona Kimi K3 para tarefas agentic de múltiplas etapas e trabalho de contexto longo em grandes bases de código. Isso pode torná-lo uma evolução natural para fluxos que dependem de exploração de repositório, planejamento de alterações conectadas e execução de tarefas que atravessam vários arquivos.
Há, porém, uma diferença de governança importante: na política de disponibilidade padrão do Copilot, o GitHub lista modelos de pesos abertos, incluindo Kimi K3, entre os modelos que ficam desabilitados por padrão e não são habilitados automaticamente apenas porque a política “Default availability for released models” está ativa. Em uma organização ou enterprise, isso significa que o administrador deve verificar a página de modelos e habilitar Kimi K3 explicitamente quando a política superior permitir. A documentação relevante é About default availability of Copilot models.
O GitHub também registra considerações específicas para Kimi K3 e recomenda que empresas avaliem capacidades, limitações e salvaguardas de acordo com seus requisitos. Assim, uma migração corporativa não deveria ser apenas um “find and replace” do nome do modelo: vale testar tarefas reais, comportamento agentic, políticas de segurança e compatibilidade com o cliente usado pela equipe.
Claude Opus 4.7: Claude Opus 5 mantém o foco em raciocínio profundo
Para Claude Opus 4.7, o substituto indicado é Claude Opus 5. Os dois ficam na faixa de uso que o GitHub associa a raciocínio profundo e depuração: problemas complexos, refatorações grandes, decisões de arquitetura, análise de múltiplos arquivos e investigação de comportamento de sistemas.
Isso não significa que respostas serão idênticas. Uma troca de geração pode alterar estilo, latência, consumo de créditos, uso de ferramentas e resultados em prompts já estabilizados. Se a equipe possui prompts, instruções de repositório, agentes ou automações ajustados ao Opus 4.7, rode um conjunto de regressão com tarefas representativas antes de tornar Opus 5 o padrão.
O que o usuário precisa alterar antes de 2 de outubro
- Liste onde o modelo está fixado. Verifique seletores de modelo no Chat, configurações de completions, instruções de agentes, automações, integrações ou qualquer fluxo que faça referência explícita a um dos quatro modelos.
- Troque pelo substituto sugerido e teste no mesmo cliente. A disponibilidade varia por plano e por superfície. A tabela de modelos suportados no Copilot é a referência para conferir plano, cliente e status.
- Não presuma que mudar o modelo do Chat muda as sugestões inline. O GitHub documenta essas seleções separadamente. A alteração de modelo do Chat não muda o modelo das sugestões inline; quando o cliente permite, o modelo de completions precisa ser configurado em seu próprio seletor.
- Atualize clientes e extensões. Para trocar modelos de sugestões inline, o GitHub exige versões compatíveis do IDE e da extensão do Copilot.
- Compare qualidade, latência e custo. Modelos diferentes podem consumir créditos de forma diferente. Um substituto tecnicamente compatível pode não ser a melhor escolha econômica para toda tarefa.
Checklist para administradores de Copilot Business e Enterprise
- Abra as configurações do Copilot da organização ou enterprise e revise a área de Models.
- Confirme que Gemini 3.8 Flash, Kimi K3 e Claude Opus 5 aparecem como opções compatíveis com o plano e com os clientes usados pela equipe.
- Verifique se algum modelo está imposto como Enabled ou Disabled no nível de enterprise; uma organização não pode sobrescrever uma decisão superior.
- Para Gemini 3.8 Flash e Claude Opus 5, confira se a política de disponibilidade padrão ou uma configuração explícita já permite acesso.
- Para Kimi K3, faça uma checagem explícita: por ser listado entre os modelos de pesos abertos, ele não entra na habilitação automática padrão.
- Se usuários precisam escolher modelos manualmente, confirme que a política da organização permite essa seleção nas superfícies relevantes.
- Revise configurações de modelo padrão em ambientes gerenciados. Desde 2 de setembro, o GitHub permite definir qualquer modelo padrão compatível em enterprise-managed settings; um padrão apontando para um modelo que será aposentado precisa ser revisado.
- Faça um piloto com usuários representativos e documente o fallback caso um modelo não esteja disponível em um determinado cliente.
As instruções oficiais para governança estão em Managing the availability of models in an organization e em Configuring access to AI models in GitHub Copilot.
Como testar a migração sem quebrar o fluxo
Use um pequeno conjunto de tarefas que represente o trabalho real da equipe. Para Gemini 3.8 Flash, meça se pequenas edições, respostas de sintaxe e geração de utilitários continuam rápidas e corretas. Para Kimi K3, teste navegação em repositórios maiores, tarefas agentic com vários passos e alterações distribuídas em múltiplos arquivos. Para Claude Opus 5, priorize bugs difíceis, decisões de arquitetura, refatorações e análise de logs ou comportamento sistêmico.
Além da qualidade da saída, registre latência, necessidade de reprompt, consumo de créditos, uso de ferramentas e diferenças de comportamento em instruções já existentes. O objetivo é descobrir antes de 2 de outubro se a substituição indicada pelo GitHub é suficiente ou se a equipe precisa adaptar prompts e procedimentos.
Auto pode reduzir dependência de um modelo fixo, mas continua sujeito às políticas
Para fluxos em que não existe exigência de usar um fornecedor específico, o seletor Auto pode reduzir a dependência de um nome de modelo. O GitHub informa que a seleção automática leva em conta a tarefa e a disponibilidade e pode desviar de modelos degradados ou indisponíveis. Ainda assim, Auto só escolhe entre modelos compatíveis com o plano e permitidos pelas políticas administrativas. Ele não contorna um bloqueio de modelo nem garante que uma família específica será usada.
Antes de adotar Auto como resposta universal à aposentadoria, confira se o fluxo depende de comportamento reproduzível, custo previsível, uma família de modelo específica ou requisitos de compliance. A documentação oficial está em About Copilot auto model selection.
O que acontece depois do prazo
O GitHub afirma que não é necessária nenhuma ação para remover os modelos depois que forem descontinuados. A ação necessária é o inverso: atualizar fluxos e integrações para modelos suportados antes de 2 de outubro de 2026. Se uma organização depende de políticas restritivas, a parte crítica é não esperar o usuário descobrir a indisponibilidade no dia da troca.
Em resumo: migre Gemini 3.5/3.6 Flash para Gemini 3.8 Flash, Kimi K2.7 Code para Kimi K3 e Claude Opus 4.7 para Claude Opus 5; teste cada substituição no cliente realmente usado; e, em Business ou Enterprise, valide as políticas com atenção especial ao Kimi K3. Essa sequência transforma uma aposentadoria de modelos em uma mudança controlada, em vez de uma interrupção de workflow.
