Trocar o modelo do GitHub Copilot pode economizar créditos. Também pode transformar uma correção simples em uma sequência de tentativas, releituras e revisão manual. O critério útil para um time é quanto custa chegar a um resultado correto, incluindo o esforço humano.

Luna e Haiku são candidatos para trabalho delimitado e verificável. Terra 6.1 e Sonnet podem assumir execução com mais dependências. Sol e Opus merecem espaço quando há diagnóstico difícil, decisões de arquitetura ou consequências relevantes. Essa é uma orientação de trabalho que precisa ser calibrada no repositório da equipe, não um ranking comprovado para qualquer tarefa.

Referência verificada em 27/10/2026. Usamos as versões GPT-6 Luna, GPT-6.1 Terra, GPT-6.1 Sol e Claude Haiku, Sonnet e Opus 5.5. O catálogo disponível depende do cliente, plano e políticas da empresa. O laboratório acima usa essas versões; preços e modelos devem ser reconferidos antes de uma decisão de orçamento.

O que a evidência permite afirmar

Não encontramos, nas fontes consultadas, um teste público controlado que compare esses seis modelos dentro do mesmo Copilot, com o mesmo contexto, ferramentas, esforço de raciocínio e tarefas de código, testes, automação e documentos. A evidência disponível combina pesquisas sobre agentes, avaliações dos fornecedores e orientações operacionais do GitHub.

Há sinais concretos para orientar uma escolha:

  • Luna e Haiku: o comparativo do GitHub os posiciona para tarefas rápidas e pequenas. Isso apoia um ponto de partida econômico, sem provar equivalência em investigação extensa.
  • Haiku e Sonnet: a Anthropic reporta 39,2% e 70,6%, respectivamente, no Terminal-Bench 4.0. É avaliação divulgada pelo fornecedor, com detalhes no system card; não é um teste da sua instalação do Copilot.
  • Terra: a OpenAI informa 50,3% no Terminal-Bench 4.0 com raciocínio máximo. O próprio lançamento mantém Sol como opção para programação mais complexa. Esses números de fornecedores distintos não formam um placar controlado entre modelos.
  • Sol: os resultados publicados pela OpenAI incluem DeepSWE 1.1, para engenharia em bases reais, e AutomationBench 1.0.6, para fluxos com ferramentas. São indícios relevantes para investigação e automação, sujeitos às condições de cada avaliação.
  • Sonnet e Opus: a Anthropic descreve Sonnet como opção para trabalho cotidiano e documentos, e Opus para problemas abertos que exigem julgamento sustentado. Um resultado forte em uma prova não torna a variante mais cara necessária para toda edição.

A ferramenta ao redor do modelo também importa. O estudo SWE-Bench Mobile, com 22 configurações de agentes e modelos em uma base iOS, observou diferenças de até seis vezes para o mesmo modelo em agentes distintos. É um recorte específico de desenvolvimento mobile, com configurações anteriores; ilustra por que um resultado de outro agente não deve ser tratado como previsão do Copilot.

Créditos, tokens e tentativas: três coisas diferentes

No Business e no Enterprise, o GitHub cobra o uso de IA por tokens convertidos em créditos: 1 crédito equivale a US$ 0,01. As franquias se agrupam na entidade de cobrança. Completar código e receber sugestões de próxima edição continua fora dessa cobrança de créditos nos planos pagos.

Compare versões exatas: “Haiku” e “Luna” são famílias. O preço de uma geração anterior pode ser diferente do exibido neste guia.

A calculadora usa a tabela do próprio Copilot, não preços de assinatura de aplicativos externos. Ela separa entrada sem cache, leitura, gravação de cache e saída faturável. Contexto longo pode mudar a tarifa, inclusive a partir de limiares diferentes entre modelos.

