Escolher um modelo no GitHub Copilot parece uma decisão de preço até o momento em que você precisa explicar a mesma correção pela quarta vez. A chamada continua barata, mas alguém está lendo as respostas, descartando alterações e tentando descobrir por que o trabalho não anda.

Eu não adotaria “usar sempre o mais barato” como regra de equipe. Minha preferência seria economizar onde a tarefa está bem resolvida na cabeça de quem pede e investir mais capacidade onde ainda precisamos entender o problema. Há uma diferença importante entre pedir que um agente execute um plano e pedir que ele descubra qual plano faz sentido.

Os exemplos acima partem dessa ideia. São caminhos que eu avaliaria, com espaço para mudar de escolha conforme aparecem evidências. Usar Sol ou Opus no diagnóstico não obriga a manter esse modelo em cada edição de arquivo. Também não faz sentido interromper uma tarefa que está andando bem só para economizar na próxima chamada.

Uma distinção ajuda: aqui falamos principalmente de trocar o modelo que trabalha dentro do agente do Copilot. O agente também depende das ferramentas disponíveis, do contexto que recebe e das permissões para agir. Mudar o modelo altera uma parte desse conjunto.

Antes do nome do modelo, eu olharia para a dúvida

Imagine dois pedidos: “atualize este comando no README” e “revise o procedimento de recuperação do serviço”. Ambos geram documentação. No primeiro, podemos fornecer o comando correto e conferir a edição rapidamente. No segundo, alguém precisa investigar dependências, confrontar o texto com o sistema e descobrir se a recuperação proposta funciona.

Por isso, o tipo de arquivo me diz pouco sobre a capacidade necessária. Um documento pode exigir mais análise do que uma alteração de código. Um script de vinte linhas pode provocar mais estrago do que uma refatoração extensa.

O comparativo do GitHub ajuda a formar uma primeira hipótese: Luna e Haiku para trabalho simples e rápido; Terra e Sonnet para tarefas cotidianas mais amplas; Sol e Opus entre as opções para trabalho complexo. Eu usaria essa orientação como ponto de partida para testar, com atenção ao contexto e à verificação.

As versões de referência são GPT-6 Luna, GPT-6.1 Terra, GPT-6.1 Sol e Claude Haiku, Sonnet e Opus 5.5, consultadas em 27/10/2026. A disponibilidade depende do cliente, do plano e das políticas da empresa.

Entre as fontes consultadas, não encontramos um estudo público que compare esses seis modelos no mesmo Copilot, com tarefas, ferramentas e configurações equivalentes. Seria confortável oferecer uma tabela definitiva de vencedores. A evidência disponível pede mais cuidado.

Os estudos ajudam a enxergar onde a escolha pode falhar

O SWE-Bench Mobile avaliou 22 combinações de agentes e modelos em desenvolvimento iOS. O mesmo modelo teve diferenças de desempenho de até seis vezes conforme o agente utilizado. É um recorte específico, com outras configurações, mas ele coloca uma dúvida útil sobre qualquer ranking: quanto do resultado vem do modelo e quanto vem do ambiente em que ele trabalha?

Na prática, eu verificaria se o agente consegue ler os arquivos certos, executar os testes e obter os logs antes de concluir que preciso de um modelo mais caro. Se ele está investigando sem acesso à evidência, trocar de modelo pode apenas tornar a investigação mais cara.

Nos testes, existe outra armadilha. O TestGenEval, publicado no ICLR 2025, avaliou geração e complementação de testes em 11 repositórios Python e identificou dificuldades com cobertura e asserções em caminhos complexos. O estudo trata de modelos anteriores; sua contribuição aqui é mostrar por que gerar código de teste e testar bem precisam ser avaliados separadamente.

Eu deixaria um modelo econômico preencher casos repetitivos quando o comportamento esperado já está definido. Para descobrir quais regras precisam ser protegidas, sobretudo em autorização, concorrência ou recuperação de falhas, dedicaria mais atenção à análise. Uma suíte que fica verde porque o agente adaptou a expectativa ao código pode esconder exatamente o problema que deveria revelar.

Economia aparece na entrega, não apenas na chamada

O preço no Copilot depende do modelo e dos tokens consumidos, com categorias de entrada, saída e cache. No Business e no Enterprise, há créditos agrupados na entidade de cobrança, e um crédito equivale a US$ 0,01. Esse preço unitário importa. Ainda falta medir quanto trabalho foi necessário para chegar à entrega aceita.

Minha ressalva à busca pelo menor preço é essa: o tempo de revisão também pertence à conta. Se economizamos créditos e transferimos a investigação para a pessoa que está tentando usar a ferramenta, precisamos reconhecer essa troca.

