No blog de engenharia de 2 de setembro, o GitHub divulgou uma lista de reduções de custo para o agente de código do Copilot, assinada por Erik Kristensen e Napalys Klicius. Quatro mudanças, cada uma economizando 5,5%, 3,1%, 2,9% e 2,3% do custo de inferência, todas atuando sobre o contexto enviado ao modelo, nenhuma dependendo da troca de modelo.
Quatro mudanças, cada uma com alguns pontos percentuais
Em primeiro lugar está a compressão seletiva de saídas, que economiza 5,5%. As regras são bem definidas: o código-fonte permanece intacto, a saída dos comandos permanece intacta, os resultados de busca só são reordenados, sem cortar conteúdo; o que é comprimido são apenas os milhares de linhas de ruído repetitivo nos logs de instalação, build e teste. A parte comprimida mantém um caminho de recuperação, permitindo que o modelo resgate a saída original quando necessário.
A segunda mudança remove o prefixo de número de linha na leitura de arquivos, economizando 3,1%. Nas primeiras versões, o Copilot adicionava o número da linha no início de cada linha ao ler um arquivo, formato que o fluxo de edição atual não utiliza mais. Depois da remoção, o custo de inferência do modelo caiu cerca de 5% nos benchmarks, o que equivale a 3,1% na fatura total — os dois números usam bases de cálculo diferentes.
A terceira mudança atua no prompt da ferramenta task. A equipe usou meta-prompting para cortar pela metade o trecho que orienta a execução paralela, mantendo o comportamento inalterado, economizando 2,9%. Esse trecho de prompt é reenviado a cada interação com o modelo; após a compressão, cada rodada economiza cerca de 1.300 tokens.
A quarta mudança reduz idas e vindas de notificações, economizando 2,3%. Antes, depois que uma tarefa em segundo plano terminava, era preciso uma rodada extra de recuperação para levar o resultado até o modelo; com o envio direto em lote, o que se economiza é uma chamada inteira ao modelo.
Economizar tokens não é o mesmo que cortar contexto
A frase mais fácil de interpretar mal nessa lista é a definição do objetivo que eles dão:
"The goal shouldn't be to use fewer tokens, but to tap into the right amount of context to move a task forward."
O objetivo não deveria ser usar menos tokens, e sim acessar a quantidade certa de contexto para fazer a tarefa avançar.
O ponto em comum das quatro mudanças é cortar apenas o que o modelo lê mas não usa: logs de build repetidos, números de linha que ninguém consome, instruções longas reenviadas a cada rodada, rodadas de recuperação extras. As partes que carregam informação de fato — código-fonte, saída de comandos, resultados de busca — não são tocadas. A linha entre “redundância” e “falta de contexto” é o que torna essa abordagem viável: cortar demais tem como custo a queda na taxa de conclusão das tarefas, uma conta bem mais cara do que os tokens economizados.
Primeiro benchmark offline, depois comparação online
O trecho sobre o processo é ainda mais revelador do que os números. Cada mudança foi validada primeiro em um benchmark offline de agentes de código para garantir que a qualidade da tarefa não caísse, depois passou por um experimento online controlado para comparação, e só então foi implantada nas três linhas de produto: Copilot CLI, aplicativo Copilot e revisão de código.
Essa ordem existe para evitar o erro mais comum na redução de custos: o uso de tokens cai, a taxa de conclusão das tarefas cai discretamente alguns pontos, a fatura de cada chamada fica mais bonita, mas os usuários passam a tentar de novo repetidamente, e o custo total acaba sendo maior. Colocar “a qualidade da tarefa não pode cair” como restrição rígida logo no início é o que sustenta os percentuais que vêm depois.
Somadas, as quatro mudanças chegam a cerca de 13,8%, uma soma direta e aproximada, que na prática pode ter sobreposições. Comparado a trocar de modelo, esse patamar não é grande — uma mudança de geração de modelo costuma trazer quedas de preço de dezenas de pontos percentuais. Mas esse tipo de mudança tem uma natureza diferente: não depende do modelo escolhido, continua válida depois de uma troca de geração e não exige que o usuário mude nada no seu uso.
Para usuários do Copilot na cobrança por uso, a economia do lado da plataforma cai direto na fatura. Uma única execução de um agente de código facilmente consome centenas de milhares de tokens, e a proporção de logs de build e saídas de teste costuma superar a soma de todo o código-fonte lido — por isso a primeira mudança sozinha consegue economizar 5,5% de uma vez. Para equipes que constroem seus próprios agentes de código internamente, esse também costuma ser o custo mais fácil de passar despercebido. A maioria dos frameworks, por padrão, joga toda a saída padrão (stdout) de volta para o contexto — a saída de um único npm install já pode ocupar o espaço de milhares de linhas de código-fonte útil.
A julgar por essa lista, o controle de custos dos agentes de código já desceu para a camada de gerenciamento de contexto, tornando-se basicamente independente da escolha do modelo.
Fontes: blog oficial de engenharia do GitHub, CocoLoop, documentação de produto do Copilot; os percentuais das quatro mudanças, a economia de tokens por rodada e o processo de validação foram conferidos item a item conforme o texto original do blog, e o total de 13,8% é uma soma direta e aproximada.