No exemplo inicial, uma requisição hipotética com 20 mil tokens de entrada sem cache e 4 mil de saída custa US$ 0,004 no Luna ou Haiku, US$ 0,04 no Terra, US$ 0,08 no Sol ou Sonnet e US$ 0,16 no Opus. Os volumes iguais servem só para entender a aritmética: modelos podem produzir quantidades diferentes de tokens.

Vinte requisições desse tamanho em Luna somariam o preço de uma no Sol. Isso não significa que Sol sempre resolve em uma tentativa ou que Luna precisa de vinte. Ajuste as repetições e observe o ponto em que a vantagem de preço desaparece. Depois acrescente à discussão o tempo de revisão, o retrabalho e o impacto de um erro.

Como trocar sem desperdiçar o que já foi feito

No VS Code, abra o Chat e use o seletor de modelo abaixo da entrada. A documentação oficial permite trocar durante a conversa e esclarece que isso não altera o modelo das sugestões inline. Se uma opção não aparecer, confira cliente, plano e políticas, em vez de presumir uma falha da conta.

A troca faz sentido quando muda a necessidade da tarefa. Por exemplo: terminar um diagnóstico com Sol e entregar ao Haiku uma alteração mecânica, com arquivos e critérios definidos. Mudar repetidamente apenas para experimentar nomes pode gerar custo adicional e dificultar a comparação.

O guia de eficiência do GitHub explica que a troca de modelo invalida o cache anterior. Prefira transições entre etapas e um contexto enxuto. Um resumo de passagem útil contém:

  1. Objetivo e comportamento esperado.
  2. Arquivos relevantes e fatos confirmados, separados de hipóteses.
  3. Testes executados, comandos e falhas ainda presentes.
  4. Restrições da mudança e condição de conclusão.

Em uma tarefa contínua, manter o modelo pode preservar valor do cache. Ao mudar de problema, uma nova conversa evita carregar histórico irrelevante. A passagem precisa preservar também evidências que contrariem a hipótese inicial; um resumo otimista pode esconder a causa do defeito.

E o Auto?

O Auto com otimização por tarefa oferece Efficiency, Balance e Intelligence. Essas prioridades orientam o roteamento; não fixam um modelo nem um gasto máximo. Nos planos pagos, a documentação informa desconto de 10% no custo dos modelos nas experiências elegíveis.

Para uma rotina variada, Auto/Balance é uma alternativa a avaliar. Para comparar modelos com repetibilidade, selecione-os manualmente e registre versão e configuração. Se o objetivo for um teto de gasto, use os controles de orçamento: o nome Efficiency, sozinho, não faz esse papel.

Onde começar barato e onde subir de capacidade

As escolhas abaixo são recomendações editoriais para um piloto. O requisito, o risco e a capacidade de verificar o resultado pesam mais que a quantidade de linhas.

Código localizado. Ajustar uma mensagem, gerar um adaptador com contrato conhecido ou aplicar uma transformação mecânica são bons candidatos para Luna/Haiku. Confira o diff e execute o teste associado. Se a mudança exigir compreender efeitos entre serviços, experimente Terra/Sonnet; para uma causa ainda desconhecida, considere Sol/Opus no diagnóstico.

Geração de testes. Fixtures e casos repetitivos podem começar leves. Já definir o comportamento esperado, cobrir concorrência ou autorização e descobrir uma regressão exige análise. Não deixe o agente “corrigir” o teste apenas para aceitar a implementação. Verifique se um defeito introduzido deliberadamente faz o teste falhar.

O TestGenEval, publicado no ICLR 2025, avaliou geração e complementação de testes em 11 repositórios Python. Encontrou dificuldades com cobertura e asserções em caminhos complexos. Ele não compara as versões atuais deste guia; sustenta a necessidade de avaliar a qualidade dos testes separadamente da geração de código.

Automações. Um script de leitura e transformação com esquema estável pode começar em Luna/Haiku. Fluxos com várias ferramentas, falhas parciais, retentativas ou estado compartilhado justificam testar Terra/Sonnet ou Sol. Se houver exclusão, pagamento, credencial ou dado de produção, comece pelo desenho de permissões, simulação, idempotência e recuperação. Um modelo mais capaz não é uma autorização para executar.