Eu compararia o consumo das tentativas, inclusive das descartadas, com o tempo humano gasto e os defeitos encontrados depois. Sem observar os três, é fácil premiar uma configuração que parece econômica no painel e custa caro na rotina.

Também não partiria da ideia de que o modelo mais caro sempre termina antes. Ele pode interpretar mal o pedido, explorar além do necessário ou produzir uma solução difícil de manter. Capacidade precisa se converter em progresso verificável para justificar o gasto.

A troca precisa ter um motivo e uma passagem clara

No VS Code, a troca acontece pelo seletor de modelo no Chat, abaixo da entrada. É possível mudar durante a conversa; isso não altera o modelo das sugestões de código inline. Se a opção desejada não aparecer, confira disponibilidade e políticas da organização.

O ponto mais delicado vem depois do clique. O guia de eficiência do GitHub explica que trocar de modelo invalida o cache anterior. Eu evitaria alternar a cada resposta. Preferiria a fronteira entre duas etapas, quando já existe algo consistente para entregar ao próximo modelo.

Pense em um bug investigado com Sol. Ao localizar a causa, a passagem para Terra poderia ser assim:

O erro ocorre quando o evento chega duas vezes. A segunda execução repete a gravação. O teste de reprodução está neste arquivo e falha antes da correção. Implemente a proteção no ponto indicado, preserve o contrato público e execute estes testes. Não amplie a refatoração.

O valor desse resumo está nos fatos que ele preserva. “Continue de onde paramos” deixa muita coisa implícita. Uma boa passagem leva a causa demonstrada, os arquivos relevantes, as tentativas descartadas e o critério de conclusão. Se ainda há hipóteses em aberto, elas precisam seguir identificadas como hipóteses.

Para uma mudança pequena, eu provavelmente manteria o modelo até terminar. Preparar e conferir uma passagem também consome tempo. A divisão só vale quando ajuda o trabalho.

O GitHub também orienta o uso de modelos mais baratos em subagentes com tarefas focadas. Quando esse recurso estiver disponível na experiência utilizada, pode ser uma forma de delegar trabalho delimitado sem trocar o modelo da sessão principal.

Quando o barato deixa de ser uma boa escolha?

O SWE-Router estudou a decisão de subir de capacidade depois de observar os primeiros passos do agente. Os experimentos usaram outros modelos e o mini-SWE-agent, com resultados que variaram entre conjuntos de teste. Eles apoiam observar a trajetória do trabalho, sem determinar qual versão atual do Copilot usar.

Essa é a parte que eu levaria para o cotidiano. Um erro acompanhado de uma hipótese nova pode ser progresso. A repetição do mesmo comando, a invenção de uma API ou alterações sem explicação são sinais para parar e reavaliar.

Como ponto de partida, eu aceitaria uma tentativa e uma correção orientada pelo erro antes de rever a abordagem. É uma política sugerida, que a equipe pode ajustar; a pesquisa não validou esse número. A revisão pode terminar em um pedido mais claro, um ambiente corrigido, outro modelo ou uma investigação humana.

O Auto ajuda, mas ainda precisamos julgar o resultado

O Auto oferece prioridades de eficiência, equilíbrio e inteligência. Eu consideraria Balance para uma rotina variada e seleção manual para comparar modelos em condições reproduzíveis. A prioridade escolhida orienta o roteamento, sem funcionar como teto de gasto.

Para acompanhar consumo Enterprise, o caminho é Copilot settings → Usage, conforme a documentação de monitoramento. Nem toda visão permite atribuir créditos a um prompt específico. Vale registrar essa limitação antes de anunciar uma economia precisa.

Em automações pela CLI, existe limite de créditos por sessão em prévia pública. Ele é flexível, com mínimo de 30 créditos, e uma resposta em andamento pode ultrapassá-lo. Use os controles de orçamento disponíveis quando precisar limitar consumo.

Para aprofundar o que acontece ao redor do modelo, os artigos sobre cache de prompts e harness engineering ajudam a conectar contexto, ferramentas e validação.

Eu começaria escolhendo uma tarefa recorrente do time e comparando duas configurações a partir do mesmo estado inicial, com o mesmo critério de aceitação. Repetiria o teste antes de transformar uma boa tentativa em regra. Minha pergunta ao final seria simples: qual escolha deixou menos trabalho pendente para a pessoa que precisava confiar na entrega?

Fontes originais em inglês, consultadas em 27/10/2026. Os estudos citados usam cenários e modelos próprios. As recomendações em primeira pessoa e os caminhos dos cards expressam julgamento editorial; não relatam testes práticos dos seis modelos realizados pela MnzAI Labs.