Nem sempre precisa do modelo maior: um mês de Luna no modo Auto do Copilot

Já faz um tempo que uso o Copilot da empresa, no VS Code, com o seletor de modelo em Auto. E a minha impressão é que um modelo menor, o Luna, deu conta de muita coisa.

A tese que eu carrego é simples: nem sempre é preciso Sonnet/Opus. Nem toda tarefa pede o modelo mais caro da prateleira.

Só que impressão não é dado. Então analisei os logs locais das minhas sessões do Copilot, de 14 de agosto a 13 de setembro.

Adianto a parte desconfortável: não medi qualidade. A cada ponto, vou separar o que é número do que é impressão minha.

Sobre o modo Auto

O Copilot é o assistente de IA do GitHub dentro do editor. Nele, você escolhe num seletor qual modelo de linguagem vai responder. Há modelos leves e baratos, e modelos maiores e caros.

No modo Auto, você não escolhe. O Copilot escolhe por você.

Segundo a documentação oficial, são dois sistemas juntos: “One system tracks real-time system health and availability, while the other evaluates task complexity.”

Traduzindo: um olha a saúde e a disponibilidade dos modelos. O outro avalia a complexidade da tarefa.

O Luna é um dos modelos que o Auto pode escolher. O próprio catálogo do Copilot classifica o Luna como leve e de preço baixo.

Todas as sessões foram em modo agente, em que o Copilot lê arquivos, roda comandos e edita código. Foram 232 requisições, 190 delas em Auto e com resposta. Requisição, aqui, é cada mensagem que eu mando.

O que os dados confirmaram

1. O Luna sempre veio do Auto. Cada requisição guarda o modelo do seletor e, separado, o modelo que respondeu. O Luna respondeu 108 vezes, com o seletor em Auto em 108 de 108. No período, nunca escolhi o Luna à mão.
2. A gravação bate com o log da extensão. Onde deu para conferir, o modelo registrado coincidiu em 64 de 64 requisições.
3. O Luna foi a escolha mais comum do Auto. Das 190 respostas em Auto, 108 foram dele. Mais da metade.
4. O preço por token é bem menor. Token é o pedaço de texto que o modelo lê ou gera. A extensão guarda localmente o preço de tabela de cada modelo, por milhão de tokens.

Comparei o Luna com os modelos maiores que o Auto usou comigo e que têm preço nesse catálogo. No token de entrada, o Luna custa de um décimo (contra o mais barato deles) a um vinte e cinco avos (contra o mais caro). No token de saída, de cerca de um oitavo a cerca de um vigésimo.

A ressalva vem junto: é preço de tabela por token, não o custo de uma tarefa. Esse depende de quantos tokens a tarefa consome. E eu não sei quanto a empresa efetivamente paga.

Ainda assim, isso sugere que a cota da empresa rende mais quando o Auto cai no Luna. Sugere.

O que os dados não confirmaram

Por que o Auto escolheu o Luna. O próprio seletor descreve o critério assim: “Auto routes based on your task and real-time system health and model performance”.

Mas isso é o que a documentação diz. Os logs não registram o motivo de nenhuma escolha. E os sinais de saúde do sistema não ficam na minha máquina.

Preferência por tipo de tarefa. Nas revisões, o Auto foi para o Luna em 5 de 8 escolhas. Em planejamento de testes, em 0 de 3.

Parece padrão. Mas não dá para afirmar.

Com amostra desse tamanho, o teste estatístico não sustenta a diferença. E tem um agravante: as revisões que caíram no Luna aconteceram em dois dias seguidos.

Nos mesmos dias, outras revisões foram para modelos maiores. Como o Auto também pesa a saúde do sistema, não dá para separar o efeito da tarefa do efeito do dia.

Qualidade. Não existe campo de “deu certo” nos logs. Tenho só sinais indiretos: pedido de correção em seguida, troca manual de modelo, cancelamento e a leitura das respostas.

Esforço de raciocínio. Alguns modelos podem pensar mais ou menos antes de responder. Quanto o Auto usou com o Luna não é registrado.

Onde o Luna deu conta (pela leitura das respostas)

Dois casos ilustram bem, cada um em dois momentos. Todos são leitura das respostas, não verificação do código entregue.

1. Uma revisão de código completa. O Auto mandou o Luna revisar uma branch de automação de testes. Segundo a resposta, saíram 4 achados, 2 de severidade alta. Outros três, levantados pelo subagente revisor, foram descartados por não se sustentarem no código.
2. A correção dessa revisão. Na requisição seguinte, pedi a correção. O Luna corrigiu, adicionou testes de regressão, rodou as suítes e fez uma revisão final sem pendências.
3. Execução e diagnóstico de testes. Com a saída da suíte truncada, o Luna leu os relatórios XML em vez de rodar tudo de novo. Noutro dia, relatou 60 de 60 testes unitários aprovados.
4. Um teste pulado, bem explicado. Na mesma ocasião, explicou que um teste integrado foi pulado por falta de uma variável de ambiente, e que nada foi alterado. Não houve pedido de retrabalho na requisição seguinte.

É esse tipo de caso que alimenta a minha impressão. Mas continua sendo impressão.

Surpresa: a escolha é por sessão, não por mensagem

Dá para imaginar o Auto decidindo o modelo a cada mensagem. Não é o que acontece.