Documentos. Resumir um diff ou atualizar instruções com fatos fornecidos pode ser leve. Conciliar fontes, escrever uma decisão de arquitetura ou elaborar um runbook exige verificar contradições, restrições e comandos. Terra/Sonnet são candidatos intermediários; Sol/Opus podem ajudar na análise aberta. Aparência profissional e texto fluente não validam o conteúdo. Reabra os arquivos gerados e teste exemplos.

Refatoração e arquitetura. Separe investigar, planejar, implementar e revisar. Use capacidade maior onde há incerteza e entregue partes delimitadas a modelos mais econômicos. Evite impor essa divisão quando a tarefa for tão pequena que o custo de preparar a passagem supere o trabalho.

Quando parar de insistir no barato

O estudo SWE-Router, apresentado em workshop do ICML 2026, encontrou vantagens em observar os primeiros passos de um agente antes de decidir uma escalada. Os experimentos usaram mini-SWE-agent com GPT-5-mini ou DeepSeek-V3.2 e Gemini-3-Pro-Preview, não as seis versões deste guia. Houve também variação entre conjuntos de teste.

A lição transferível é observar progresso. Se o agente repete o mesmo comando, altera arquivos sem hipótese verificável, inventa uma API ou não explica uma falha, interrompa e revise o contexto. Depois escolha entre esclarecer o requisito, corrigir o ambiente, subir de capacidade ou assumir a investigação manualmente. Uma dependência indisponível não se resolve necessariamente com outro modelo.

Como regra inicial de equipe, pode-se permitir uma tentativa e uma correção orientada pelo erro antes de reavaliar. Esse limite é uma política sugerida, não um número validado pela pesquisa. Ajuste-o com os dados do seu trabalho.

Como transformar o guia em uma prática do time

Monte um conjunto pequeno de tarefas representativas: correções, testes, automações e documentos. Guarde uma cópia inicial reproduzível e compare configurações no mesmo estado, sem entregar a solução de uma execução à seguinte. Repita as avaliações para não confundir uma boa tentativa com consistência.

Registre modelo e esforço, cliente do Copilot, resultado dos critérios de aceitação, consumo disponível, duração, revisão humana e defeitos encontrados depois. Defina os critérios antes de ver qual modelo venceu. Um teste aprovado com uma regra de negócio errada deve contar como falha.

Acompanhe duas medidas separadas: custo de IA por entrega aceita e tempo humano total por entrega aceita. Inclua o consumo das tentativas descartadas. Não transforme número de prompts, tokens ou linhas geradas em produtividade.

Usuários Enterprise podem conferir consumo em Copilot settings → Usage. A documentação de monitoramento diferencia essa visão da página de cobrança para planos individuais. Nem toda visão permite atribuir consumo a um prompt específico; registre os limites da medição.

Para automações via CLI, há limite de créditos por sessão em prévia pública, com mínimo de 30 créditos. O comando interativo é /limits set max-ai-credits NUMBER; em execução programática, use --max-ai-credits NUMBER. É um limite flexível: uma resposta em andamento pode ultrapassá-lo. Combine-o com orçamento mensal e políticas administrativas.

Para aprofundar contexto e validação, veja cache de prompts e harness engineering.

Se você usa Copilot todos os dias, escolha uma tarefa recorrente para começar essa comparação. A meta é descobrir qual configuração entrega o trabalho com menos custo e revisão, e reconhecer cedo quando o problema pede mais capacidade.

Fontes e documentação originais em inglês, consultadas em 27/10/2026. Benchmarks citados são resultados de seus autores ou fornecedores; a MnzAI Labs não executou um comparativo controlado dos seis modelos. Exemplos, seletor e limites operacionais são orientações editoriais, com hipóteses explícitas.