Seis modelos saem do Copilot em 19/10: o que testar até lá
Imagine que o time costuma usar o GPT-5.4 no Copilot para editar uma parte delicada do projeto. O aviso sugere outro modelo. Parece uma troca simples até alguém abrir o editor numa tarefa urgente e descobrir que a opção não aparece na conta, ou que o mesmo pedido produz um diff que exige mais revisão.
O GitHub anunciou a retirada de seis modelos em 19 de outubro de 2026, em experiências como Copilot Chat, edições inline, modos Ask e Agent e sugestões de código. Ainda dá tempo de fazer um ensaio pequeno no repositório, sem esperar a primeira regressão para começar a comparar.
Veja qual troca afeta seu fluxo
O aviso indica estas alternativas:
- Gemini 3.7 Flash → Gemini 3.8 Flash;
- GPT-5.5 e GPT-5.4 → GPT-5.6 Sol;
- GPT-5.4 mini e GPT-5 mini → GPT-5.6 Luna;
- Grok 4.5 → Grok 4.6.
São sugestões da plataforma. Elas não garantem a mesma qualidade, latência ou disponibilidade para a sua equipe. Antes de comparar, anote o modelo usado hoje e onde ele entra no trabalho: conversa sobre código, edição de um arquivo, sugestões no editor ou execução de uma tarefa em modo agente. Se alguma configuração fixar o modelo na IDE ou em uma integração, inclua-a no inventário.
Confira o acesso antes de medir a qualidade
Em contas de empresa, não basta encontrar o nome do modelo numa lista pública. A disponibilidade pode depender da política definida por quem administra o Copilot. Em ambientes Enterprise, a documentação da GitHub aponta o caminho AI controls → Copilot → Configure models para revisar quais modelos estão habilitados, desabilitados ou delegados à organização ou a equipes. Se você não administra essa política, pergunte qual alternativa estará liberada para o seu grupo e confirme na interface que você realmente usa.
Isso evita gastar tempo comparando uma opção que o time não poderá selecionar. Também separa dois problemas diferentes: acesso ao modelo e resultado do modelo.
Repita tarefas reais, não um prompt de demonstração
Escolha dois ou três casos pequenos do próprio repositório. Por exemplo:
- Peça para explicar um módulo que tem uma regra de negócio pouco óbvia. Confira se a resposta aponta para o código certo e não inventa comportamento.
- Peça uma alteração localizada em uma função que já tem testes. Rode os testes e veja o diff, inclusive o que mudou fora do pedido.
- Se o time usa modo agente, peça uma mudança curta que passe por mais de um arquivo. Verifique se o agente respeitou os limites combinados e quais ajustes você precisou fazer depois.
Rode os mesmos pedidos, no mesmo estado do repositório, com o modelo atual e a alternativa disponível. Defina antes o que seria um resultado aceitável. Registre se os testes passaram, quanto trabalho manual sobrou e quanto tempo levou até um diff revisável. Consulte também os limites e o custo aplicáveis ao plano do time; não presuma que trocar o nome do modelo mantém essas condições. Use dados de teste, sem copiar credenciais ou informações sensíveis para o chat.
Não é preciso fabricar uma nota única para declarar um vencedor. Talvez a alternativa explique bem o módulo e precise de mais correções ao editar código. Essa diferença já ajuda a decidir onde usá-la e onde manter uma revisão mais cuidadosa.
Antes de 19/10, deixe registrado qual modelo está habilitado, quais tarefas passaram no ensaio e quem ajustará as configurações que ainda apontam para um modelo retirado. Se o cliente ou a política de acesso mudar, repita os casos. A lista de alternativas resolve a pergunta “por onde começar?”; o teste no seu fluxo resolve a pergunta que interessa à equipe.