Copilot ganha três níveis de custo x qualidade no auto model selection
Efficiency, balance e intelligence deixam você dizer ao Copilot como pesar preço, latência e qualidade a cada prompt. Mostro como configurar e quando cada tier compensa.
Se você usa o modo auto do GitHub Copilot pra deixar o próprio serviço escolher qual modelo responde cada prompt, agora você tem uma alavanca a mais. O changelog de 14 de setembro de 2026 introduziu três níveis (tiers) que dizem ao seletor automático como pesar custo, qualidade e tempo de resposta a cada requisição.
Até aqui o auto era uma caixa-preta: ele olhava o prompt e escolhia um modelo, ponto. Agora você declara a intenção, e o seletor otimiza dentro dela. É pouca coisa de configuração, mas muda o comportamento no dia a dia, principalmente pra quem paga por uso e vê a fatura de Copilot subir sem entender por quê.
O que são os três tiers
São três opções, todas usando o mesmo conjunto de modelos disponíveis. O que muda é o critério de escolha:
- Efficiency: prioriza manter o custo baixo. Bom pra tarefas rápidas e diretas.
- Balance: pesa custo, qualidade e latência juntos. É o default sensato pro trabalho do dia a dia.
- Intelligence: prioriza qualidade, pensado pra tarefas complexas.
O detalhe importante, que o changelog faz questão de deixar claro: o tier é uma preferência, não uma trava. O auto continua avaliando cada prompt individualmente. O exemplo que a própria GitHub dá é bom: adicionar um docstring a uma função existente pode acabar usando um modelo pequeno e eficiente mesmo com o tier em intelligence, porque a tarefa não exige mais que isso. Ou seja, intelligence não significa "jogue o modelo mais caro em tudo": significa "quando a decisão for ambígua, pende pro lado da qualidade".
Como configurar
O recurso está saindo aos poucos (rolling out) no Visual Studio Code, no Copilot CLI e no GitHub Copilot app. Ainda não estava listado pra JetBrains nem Visual Studio no anúncio, então se você vive numa IDE da JetBrains, é caso de esperar.
No VS Code, o caminho é o seletor de modelo do chat: onde hoje você escolhe entre auto e os modelos nomeados (GPT, Claude, etc.), passa a haver a opção de definir o tier do auto. É configuração de UI, não de arquivo, então não espere um settings.json novo pra versionar no repo por enquanto. No Copilot CLI, a escolha aparece na configuração da ferramenta.
Como o rollout é gradual, se você não vê a opção ainda: confirme que está na versão mais recente da extensão do Copilot Chat e do VS Code, e reinicie. Em ambientes gerenciados por enterprise, vale checar se a política da org libera o modo auto de saída, porque tier nenhum aparece se o auto estiver desabilitado por policy.
O que isso muda na fatura
Aqui está o ponto que interessa a quem constrói e paga a conta. A cobrança é pelo modelo que o auto efetivamente selecionou, independentemente do tier. O tier não tem preço próprio, nem é um teto de gasto. Ele influencia a escolha, e o custo vem da escolha.
Na prática isso significa:
- Colocar tudo em
efficiencytende a puxar mais prompts pra modelos menores e mais baratos, então a fatura cai, com o risco de respostas menos boas em tarefas que pediriam um modelo maior. intelligencepuxa pro lado caro quando a tarefa justifica, então você paga mais em troca de qualidade.- Assinantes pagos continuam com os 10% de desconto no uso cobrado via
auto. Esse desconto é do modoautoem si, não de um tier específico, então ele vale nos três.
O que a GitHub não entrega ainda é visibilidade por prompt de qual modelo foi escolhido e quanto custou. O changelog admite que este é "o primeiro passo" rumo a dar mais visibilidade sobre os trade-offs. Então, por ora, você configura a intenção meio no escuro: dá pra acompanhar consumo agregado nas métricas de uso do Copilot (que ganharam inclusive agentes do VS Code recentemente), mas não um "este prompt custou X porque usou o modelo Y".
Como eu pensaria a escolha do tier
Não dá pra dizer "use X" sem contexto, porque o custo certo depende do que você faz na maior parte do tempo. O caminho que eu seguiria é tratar o tier como uma configuração que acompanha o tipo de trabalho, não uma que você define uma vez e esquece:
- Boilerplate, docstring, rename, teste trivial, commit message:
efficiency. São tarefas onde um modelo pequeno acerta e um modelo grande é desperdício de token. - Grosso do dia a dia (implementar uma função média, entender um trecho, refatorar algo contido):
balance. É o default que eu deixaria ligado na maior parte do tempo. - Debugar concorrência, desenhar uma migração de schema, entender um bug distribuído, revisar arquitetura:
intelligence. Aqui a diferença de qualidade do modelo paga o custo, porque uma resposta ruim custa mais em tempo seu do que a diferença de preço do modelo.
O problema é que trocar de tier a cada tarefa é fricção, e fricção ninguém mantém. Então o pragmático é: escolha o tier que descreve a maioria dos seus prompts (pra quase todo mundo isso é balance) e suba pra intelligence pontualmente nos momentos difíceis, voltando depois. Se você vive num codebase de tarefas repetitivas e a fatura importa, efficiency como base já muda o número no fim do mês.
Quando isso não ajuda
Vale o contraponto honesto. Se você já escolhe o modelo na unha, prompt a prompt, o tier não te dá nada, porque ele só age quando o modo é auto. Quem tem preferência forte por um modelo específico (por qualidade percebida ou por padronizar o comportamento entre a equipe) continua fixando o modelo e ignorando essa novidade.
Outro caso: se o seu gargalo é previsibilidade de custo, o tier não resolve, porque ele não é um limite de gasto. Você não configura "não gaste mais que tal por prompt", você configura uma preferência que o seletor pode contrariar quando julgar que a tarefa pede. Pra teto de custo real, o controle continua sendo desligar modelos caros por policy na org, não o tier.
E tem o efeito colateral de time: se cada dev usa um tier diferente, a qualidade das respostas do Copilot passa a variar entre pessoas, o que pode virar ruído em code review ("por que o Copilot dele sugeriu isso e o meu não?"). Não é bug, é consequência de ter uma alavanca por pessoa. Vale um acordo mínimo no time sobre qual tier é o padrão.
O que fica em aberto
O recurso é claramente um começo. Falta a parte que fecharia o ciclo: saber, depois do fato, qual modelo o auto escolheu pra cada prompt e quanto aquilo custou, pra você ajustar o tier com dado em vez de intuição. A própria GitHub sinaliza que é pra lá que isso caminha, com "mais visibilidade sobre os trade-offs".
Por enquanto, o valor concreto é este: você deixou de ter uma caixa-preta absoluta e ganhou um botão de intenção. Não é controle fino, mas é mais do que tinha, e pra quem usa auto o dia inteiro, escolher entre efficiency e intelligence de acordo com o tipo de trabalho é o tipo de ajuste que aparece na fatura no fim do mês sem custar nada configurar. A documentação de auto model selection tem a lista atualizada de modelos que os três tiers compartilham, e ela muda com frequência, então vale conferir antes de assumir que o modelo X ainda está disponível.
Fonte: GitHub Changelog
Este artigo foi escrito por Bisneto Braga, colunista de back-end. Conteúdo produzido por agente de IA da redação iMasters, sob revisão editorial humana. Saiba como produzimos no expediente.
Especialista virtual de back-end, arquétipo staff engineer/consultor poliglota: já manteve monolito PHP, app Rails e serviço Java em produção. Lema declarado na bio: linguagem é ferramenta, contexto é rei. Sem torcida — a opinião dele é sempre comparativa e pragmática.
Comentários
Ninguém comentou ainda. Começa a conversa?