Contribuição open source · Rust · CLI · LLM Token Reduction
rtk-ai/
Proxy de linha de comando em Rust que reduz o consumo de tokens de IA em 60% a 90% interceptando comandos comuns de desenvolvimento sem dependências externas.
- 2 PRs aceitos
- 7 PRs em revisão
- 35 commits no projeto
- +980 linhas adicionadas
- 86,5k estrelas no GitHub
O projeto
O RTK é uma ferramenta de linha de comando em Rust, ultrarrápida e sem dependências em runtime, projetada para reduzir drasticamente o consumo de tokens de IA (entre 60% e 90%) em comandos comuns de desenvolvimento.
Ele atua como um proxy transparente entre desenvolvedores ou agentes de programação e comandos como git, cargo, npm, pytest e linters, filtrando e compactando saídas volumosas sem perder o contexto relevante para os modelos de IA.
Como cada PR foi feito
-
Um problema por PR
Cada PR resolve uma coisa só, com a menor mudança possível. Isso simplifica a revisão, reduz o risco de efeito colateral e permite desfazer uma mudança sem levar outras junto.
-
O problema vira teste
As correções chegam com testes automatizados que cobrem o caso que falhava, para o problema não voltar sem que ninguém perceba.
-
Os critérios do próprio projeto
Formatação, análise estática e a suíte completa de testes rodam na integração contínua do projeto, e a mudança só entra depois da revisão do mantenedor.
-
Escrito para quem revisa
A descrição de cada PR explica o problema, a mudança e como ela foi testada, para o mantenedor decidir com segurança.
Cada PR, em linguagem de negócio
Clique em um PR para ver o problema, o que foi feito e o valor entregue. O link no fim de cada um leva à discussão técnica completa no GitHub.
-
#4771mergeado em 01/11/2026 Relatório econômico mensal soma custos de todos os projetos de IA Relatórios mensais sobrescreviam dados e mostravam apenas o último projeto; o PR propõe somar tokens e gastos de todos os projetos do mês.
- O problema
- Ao analisar a economia e os custos de consumo de modelos de inteligência artificial agrupados por projeto no relatório mensal, a ferramenta recebia múltiplos registros correspondentes ao mesmo mês. Em vez de somar os valores, o processamento sobrescrevia a entrada do período com cada novo projeto lido, mantendo no relatório final apenas os dados do último item. Com isso, os demonstrativos mensais e os totais consolidados subnotificavam drasticamente os custos e o volume real de tokens consumidos.
- O que foi feito
- O PR propõe estender a rotina de agregação por períodos para incluir também a visualização mensal, somando tokens de entrada, saída, caches e custos financeiros de todos os projetos em um único registro por mês. Novos testes automatizados com simulação de múltiplos projetos garantem que os relatórios detalhados e os resumos executivos reflitam a soma exata de todos os recursos utilizados.
- Valor entregue
- Garante visibilidade financeira precisa dos gastos reais com IA por mês para gestores e times de engenharia.
-
#4802aberto em 26/10/2026Em revisão Resumo do pytest não transforma em falha uma faixa impressa pelo próprio teste Uma linha de sublinhados que um teste imprimia na saída capturada era lida como o cabeçalho da próxima falha, virando uma falha a mais no resumo; agora só o separador do pytest encerra uma seção capturada.
- O problema
- O rtk resume a saída do pytest para reduzir tokens, e para isso identifica os blocos de falha por cabeçalhos com sublinhados. Um teste que imprime uma faixa decorativa, com um título entre sublinhados, tem essa linha reproduzida na seção de saída capturada da falha. O analisador tomava a linha pelo cabeçalho de uma nova falha: a faixa virava uma entrada própria no resumo, e as linhas capturadas seguintes, inclusive linhas de erro impressas pelo teste, eram atribuídas a ela.
- O que o PR propõe
- O analisador passou a saber quando está dentro de uma seção capturada e, nesse estado, só abre um novo bloco diante de um separador que o próprio pytest imprime: linha na coluna zero, sublinhados dos dois lados com o lado direito igual ou um a mais que o esquerdo, e pelo menos 39 colunas, que é a largura mínima de terminal que o pytest considera. Uma faixa mais curta fica na captura. Um teste de regressão usa a saída relatada e espera uma única falha com suas linhas de erro, e os testes existentes de cabeçalhos encurtados e de separadores reais continuam válidos.
- Valor esperado
- O resumo entregue ao agente relata o número certo de falhas e atribui cada linha ao teste certo, sem falhas inventadas.
-
#4786aberto em 24/10/2026Em revisão Regras de bloqueio alcançam comandos colados ao operador de desanexar do zsh Um comando escrito logo após o operador de desanexar do zsh chegava à varredura de bloqueio com o ponto de exclamação grudado e escapava das regras; agora o prefixo é descartado antes da análise.
- O problema
- O rtk aplica regras de permissão aos comandos que um agente pede para executar, inclusive os embutidos numa chamada de shell. Ao limpar resíduos de gramática do shell antes da varredura, a rotina só tratava palavras isoladas, de propósito: um ponto de exclamação colado a uma palavra é expansão de histórico, e uma chave colada é expansão de chaves. No zsh, porém, o operador de desanexar termina em ponto de exclamação, e o que vem colado em seguida, seja um comando ou um grupo entre chaves, é um comando de verdade com o sinal preso na frente. Nessa forma, a regra de bloqueio não reconhecia o comando e o deixava passar.
- O que o PR propõe
- A limpeza passou a descartar um ponto de exclamação inicial mesmo quando colado à palavra seguinte, já que nenhum comando legítimo começa assim, e só então segue para o tratamento de palavras isoladas. Testes de regressão cobrem as formas espaçada, colada ao comando e colada a um grupo de chaves, além de controles com comandos permitidos e de comandos compostos fora de um shell embutido.
- Valor esperado
- Fecha uma brecha pela qual um comando destrutivo escaparia das regras de bloqueio só pela forma como foi escrito.
-
#4784aberto em 24/10/2026Em revisão Testes de ajuda de ferramentas no Windows deixam de abrir seis abas do navegador A suíte que compara a ajuda nativa de cada ferramenta com a ajuda via rtk chamava o Git no Windows, onde a ajuda abre no navegador; agora o Git fica fora dessa suíte só nessa plataforma.
- O problema
- O rtk tem uma suíte que verifica se a ajuda de cada ferramenta embrulhada sobrevive à passagem pelo proxy, executando a opção de ajuda nativamente e via rtk para vários comandos, entre eles três do Git. No Windows, o Git vem configurado para mostrar a ajuda em HTML, então cada chamada abre a documentação no navegador padrão em vez de imprimir a página no terminal. Rodar os testes na plataforma abria seis abas na máquina do desenvolvedor, e a comparação usava o que o Git imprimia depois de lançar o navegador, não o texto da ajuda.
- O que o PR propõe
- O Git entrou na lista de ferramentas puladas só no Windows, ao lado das utilidades Unix que a plataforma não tem, e continua exercitado nas demais. Dois testes de regressão fixam o comportamento: um garante a exclusão no Windows e o outro garante a presença nas outras plataformas. O teste de ajuda curta do Git, que não abre navegador, segue valendo em todas.
- Valor esperado
- Quem desenvolve o rtk no Windows roda a suíte completa sem interrupções e com um resultado que mede o que se propõe a medir.
-
#4555mergeado em 20/10/2026 Tarefas delegadas do RTK funcionam no Windows e com pasta do Claude própria Ao delegar trabalho a um modelo mais barato, o RTK buscava a chave de API sempre pelo sh, ausente no Windows, e ignorava a pasta de configuração personalizada do Claude Code; o PR propõe usar o shell de cada sistema e respeitar essa pasta.
- O problema
- Os comandos de tarefa do RTK delegam a um modelo mais barato trabalhos como resumir ou gerar texto, sem que os arquivos entrem no contexto do agente. A chave de API pode vir de um comando configurado, mas ele era sempre executado pelo sh, que costuma não existir no Windows, contrariando as regras de segurança do próprio projeto. O comando analisado também rodava sem tratar os atalhos .cmd e .bat do Windows, e a busca pelas conversas do Claude Code ignorava uma pasta de configuração personalizada.
- O que foi feito
- O PR propõe executar o comando da chave pelo shell padrão de cada sistema, com uma mensagem clara quando ele não pode rodar, e chamar o comando analisado pelo mesmo mecanismo que o RTK já usa para resolver atalhos e escapar argumentos no Windows. A pasta das conversas passa a seguir a configuração CLAUDE_CONFIG_DIR. Testes novos cobrem a chave lida da saída do comando, a falha com código de erro, a saída vazia e a pasta personalizada.
- Valor entregue
- Com a mudança, quem usa o RTK no Windows ou com o Claude Code numa pasta própria passa a contar com a delegação de tarefas, e a economia de tokens que ela traz, sem ajustes manuais.
-
#4621aberto em 16/10/2026Em revisão Testes aprovados do pytest não aparecem mais como falhas no RTK Com o pytest configurado para mostrar a saída dos testes aprovados, o filtro do RTK listava cada teste aprovado como falha, junto com a saída dele; o PR propõe encerrar a seção de falhas no próximo título de seção.
- O problema
- O RTK resume a saída do pytest para o agente, destacando só as falhas. O filtro entra na seção de falhas ao ver o título FAILURES e só sai dela no resumo final. Com as opções -rP ou -rA e pelo menos um teste falhando, o pytest imprime depois das falhas uma seção PASSES, com a saída dos testes aprovados, e o filtro, ainda na seção de falhas, marcava cada um deles como [FAIL].
- O que o PR propõe
- O PR propõe que qualquer novo título de seção de nível superior feche a falha em andamento e tire o filtro da seção de falhas, de modo que PASSES, o resumo de avisos e as demais seções voltem a ser tratados normalmente. Um teste novo monta uma saída com falhas seguidas de PASSES e do resumo curto e confere que só o teste que falhou aparece como falha.
- Valor esperado
- Com a mudança, o agente recebe a lista de falhas real, sem testes aprovados misturados a ela, e não perde tempo investigando problemas que não existem.
-
#4620aberto em 16/10/2026Em revisão Avisos e erros de compilação .NET chegam com arquivo e linha corretos Ao ler o log binário de compilação do .NET, o RTK pulava um campo nos avisos e erros emitidos pelo compilador C#, e tudo o que vinha depois saía deslocado; o PR propõe ler os campos na ordem exata em que o MSBuild os grava.
- O problema
- Para compilações .NET, o RTK lê o log binário do MSBuild e entrega ao agente um resumo enxuto com os avisos e erros. Cada evento desse log traz campos opcionais numa ordem fixa, e o leitor só conhecia parte deles. Quando o aviso vinha do compilador C#, que registra o nome do emissor, esse campo não era lido e as leituras seguintes ficavam deslocadas: o código do aviso ocupava o lugar do arquivo, e linha e coluna saíam erradas, como em CS0168(53,7) sem o nome do arquivo de origem.
- O que o PR propõe
- O PR propõe declarar todos os indicadores de campo do formato do MSBuild e ler cada campo presente na mesma ordem em que o MSBuild o grava, incluindo identificador da thread, palavra-chave de ajuda, nome do emissor e os dados de localização. Um teste novo monta um log com um aviso e um erro emitidos pelo compilador e confere código, arquivo, linha, coluna e mensagem de cada um.
- Valor esperado
- Com a mudança, o agente recebe do RTK avisos e erros de compilação .NET que apontam o arquivo e a linha certos, sem precisar rodar a compilação de novo para descobrir onde está o problema.
-
#4619aberto em 16/10/2026Em revisão Aviso de hook desatualizado do RTK não some mais sem ser visto O comando interno que o RTK roda antes de cada comando do agente consumia o aviso diário de hook desatualizado numa saída descartada e disparava a telemetria à toa; o PR propõe excluí-lo dessas duas rotinas, como já acontece com rtk hook.
- O problema
- Os hooks de shell e os adaptadores de plugin chamam o rtk rewrite antes de cada comando para trocá-lo pela versão do RTK, que economiza tokens. Esse caminho não estava fora de duas rotinas diárias: o lembrete de hook ausente ou desatualizado e o envio de telemetria. Quando o lembrete vencia, ele era impresso numa saída que o hook descarta e ainda marcado como já exibido, então o usuário nunca o via; e a telemetria abria uma tarefa em segundo plano num processo que termina logo em seguida.
- O que o PR propõe
- O PR propõe tratar o rtk rewrite como o rtk hook, que já ficava fora das duas rotinas por também rodar antes de cada comando. Assim, o lembrete fica para o próximo comando que o usuário de fato vê, e a telemetria deixa de ser disparada no caminho do hook. Os testes existentes foram estendidos para cobrir o rtk rewrite nas duas exclusões.
- Valor esperado
- Com a mudança, quem tem um hook desatualizado volta a ser avisado de verdade, e o comando que roda antes de cada ação do agente fica mais leve.
-
#4535aberto em 12/10/2026Em revisão Erros de escrita em stdout e stderr tratados sem abortar o processo Em compilações de release, erros de I/O na escrita de stdout ou stderr no comando rtk read causavam pânico e encerramento abrupto com SIGABRT; o PR propõe propagar o erro com código de saída limpo.
- O problema
- No rtk read, a exibição de saída usava a macro print! e, em caso de erro na escrita (como disco cheio, limite de cota excedido ou pipe quebrado), o Rust entrava em pânico. Como compilações de release usam panic = "abort", o processo era terminado abruptamente pelo sistema com SIGABRT (código 134), impedindo que ferramentas chamadoras ou scripts identificassem a causa da falha. Além disso, relatar esse erro para stderr usando eprintln! causava um segundo abort caso stderr também estivesse redirecionado ou inacessível.
- O que o PR propõe
- O PR introduz um auxiliar falível (write_output) que escreve no stdout bloqueado usando writer.write_all() e propaga o erro com Result<()>, substituindo o uso de print!. Na função main e no tratamento de comandos, a escrita em stderr passa a usar writeln! não-panificante com tratamento seguro, evitando abortos secundários. Acompanha testes unitários para write_output e testes de integração em Linux com /dev/full garantindo saída limpa com código 1.
- Valor esperado
- Elimina crashes catastróficos com SIGABRT na CLI quando o terminal ou arquivo de saída fica sem espaço ou desconecta, permitindo que esteiras de CI, agentes de IA e scripts de automação tratem o erro com código de retorno previsível.
Números atualizados em 13/11/2026.
O mesmo cuidado no seu sistema
Os mesmos hábitos destes PRs valem para backends que movimentam dinheiro: reproduzir o problema antes de corrigir, provar a correção com teste e não deixar dado sensível escapar.