> ## Content Index > Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt > Use this file to discover other available public pages before exploring further. # Rodando um benchmark do RTK no GitHub Copilot CLI e no Claude Code CLI - URL: https://www.azurebrasil.cloud/blog/rodando-um-benchmark-do-rtk-no-github-copilot-cli-e-no-claude-code-cli/ - Published: 2026-08-19T12:27:38.000Z - Updated: 2026-08-19T12:27:38.000Z - Author: Talles Valiatti O [**RTK**,](https://github.com/rtk-ai/rtk?ref=azurebrasil.cloud) sigla para Rust Token Killer, é um proxy de linha de comando escrito em Rust que se posiciona entre o agente de código e o shell, reescrevendo comandos suportados para que a saída retorne comprimida antes de entrar no contexto do modelo. A promessa central é reduzir o volume de tokens gastos com output de terminal, e o próprio projeto expõe isso através do comando **rtk gain**, que mostra um percentual de economia sobre os comandos interceptados. Este artigo documenta, com bastante detalhe de metodologia, um benchmark que rodamos comparando o GitHub Copilot CLI e o Claude Code CLI, com e sem o RTK habilitado, para responder a uma pergunta específica, o percentual de gain que o RTK reporta se traduz na mesma proporção em economia de créditos ou dólares na fatura final do agente. Adiantamos o resultado, não se traduz, e o resto do texto explica por quê, com todos os números que coletamos. Vale um aviso logo de início, isto é um teste prático pequeno, feito em um único repositório, com uma amostra de vinte execuções, e dentro do meu MacBook Air. Não é um estudo estatístico e não deve ser lido como fonte da verdade sobre o RTK, é uma demonstração de um ponto conceitual específico, apoiada em dados reais. Antes de entrar nos números, vale entender como o RTK funciona por baixo do capô, porque isso explica boa parte do resultado. O [mecanismo de interceptação](https://github.com/rtk-ai/rtk?ref=azurebrasil.cloud#how-it-works?wt.mc%5Fid=MVP%5F407589) funciona através de um [**PreToolUse hook**,](https://github.com/rtk-ai/rtk?ref=azurebrasil.cloud) ([doc do GitHub Copilot](https://docs.github.com/en/copilot/how-tos/copilot-sdk/hooks/pre-tool-use?ref=azurebrasil.cloud)) que intercepta a chamada de ferramenta do agente antes da execução, reescreve o comando para sua versão **rtk,** executa esse comando reescrito e devolve ao modelo apenas a saída filtrada e compactada. O RTK não usa o tokenizer real de nenhum provider para estimar economia, ele calcula tokens estimados dividindo o número de bytes de saída por quatro, e "tokens economizados" é simplesmente a diferença entre a estimativa de tokens da saída bruta e da saída filtrada. Essa é uma limitação relevante, os números absolutos do [rtk gain](https://github.com/rtk-ai/rtk?ref=azurebrasil.cloud#token-savings-analytics?wt.mc%5Fid=MVP%5F407589) são aproximações, não uma contagem exata de tokens do provider. Um segundo ponto estrutural do RTK, e talvez o mais importante para entender o resultado deste benchmark, é que o hook de interceptação automática atua apenas sobre chamadas Bash. Ferramentas nativas do Claude Code, como Read, Grep e Glob, não passam automaticamente pelo hook, o agente precisaria usar comandos de shell equivalentes ou invocar explicitamente **rtk read**, **rtk grep** ou **rtk find** para que essas leituras fossem comprimidas. Isso significa que qualquer chamada nativa que não siga essa convenção fica totalmente invisível ao **rtk gain**, tanto no numerador quanto no denominador da conta. Para este benchmark, instalamos o RTK globalmente na máquina (*Mac OS*), o que cobre GitHub Copilot CLI, GitHub Copilot no VS Code, Claude Code CLI, Claude Code no VS Code. A instalação seguiu o caminho recomendado via Homebrew. ```bash brew install rtk-ai/tap/rtk rtk --version ``` Com o binário instalado, cada agente precisa de um comando de inicialização próprio, já que a integração é feita através de hooks e arquivos de instrução específicos de cada ferramenta. Para habilitar o RTK no GitHub Copilot CLI e no Copilot do VS Code globalmente, usamos o seguinte comando. ```bash rtk init --global --copilot ``` E, de forma equivalente, para habilitar no Claude Code CLI e na extensão do Claude Code no VS Code. ```bash rtk init --global ``` Ambos os comandos patcham as configurações do usuário, no caso do Claude Code o arquivo **\~/.claude/settings.json** recebe o hook de **PreToolUse,** e no caso do Copilot os arquivos ficam sob **\~/.copilot**. Depois de cada **rtk init**, rodamos **rtk init --show** para confirmar que a integração estava ativa antes de começar qualquer execução. Também vale registrar que o RTK guarda o histórico de economia em um banco SQLite local, em **\~/.local/share/rtk/history.db**. O ponto mais delicado da metodologia foi evitar que dados de consumo do Copilot se misturassem com dados do Claude no histórico interno do RTK, já que o **rtk gain** acumula tudo o que foi interceptado desde o último reset. Por isso o benchmark foi sequencial e não paralelo, em quatro fases. Na primeira fase, resetamos o histórico do RTK, habilitamos a integração apenas com o Copilot e rodamos toda a bateria de testes do Copilot, sem tocar no Claude Code em nenhum momento. Ao final, salvamos os resultados do rtk gain em arquivo antes de qualquer limpeza. ```bash rtk gain > copilot/rtk-gain.txt rtk gain --all > copilot/rtk-gain-all.txt ``` Na segunda fase, desinstalamos a integração do RTK com o Copilot e resetamos o histórico novamente, com **rtk gain --reset**, garantindo que a bateria do Claude começasse do zero. Na terceira fase, habilitamos a integração com o Claude Code e rodamos toda a bateria de testes equivalente, salvando os resultados da mesma forma. Na quarta e última fase, removemos a integração do RTK com o Claude Code e apagamos o histórico final. Esse cuidado de isolamento é o que nos permite comparar o **rtk gain** de cada agente sem risco de contaminação cruzada entre os dois conjuntos de dados. Fora a parte de instalação do RTK, o desenho do benchmark em si seguiu um conjunto fixo de parâmetros para os dois agentes. Usamos o mesmo repositório em todas as vinte execuções, um projeto de porte razoável, com **2.238 arquivos** e **246.092 linhas** classificadas como código. O modelo foi o mesmo nos dois agentes, [Claude Sonnet 5](https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5?wt.mc%5Fid=MVP%5F407589&ref=azurebrasil.cloud), com [reasoning effort](https://platform.claude.com/docs/en/build-with-claude/effort?wt.mc%5Fid=MVP%5F407589&ref=azurebrasil.cloud) configurado como medium, e ambos rodaram em modo autopilot, o modo autônomo em que o agente executa sem pedir confirmação a cada ação. Usamos exclusivamente a versão CLI de cada ferramenta, **copilot --autopilot --yolo** de um lado e **claude --dangerously-skip-permissions** do outro, referenciando a documentação de referência da [CLI do Claude Code](https://code.claude.com/docs/en/cli-reference?wt.mc%5Fid=MVP%5F407589&ref=azurebrasil.cloud) e a visão geral do **Github copilot CLI**. O escopo das perguntas foi restrito a cem por cento codebase, sem acesso a git explícito, sem internet e sem MCPs, para isolar o consumo de leitura e escrita de código puro. Entre cada execução rodamos **/clear**, para que o consumo de tokens fosse contabilizado separadamente por tarefa, e a qualidade do código gerado não foi validada em nenhum momento, o foco era exclusivamente consumo. Definimos dois tipos de tarefa, aplicados com o mesmo prompt literal nos dois agentes. A tarefa simples pedia ao agente que explicasse a arquitetura da solução, projetos, camadas e padrões utilizados, e gravasse o resultado em um arquivo markdown na raiz do repositório. A tarefa complexa pedia um CRUD completo de uma nova entidade, atravessando a camada de domínio, aplicação, web e frontend, incluindo um novo item no menu lateral e testes para as duas primeiras camadas, com instrução explícita para usar subagentes na implementação. Cada bateria, sem RTK e com RTK, rodou três execuções da tarefa simples e duas da tarefa complexa, por agente, totalizando vinte execuções no total. É uma amostra pequena, e tratamos os números como indicação de ordem de grandeza, não como prova estatística. No GitHub Copilot CLI, a métrica nativa de consumo é o [AI Credits](https://docs.github.com/en/copilot/concepts/billing/usage-based-billing-for-individuals?wt.mc%5Fid=MVP%5F407589&ref=azurebrasil.cloud), que converte o uso de tokens do modelo em créditos cobrados pelo GitHub, segundo a **tabela oficial de modelos e preços**. Registramos o valor de créditos ao final de cada uma das cinco execuções por bateria. - **Simples 2:** 39,2 (sem RTK) → 22,9 (com RTK) => variação **−41,6%** - **Simples 3:** 37,0 (sem RTK) → 36,7 (com RTK) => variação **−0,8%** - **Média simples:** 38,27 (sem RTK) → 32,03 (com RTK) => variação **−16,3%** - **Complexa 1:** 369 (sem RTK) → 339 (com RTK) => variação **−8,1%** - **Complexa 2:** 336 (sem RTK) → 354 (com RTK) => variação **+5,4%** - **Média complexa:** 352,5 (sem RTK) → 346,5 (com RTK) => variação **−1,7%** - **Total das 5 execuções:** 819,8 (sem RTK) → 789,1 (com RTK) => variação **−3,7%** O gain agregado de 3,7% esconde um detalhe importante, quase toda a redução observada nas tarefas simples veio de uma única execução, a segunda, que caiu para 22,9 créditos enquanto as outras duas ficaram na casa dos 36 a 37 créditos nas duas baterias. Excluindo esse ponto fora da curva das duas baterias, sem RTK e com RTK, a média das simples cai para 37,8 contra 36,6 créditos, uma redução de apenas 3,2%, já dentro da faixa de variação natural que observamos entre execuções idênticas do mesmo agente. No Claude Code CLI, acompanhamos o consumo através do **/usage**, [documentado na página de custos e uso](https://code.claude.com/docs/en/costs?wt.mc%5Fid=MVP%5F407589&ref=azurebrasil.cloud), que expõe tokens de input, output, cache read e cache write, além de um custo estimado em dólar. Um adendo importante sobre esse valor em dólar, ele é calculado localmente pelo próprio Claude Code, a preço de tabela padrão, sem refletir pricing promocional nem descontos contratados, e pode diferir do valor efetivamente cobrado. - **Simples 1:** não coletado (sem RTK) → $0,97 (com RTK) => variação **não calculável** - **Simples 2:** $0,57 (sem RTK) → $0,80 (com RTK) => variação **+40,4%** - **Simples 3:** $0,66 (sem RTK) → $0,53 (com RTK) => variação **−19,7%** - **Média simples:** $0,615 (sem RTK) → $0,767 (com RTK) => variação **+24,7%** - **Complexa 1:** $5,74 (sem RTK) → $7,42 (com RTK) => variação **+29,3%** - **Complexa 2:** $6,10 (sem RTK) → $6,20 (com RTK) => variação **+1,6%** - **Média complexa:** $5,92 (sem RTK) → $6,81 (com RTK) => variação **+15,0%** - **Ponderado (3 simples + 2 complexas):** $13,69 (sem RTK) → $15,92 (com RTK) => variação **+16,3%** A execução simples 1 sem RTK não foi registrada, então a média sem RTK das simples usa duas amostras contra três da bateria com RTK, uma limitação que carregamos conscientemente pelo resto da análise. Ainda assim, o padrão é claro, a média simples subiu 24,7%, a média complexa subiu 15,0%, e o total ponderado para o mesmo perfil de cinco execuções, três simples e duas complexas, foi de $13,69 para $15,92, um aumento de 16,3%. Acompanhamos também a soma bruta de tokens de cada execução, somando input, output, cache read e cache write reportados pelo **/usage**. - **Simples 1:** não coletado (sem RTK) → 656,3K (com RTK) => variação **não calculável** - **Simples 2:** 486,7K (sem RTK) → 764,8K (com RTK) => variação **+57,1%** - **Simples 3:** 495,0K (sem RTK) → 371,2K (com RTK) => variação **−25,0%** - **Média simples:** 490,9K (sem RTK) → 597,5K (com RTK) => variação **+21,7%** - **Complexa 1:** 11,80M (sem RTK) → 14,60M (com RTK) => variação **+23,7%** - **Complexa 2:** 12,41M (sem RTK) → 13,19M (com RTK) => variação **+6,3%** - **Média complexa:** 12,11M (sem RTK) → 13,89M (com RTK) => variação **+14,7%** O aumento de tokens acompanha o aumento de custo, 21,7% a mais nas simples e 14,8% a mais nas complexas, com RTK habilitado. Chegamos então ao paradoxo aparente que motivou este artigo, o próprio RTK reportou uma economia expressiva na saída de shell que interceptou, mas o custo final da bateria subiu. As duas capturas abaixo mostram exatamente o que o **rtk gain** reportou ao final de cada bateria com RTK habilitado. ![](https://storage.ghost.io/c/00/52/0052dced-0017-4d07-b190-1f5c48e0ab59/content/images/2026/08/claude.png) ![](https://storage.ghost.io/c/00/52/0052dced-0017-4d07-b190-1f5c48e0ab59/content/images/2026/08/copilot.png) Vale a pena olhar para dentro dessas capturas, porque a tabela por comando é o que explica a mecânica do resultado. No Copilot, **rtk read** respondeu por 81 chamadas e 35,1K tokens economizados, mas com apenas 6,0% de redução média por chamada, e **rtk grep** respondeu por 69 chamadas e 5,4K tokens economizados, com 30,2% de redução média. Já comandos estruturais, de baixíssimo volume, tiveram reduções percentuais muito mais altas, **rtk dotnet build** teve uma única execução com 96,7% de redução, e diferentes variações de **rtk ls -la** ficaram entre 50,8% e 76,4% de redução, cada uma aparecendo uma ou duas vezes apenas. No Claude, o padrão se repete, **rtk read** teve 41 chamadas somando 36,7K tokens economizados a apenas 5,8% de redução média, **rtk grep** teve 77 chamadas somando 2,6K tokens a 28,7% de redução média, e **rtk find** apareceu 31 vezes com apenas 6,2% de redução média. Comandos estruturais como **rtk ls -la src/Client...** chegaram a 87,4% de redução, mas de novo em volume baixíssimo, duas chamadas apenas. É exatamente o padrão que o mecanismo de interceptação por Bash sugere, comandos de alto volume como leitura e busca de arquivo têm pouca gordura para cortar proporcionalmente, enquanto comandos raros de saída muito verbosa, como um build, têm muito mais espaço de compressão. Com todos os números coletados, vale explicar exatamente como cada cálculo foi feito, para que qualquer pessoa possa reproduzir ou auditar as contas. A variação percentual em todas as tabelas segue a fórmula padrão de diferença relativa. ```text Δ% = (média_sem_RTK − média_com_RTK) / média_sem_RTK × 100 ``` A soma de tokens por execução no Claude Code é simplesmente a soma dos quatro contadores que o **/usage** expõe. ```text total = input + output + cache_read + cache_write ``` E o total ponderado de custo, usado para comparar as duas baterias no mesmo perfil de cinco execuções, pondera a média de cada categoria pelo número de execuções daquele tipo no desenho original do benchmark. ```text total = 3 × média_simples + 2 × média_complexa sem RTK: 3 × 0,615 + 2 × 5,92 = $13,69 com RTK: 3 × 0,767 + 2 × 6,81 = $15,92 ``` Um ponto que exigiu atenção redobrada foi a base de preço usada nas conversões da análise seguinte. O **/usage** do Claude Code e o conversor de AI Credits do GitHub usam bases de preço diferentes, então usamos cada tabela na comparação que lhe corresponde, para não misturar maçãs com laranjas. A tabela do GitHub, confirmada na documentação oficial de modelos e preços, reflete o pricing promocional do Sonnet 5 vigente até 31 de agosto de 2026, e foi usada em todos os cálculos envolvendo Copilot. - **Input:** US$ 2,00 / MTok → **200 AI Credits** - **Cached input (cache read):** US$ 0,20 / MTok → **20 AI Credits** - **Cache write (5 min):** US$ 2,50 / MTok → **250 AI Credits** - **Output:** US$ 10,00 / MTok → **1.000 AI Credits** > Considerando **1 AI Credit = US$ 0,01**. Já para o Claude Code, como o próprio **/usage** calcula a preço de tabela padrão, sem desconto promocional, usamos a tabela standard list rate do Sonnet 5, com os multiplicadores usuais de cache aplicados sobre o preço de input, dez por cento para cache read e um a dois multiplicadores para cache write dependendo do TTL, conforme documentado na [**página oficial de pricing**](https://platform.claude.com/docs/en/pricing?wt.mc%5Fid=MVP%5F407589&ref=azurebrasil.cloud). - **Input:** US$ 3,00 / MTok - **Cached input (cache read):** US$ 0,30 / MTok - **Cache write (5 min):** US$ 3,75 / MTok - **Cache write (1h):** US$ 6,00 / MTok - **Output:** US$ 15,00 / MTok Com as duas bases de preço definidas, chegamos ao núcleo da análise, por que a economia que o RTK reportou não apareceu na conta final. A primeira explicação é que o **rtk gain** e o custo da sessão medem coisas fundamentalmente diferentes. O **rtk gain** mede a razão entre tokens removidos e tokens brutos de saída de shell, enquanto o custo da sessão soma tudo o que o agente consumiu, prompt, system instructions, histórico de conversa reenviado a cada turno, chamadas de ferramenta, cache read, cache write e o output do próprio modelo. O RTK só toca o numerador da primeira conta, e o que ele toca é uma fração pequena do segundo. A própria [documentação sobre como o savings é calculado](https://github.com/rtk-ai/rtk/blob/develop/docs/guide/resources/savings-explained.md?wt.mc%5Fid=MVP%5F407589&ref=azurebrasil.cloud) já deixa isso explícito, uma redução de 90% na saída de um comando não implica sessão 90% mais barata. Para dimensionar essa fração, somamos os contadores de tokens de toda a bateria com RTK do Claude Code, input, output, cache read e cache write das cinco execuções. - **Simples:** 656,3K + 764,8K + 371,2K = **1,79M** - **Complexas:** 14,60M + 13,19M = **27,79M** - **Total:** **29,58M** O **rtk gain** registrou 44,8K tokens economizados na mesma bateria. Contra esse total, a conta fica em torno de 0,15%. ```text 44,8K / 29,58M ≈ 0,15% ``` Vale um cuidado aqui com o denominador, porque é fácil errar essa conta comparando os 44,8K contra uma única tarefa complexa, que sozinha já soma cerca de 12 milhões de tokens. Fazer essa comparação daria algo perto de 0,4%, superestimando o efeito em quase três vezes. O denominador correto é a bateria inteira, já que os 44,8K são o acumulado dos 213 comandos das cinco execuções, não de uma execução isolada. Vale lembrar também que essa soma não é literalmente um tamanho de contexto, o cache read conta o mesmo histórico sendo reprocessado a cada novo request, já que o Claude Code reenvia a conversa inteira a cada turno, conforme explica a documentação de [prompt caching](https://code.claude.com/docs/en/prompt-caching?wt.mc%5Fid=MVP%5F407589&ref=azurebrasil.cloud). Então o total de 29,58 milhões reflete reprocessamento acumulado ao longo da sessão, não uma janela de contexto única. O RTK fez o trabalho dele dentro do domínio que consegue controlar, e o comportamento não determinístico do agente variou mais do que a economia produzida nesse domínio. O aumento observado é compatível com variação normal do comportamento agêntico, mais turnos, mais leituras, mais chamadas de ferramenta, uso diferente de subagentes entre uma execução e outra, mas o benchmark atual não permite identificar qual desses fatores efetivamente causou a diferença, nem se o RTK teve qualquer participação causal nela. Com apenas duas ou três execuções por célula, não conseguimos separar estatisticamente "o RTK causou um comportamento diferente do agente" de "o agente simplesmente teve uma trajetória diferente por acaso". A própria amostra evidencia o tamanho desse ruído de forma direta, nas duas execuções complexas sem RTK do Copilot, tivemos 369 e 336 créditos, uma diferença de quase 9% entre duas rodadas idênticas, sem mudar absolutamente nada na configuração. Existe uma corroboração externa interessante para esse padrão, embora ela não prove causalidade no nosso experimento específico. Há uma issue fechada no [próprio repositório do RTK](https://github.com/rtk-ai/rtk/issues/582?wt.mc%5Fid=MVP%5F407589&ref=azurebrasil.cloud) relatando um efeito parecido, um aumento de 18% no custo do Claude Code depois de habilitar o RTK, usando a versão 0.29.0 e o modelo Sonnet 4.5, com os tokens de output subindo 50%. A hipótese levantada nessa issue é que o modelo, ao receber um output compactado e abreviado, compensa gerando mais tokens de saída para interpretar a informação condensada. É um mecanismo plausível e já documentado de forma independente por outro usuário, mas o nosso benchmark não instrumentou volume de turns ou de output por execução, então não podemos confirmar que foi exatamente isso que aconteceu na nossa bateria. Reunindo tudo, dá para separar com clareza o que os dados sustentam do que eles não sustentam. Os dados sustentam que o RTK funcionou tecnicamente, comprimindo entre 42% e 55% da saída de terminal que conseguiu interceptar nos dois agentes, e sustentam que, neste workload específico, saída de terminal representa uma parcela muito pequena do custo total dos agentes, algo em torno de 0,15% dos tokens da bateria do Claude. Sustentam também que uma redução local grande pode virar uma redução global pequena, facilmente encoberta pela variabilidade natural de execuções agênticas, e que, para este repositório e este perfil de tarefas, não houve evidência de redução de custo relevante acima do ruído experimental. O **rtk gain** deve ser interpretado como eficiência de compressão de terminal, não como economia de AI Credits ou de dólares. Por outro lado, os dados não sustentam a afirmação de que o RTK não funciona, ele fez exatamente o que promete dentro do escopo em que atua. Também não sustentam a leitura de que o RTK economiza de 40% a 55% no Copilot ou no Claude, essa é a métrica de compressão de shell, não de fatura. E não sustentam a afirmação de que o RTK aumenta o custo do Claude em 16,3%, esse aumento está dentro da faixa de ruído observada entre execuções e não foi atribuído causalmente ao RTK em nenhum momento da análise, ainda que exista um relato externo de efeito parecido. Também não é correto tratar o $15,92 como o que a bateria custou de fato, é um valor calculado localmente pelo Claude Code a preço de tabela padrão, e para assinantes Pro ou Max o uso já está incluso no plano, então nem chega a representar uma cobrança real. Por fim, listamos as limitações que consideramos importantes para qualquer pessoa que queira usar este benchmark como referência. A amostra total foi de vinte execuções, com apenas duas ou três amostras por célula, um **N** insuficiente para separar sinal de ruído com confiança estatística, e a variância entre execuções idênticas que observamos, como o caso dos 369 contra 336 créditos, é comparável em magnitude aos próprios efeitos que estávamos tentando medir. As métricas dos dois agentes não são diretamente comparáveis entre si, créditos de um lado e dólares do outro, e não instrumentamos o comportamento de cache durante as execuções, o que significa que as faixas de sensibilidade que calculamos dependem de um valor de **N** desconhecido e são estimativas com premissas explícitas, não medições diretas. Nenhuma diferença observada foi atribuída causalmente ao RTK em nenhum ponto deste artigo, os deltas medidos estão dentro da faixa de variação natural que já existe entre execuções agênticas idênticas, e a qualidade e a corretude do código gerado não foram avaliadas em momento algum, é inteiramente possível que o RTK afete a qualidade do código em qualquer direção sem que isso apareça nesses números. Usamos um único repositório, uma única stack e um único modelo. Este benchmark serve para dar uma ideia inicial de ordem de grandeza, não para embasar uma decisão de rollout em produção. Para uma conclusão mais firme seriam necessárias muito mais execuções por célula, instrumentação do comportamento de cache e, principalmente, um perfil de tarefa que inclua comandos de saída realmente verbosa, como builds longos, suítes de teste completas, logs de container ou diffs grandes de git, cenário em que a fatia controlável pelo RTK provavelmente é bem maior do que a que vimos aqui, navegando código e implementando features. Fica como sugestão para um próximo artigo! Até a próxima, abraços!