A GitHub considera que medir a eficiência de agentes de programação com base no número de tokens em uma única chamada pode levar a um resultado enganoso. Uma saída mais curta pode obrigar o modelo a executar novamente um comando ou solicitar informações excluídas, aumentando o número de rodadas, o tempo e o custo no nível da tarefa completa. Por isso, a empresa reavaliou as melhorias do GitHub Copilot com base no resultado final da tarefa, e não no tamanho da resposta de uma ferramenta individual.
Em uma publicação feita por Eric Christensen e Nabalés Klesius em 2 de setembro de 2026, a GitHub explicou quatro mudanças que, segundo a empresa, foram desenvolvidas por meio de testes offline usando benchmarks para avaliar tarefas de programação agentiva e depois validadas por experimentos controlados com usuários antes do lançamento. Vários produtos do Copilot, incluindo o aplicativo GitHub Copilot e a revisão de código, usam a mesma infraestrutura, enquanto os exemplos apresentados na publicação vieram do GitHub Copilot CLI.
Por que uma resposta mais curta não é suficiente?
A GitHub testou o impacto da ferramenta RTK, ou Rust Token Killer, que compacta as saídas do shell antes de apresentá-las ao agente. Nas configurações de teste utilizadas, a remoção de alguns textos importantes levou à reabertura das saídas originais ou à execução novamente dos comandos. Como resultado, o tamanho da resposta da ferramenta diminuiu localmente, mas a tarefa precisou, em média, de mais tokens e mais tempo.
A empresa ressalta que esse resultado se aplica à integração e às cargas de trabalho testadas, e não representa um julgamento sobre todas as configurações do RTK ou todos os métodos de compactação de saídas. A lição prática é que o critério de avaliação deve se estender do pedido do usuário até o resultado final, contabilizando rodadas de recuperação e retrabalho.
Compactação seletiva das saídas
A solução da GitHub foi compactar o ruído repetitivo, preservando as informações de que o agente precisa. Análises operacionais mostraram que as saídas de instalação, compilação, testes e operações de lint geralmente contêm muita repetição, enquanto as saídas semelhantes a código e os resultados de comandos arbitrários podem conter informações essenciais.
A versão lançada adotou uma política de três pontos:
- Manter inalteradas as saídas semelhantes a código e os resultados arbitrários, incluindo comandos como cat, git diff, git show e scripts arbitrários.
- Reorganizar resultados de pesquisa, como resultados de grep e listas de arquivos, sem excluir nenhum resultado.
- Compactar as saídas de instalação, compilação, testes e progresso apenas quando a economia for significativa.
O Copilot também manteve um caminho direto para recuperar a saída original completa. A GitHub continuou monitorando o uso desse caminho como mecanismo de segurança e indicador de que a compactação havia removido informações úteis. Nas tarefas offline em que a compactação foi ativada, a empresa não observou uma redução estatisticamente significativa no sucesso das tarefas, enquanto o experimento online reduziu ligeiramente o custo médio sem queda substancial nos indicadores de qualidade acompanhados.
Remoção de formatação desnecessária
A GitHub obteve uma das economias mais claras por meio da ferramenta view, que exibe o conteúdo dos arquivos para o modelo. A ferramenta adicionava um número de linha a cada linha, embora as ferramentas de edição atuais dependam da correspondência do código ao redor e não usem esses números no fluxo de trabalho habitual. Por isso, a empresa removeu esses prefixos das leituras de arquivos, mantendo os números de linha úteis em diferenças e trechos curtos.
A mudança reduziu o custo de inferência do modelo em cerca de 5% nos benchmarks offline de tarefas de programação agentiva, mantendo as taxas de sucesso dentro da variação esperada e sem aumentar os erros de edição. Em um experimento online com usuários do Copilot CLI, o custo médio diário de inferência por usuário caiu cerca de 3%, sem redução substancial nos indicadores de qualidade ou satisfação medidos pela GitHub.
Encurtamento das instruções sem alterar o comportamento
As instruções da ferramenta task foram se acumulando em descrições de ferramentas, esquemas, definições de agentes e instruções do sistema. A GitHub usou um ciclo para otimizar as instruções automaticamente, reduzindo o texto aproximadamente pela metade e, em seguida, testando os comportamentos que pretendia preservar.
Entretanto, o primeiro experimento online revelou um problema que não havia aparecido nas avaliações offline: orientações de paralelismo cuidadoso se transformaram em uma política rígida de agendamento, fazendo com que agentes independentes personalizados trabalhassem em sequência. A GitHub interrompeu o experimento, adicionou um teste de regressão para esse comportamento e substituiu a lista de permissões e proibições por uma única frase: “Agentes independentes podem trabalhar em paralelo; leve em consideração os efeitos colaterais”.
A formulação final reduziu cerca de 1300 tokens das instruções da ferramenta de tarefas em cada rodada, o equivalente a uma queda de aproximadamente 1,8% no total de tokens de instrução por sessão e de 2,9% no custo normalizado por hora de atividade, sem registrar redução de qualidade nas avaliações medidas.
Eliminação de rodadas desnecessárias de recuperação
Os agentes às vezes executam trabalhos independentes em segundo plano, como executar um comando shell longo em paralelo com uma investigação conduzida por um subagente. Antes, as notificações de conclusão desses trabalhos chegavam sem o próprio resultado, obrigando o agente a fazer uma chamada adicional para recuperar saídas que o Copilot já havia obtido. Agora, o sistema reúne as notificações de conclusão elegíveis e envia os resultados concluídos no formato existente de resultados de ferramentas.
No exemplo que combina um comando shell e um subagente, concluir o trabalho antes exigia quatro chamadas ao modelo: duas chamadas para solicitar os resultados e duas para processá-los. Depois da mudança, os dois resultados chegam juntos em uma única chamada para processamento. Isso reduziu em cerca de 2,3% o uso médio relacionado a tokens, conforme medido pelas unidades de AI Credits.
O que muda na prática?
A experiência da GitHub oferece uma regra importante para desenvolvedores de agentes de programação: a otimização mais segura não é excluir o máximo possível de texto, mas remover o trabalho de que o modelo não precisa. Isso inclui formatação não utilizada, rodadas de espera e recuperação que o sistema pode resolver e repetições que podem ser compactadas com a disponibilização de um caminho de recuperação.
Por outro lado, nem todo resultado pode ser generalizado para fora do ambiente de teste. Restringir as instruções das ferramentas de arquivos, apesar de ter funcionado na revisão de código, aumentou o custo em um experimento do Copilot CLI; por isso, a GitHub não lançou essa mudança. Da mesma forma, a compactação de git diff foi removida depois que os benchmarks mostraram que os agentes reabriam a saída original para recuperar as informações excluídas.
A conclusão demonstrada pelo material é a necessidade de medir a mudança no nível da tarefa, do fluxo de trabalho e do produto que a utilizará, por meio de benchmarks offline, experimentos online e testes comportamentais claros. O impacto dessas melhorias sobre um usuário específico continua relacionado ao tipo de tarefas, às ferramentas e às suas saídas, e não pode ser deduzido apenas de uma redução local no número de tokens.