Das 30 sessões em Auto, 26 usaram um único modelo do começo ao fim. As 190 respostas vieram de só 38 decisões de roteamento. E 34 delas caíram em dois momentos:

1. 30 no início da sessão;
2. 4 logo após uma compactação, quando o Copilot resume as mensagens antigas para liberar contexto.

Das 4 restantes, 2 vieram logo depois de uma requisição cancelada. As outras 2 não têm gatilho visível.

Isso bate com um post do GitHub sobre roteamento. O Auto roteia “on the first turn, when there is no cache to lose, and after compaction, when Copilot summarizes older turns and the prompt prefix resets”.

A documentação dá o motivo: trocar de modelo no meio da sessão “has shown increased cost without ample improvements in quality.”

Nos meus dados, as 4 compactações feitas em Auto foram seguidas de troca de modelo. Todas.

Surpresa: o contexto é o mesmo, o preço é que muda

Uma explicação fácil para a economia seria o Luna receber prompts menores. Não é o caso.

A mediana de tokens de entrada por requisição ficou perto de 135 mil, tanto no Luna quanto num dos modelos maiores. Numa amostra, instruções de sistema e definições de ferramentas ocupavam 39% e 52% do prompt.

Ou seja: a economia vem do preço por token, não de prompts menores.

Surpresa: “Luna” no rótulo, modelo maior no trabalho

Esse é o mais traiçoeiro. O Copilot contabiliza o uso de cada requisição em créditos. E o agente pode disparar subagentes, cujos créditos entram na conta da requisição que os chamou.

Numa requisição registrada como Luna, mais de 95% dos créditos vieram de 25 subagentes registrados com outros modelos, entre eles modelos maiores. O Luna só orquestrou.

Não tenho log de runtime daquele dia para confirmar em qual modelo os subagentes rodaram de fato.

Por isso tomo cuidado com comparação em créditos. Mas tem uma que vale mostrar, porque é o mais perto de um experimento que consegui.

Numa mesma sessão longa, seguindo o mesmo plano de escrita de testes, o Auto passou de um modelo maior para o Luna depois de uma compactação.

Em passos equivalentes (“seguir para a próxima task”, com revisão por subagente), o modelo maior gastou de umas 15 a mais de 50 vezes mais créditos por requisição que o Luna.

As ressalvas dessa proporção:

1. A unidade dos créditos não está documentada nos arquivos.
2. Os créditos de cada requisição incluem os dos subagentes.
3. Os passos são equivalentes, não idênticos. Comparar custo entre modelos mistura o modelo com a tarefa e com o tamanho do contexto.

O contraponto: quando o Luna não bastou

Nem tudo foi tranquilo. E seria desonesto contar só os casos bons.

Numa sessão de design de automação de testes, o Luna respondeu 21 requisições. Nelas, repeti o mesmo requisito em quatro prompts, os dois últimos seguidos e já sem paciência.

O modelo continuava tratando como obrigatória uma etapa manual que eu já tinha descartado. Aí troquei o seletor à mão para um modelo maior.

Foi o único caso claro, no período, em que eu mesmo decidi que o Luna não estava bastando. Mas é sinal indireto, não prova de que o Luna falhou.

Não testei a mesma conversa num modelo maior desde o início. Não sei se ele teria entendido de primeira.

A fronteira ainda é nebulosa

Aqui o post vira pesquisa em aberto. Admito: não sei onde fica a linha entre “o menor basta” e “precisa do maior”.

Tenho pistas, não respostas. Uma sessão de brainstorming de arquitetura de testes foi para um dos modelos mais caros. As três sessões de planejamento de testes foram para modelos maiores.

E numa sessão, depois de 21 requisições no Luna e uma compactação, o Auto trocou sozinho para um modelo maior. A tarefa era tratar achados de revisão. Sem registro do motivo.

O GitHub conta que o roteador é treinado comparando respostas de um modelo menos capaz e de um mais capaz: “The router learns when the stronger model adds value.” É essa pergunta que eu quero responder por conta própria.

Antes de alguém sair citando esses números, os limites:

1. A amostra é pequena. São 38 decisões, agrupadas por sessão e concentradas em poucos dias. Nenhum padrão por tipo de tarefa se sustenta estatisticamente.
2. Qualidade não foi medida. Não há campo de sucesso, e não verifiquei o código das entregas.
3. O motivo de cada escolha não é registrado na versão atual da extensão.
4. O esforço de raciocínio do Luna em Auto também não.
5. Subagentes podem mascarar custo, e a unidade de créditos não é documentada.
6. A classificação por tipo de tarefa é manual, feita por uma pessoa só.
7. São só os dados locais desta máquina. Há períodos sem uso registrado, e sessões apagadas não existem nos arquivos.

Conclusão

A minha impressão continua de pé: o Luna deu conta de muita coisa. Os dados não conseguem provar nem desmentir isso, porque não medem qualidade.

O que eles mostram é mais modesto. O Luna só apareceu pelo Auto, custa bem menos por token, e 34 das 38 decisões de modelo do Auto caíram nos pontos que a documentação descreve.

No fim do dia, saio com mais perguntas do que respostas. E acho que é o começo certo para essa pesquisa.

E você, já deixou o modelo menor trabalhar sozinho, ou ainda escolhe o maior por garantia?