# Como RTK Comprime a Saída dos Seus Comandos pra Coding Agents Gastarem Menos # Como o RTK Comprime a Saída dos Seus Comandos e Faz Coding Agents Gastarem Menos Contexto Se você usa **Claude Code**, **Codex** ou qualquer coding agent no terminal, provavelmente já percebeu um detalhe importante: boa parte do contexto consumido pelo modelo **não é o seu código**. É o output dos comandos. Um `git log` devolve dezenas de linhas formatadas. Um `cargo test` com dezenas de testes imprime centenas de linhas, mesmo quando quase tudo passa. Um `docker ps` retorna tabelas inteiras que o modelo precisa processar só para extrair uma informação simples. Cada linha dessas entra no contexto. Isso significa mais tokens, menos espaço na janela e um agent mais lento para chegar no que realmente importa. O **RTK** tenta resolver esse problema com uma ideia simples: ficar entre o coding agent e o terminal, interceptar a saída dos comandos, filtrar o ruído e devolver uma versão mais compacta. ## O que é o RTK O **RTK (Rust Token Killer)** é um binário em Rust que funciona como um **proxy CLI** entre o coding agent e o terminal. Na prática, quando o agent executa um comando como `git status`, o RTK pode interceptar essa chamada, rodar o comando real, comprimir a saída e devolver uma resposta mais enxuta. Segundo a documentação do projeto, a proposta é reduzir o volume de contexto consumido por outputs verbosos sem quebrar o fluxo normal de trabalho. O projeto é **open source**, usa licença **MIT**, está em desenvolvimento ativo e já tem **algo na casa dos 9 mil stars no GitHub**. **Repositório:** `https://github.com/rtk-ai/rtk` ## Quanto ele reduz na prática Esse é o ponto que faz a ideia ficar interessante de verdade. Segundo o projeto, o RTK costuma reduzir algo como **60% a 90%** do output em comandos comuns, com alguns casos chegando a **95%+** quando há muito ruído, repetição ou formatação redundante. Esse tipo de ganho aparece principalmente em cenários como: * **test runners**, quando a maioria dos testes passou e só poucas falhas importam * **logs repetitivos**, onde várias linhas iguais podem virar uma só com contagem * **comandos tabulares**, como `docker ps` * **listagens extensas**, como `git status`, `ls -la` ou diretórios grandes * **saídas com boilerplate**, onde muito texto existe só para consumo humano O ponto importante aqui é: essas porcentagens são **casos típicos e exemplos reportados pelo projeto**, não uma garantia universal. O ganho real depende do tipo de comando que você roda, do tamanho do projeto e de quanto ruído existe na saída. No fim, o número mais útil é o que aparece no seu ambiente com `rtk gain`. ## Como ele funciona O RTK aplica algumas estratégias de compressão dependendo do tipo de comando. ### 1\. Smart Filtering Remove ruído: comentários, whitespace excessivo, boilerplate e partes da saída que normalmente não carregam valor real para o modelo. ### 2\. Grouping Agrupa itens parecidos. Em vez de listar tudo de forma linear, ele consolida arquivos por diretório, erros por categoria ou falhas por tipo. ### 3\. Truncation Mantém o que importa e corta redundância. Se 48 de 50 testes passaram, nem sempre faz sentido gastar contexto com 48 linhas de `ok`. ### 4\. Deduplication Linhas repetidas viram uma linha com contagem. Um log com dezenas ou centenas de mensagens idênticas pode ser reduzido para algo como: ```text Connection refused (×200) ``` ## Fluxo interno, em alto nível O pipeline geral do RTK segue mais ou menos esta sequência: ```text Parse args → Route para o módulo certo → Executa o comando real → Filtra a saída → Imprime versão compacta → Registra métricas ``` A arquitetura do projeto separa filtros por categoria de comando. Há módulos específicos para coisas como **Git**, **Docker**, **cargo test**, **pytest**, **grep/rg** e outros, além de uma infraestrutura compartilhada de roteamento, tracking e relatórios. ## Instalação ### Via Homebrew ```shell brew install rtk ``` ### Via script (Linux/macOS) ```shell curl -fsSL https://raw.githubusercontent.com/rtk-ai/rtk/refs/heads/master/install.sh | sh ``` ### Via Cargo ```shell cargo install --git https://github.com/rtk-ai/rtk ``` ### Verificando ```shell rtk --version ``` > **Observação importante:** existe outro pacote chamado `rtk` no `crates.io`. Se você instalar via `cargo install rtk`, pode acabar pegando o pacote errado. Para este projeto, o mais seguro é usar `cargo install --git`. ## Setup com Claude Code O jeito mais interessante de usar o RTK com Claude Code é por meio do hook automático. ```shell rtk init --global ``` Esse comando configura um **PreToolUse hook** no arquivo: ```shell ~/.claude/settings.json ``` Depois disso, o Claude Code passa a reescrever chamadas de terminal compatíveis para usar o RTK de forma transparente. A ideia é esta: ```shell Claude pede: git status Hook reescreve: rtk git status RTK executa: git status RTK filtra: remove ruído e comprime Claude recebe: saída compacta ``` Na prática, o modelo recebe só o resultado já filtrado. ## Limitação importante do hook Aqui entra um detalhe que vale destacar porque muda bastante a expectativa de uso. O hook do RTK **só intercepta chamadas Bash**. Ou seja: ferramentas built-in do Claude Code, como **Read**, **Grep** e **Glob**, **não passam por esse hook**. Nessas situações, se você quiser o benefício da compressão, precisa usar equivalentes shell como: * `cat` * `rg` * `find` Ou chamar diretamente comandos do próprio RTK, quando fizer sentido. ## Antes e depois na prática Os exemplos abaixo são **ilustrativos**, mas seguem o tipo de redução que o projeto promete. ### Git push Sem RTK: ```shell Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 8 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 1.2 KiB | 1.2 MiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: Resolving deltas: 100% (2/2), completed with 2 local objects. To github.com:user/repo.git abc1234..def5678 main -> main ``` Com RTK: ```shell ok main ``` ### Testes com `cargo test` Sem RTK: ```shell running 15 tests test utils::test_parse ... ok test utils::test_format ... ok test utils::test_validate ... ok ... test edge::test_overflow ... FAILED test edge::test_boundary ... FAILED failures: ---- edge::test_overflow stdout ---- thread 'edge::test_overflow' panicked at 'assertion failed...' ... (stack trace) ``` Com RTK: ```shell FAILED: 2/15 tests test_overflow: assertion failed at edge.rs:42 test_boundary: panic at edge.rs:87 ``` ### Docker Sem RTK: ```shell CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES a1b2c3d4e5f6 postgres:15 "docker..." 2 hours ago Up 2 hours 0.0.0.0:5432->5432/tcp db f6e5d4c3b2a1 redis:7 "docker..." 2 hours ago Up 2 hours 0.0.0.0:6379->6379/tcp cache ``` Com RTK: ```shell 2 containers running db: postgres:15 :5432 cache: redis:7 :6379 ``` ### Listagem de diretório Sem RTK: ```shell drwxr-xr-x 15 user staff 480 Mar 15 10:23 . drwxr-xr-x 5 user staff 160 Mar 10 09:00 .. -rw-r--r-- 1 user staff 1234 Mar 15 10:23 Cargo.toml ... ``` Com RTK: ```shell my-project/ +-- src/ (8 files) | +-- main.rs +-- Cargo.toml +-- README.md ``` ## Arquitetura por dentro A estrutura do projeto segue uma divisão modular. Em vez de tratar todo output da mesma forma, o RTK tem lógica especializada para categorias diferentes de comando. Um recorte da organização interna inclui coisas como: ```shell src/ ├── main.rs ├── git.rs ├── container.rs ├── cargo_cmd.rs ├── pytest_cmd.rs ├── go_cmd.rs ├── vitest_cmd.rs ├── grep_cmd.rs ├── filter.rs ├── tracking.rs ├── gain.rs ├── discover/ ├── config.rs └── utils.rs ``` O `main.rs` faz o parse dos argumentos e roteia a execução. Depois disso, o RTK: 1. executa o comando real com `std::process::Command` 2. captura `stdout` e `stderr` 3. aplica filtros específicos para aquele tipo de saída 4. imprime a versão compacta 5. registra métricas de uso e savings Outro detalhe importante: o RTK preserva os **exit codes**. Então, se um `cargo test` falhar, o comando continua falhando corretamente do ponto de vista de CI, automações e do próprio agent. Também há fallback: se o filtro não conseguir operar do jeito esperado, a ferramenta pode repassar a saída original em vez de quebrar o fluxo. ## Tracking de savings Além de comprimir a saída, o RTK registra métricas localmente em SQLite para mostrar quanto contexto você deixou de gastar. Exemplos de comandos: ```shell # Resumo geral rtk gain # Gráfico ASCII dos últimos 30 dias rtk gain --graph # Histórico recente de comandos rtk gain --history # Breakdown por dia rtk gain --daily # Export JSON rtk gain --all --format json ``` Também existe o `rtk discover`, que analisa o histórico recente e tenta identificar oportunidades onde você poderia economizar mais: ```shell rtk discover rtk discover --all --since 7 ``` ## O que eu acho mais interessante aqui A parte mais legal do RTK não é só “deixar output bonito”. É mudar a economia do contexto. Em coding agents, a disputa por janela não acontece só entre arquivos do projeto. Ela acontece também entre: * logs * listagens * tabelas * stacks * resultados de teste * respostas de comandos repetitivos Se esse lixo operacional some ou encolhe bastante, sobra mais espaço para o que interessa de verdade: código, diffs, instruções e raciocínio. ## Limitações e trade-offs Esse é o tipo de ferramenta que vale muito mais quando você entende onde ela não cobre. ### 1\. Só funciona em chamadas de terminal compatíveis Se o agent estiver usando ferramentas internas em vez de shell, o RTK não entra no caminho automaticamente. ### 2\. Compressão demais pode esconder contexto útil Esse é o trade-off natural. Em alguns casos, o output completo pode ser importante. O RTK oferece níveis de verbosidade, mas isso exige escolha explícita. ### 3\. Projeto novo O RTK é recente e começou a ganhar releases públicas em 2026. Já tem bastante atenção, mas ainda não é uma ferramenta com anos de histórico em produção. ### 4\. Savings variam conforme projeto e fluxo Os números de economia publicados pelo projeto são úteis como referência, mas o ganho real depende do seu stack, do tipo de comando que você roda e do quanto seu workflow é verboso. ## Quando faz sentido usar O RTK parece fazer mais sentido se você: * usa coding agents no terminal com frequência * trabalha em projetos médios ou grandes * roda comandos com saída muito verbosa * se importa com custo e com janela de contexto * quer deixar mais espaço livre para código e instruções ## Quando talvez não faça tanta diferença Pode não valer tanto a pena se você: * usa pouco terminal no fluxo com agents * trabalha em projetos pequenos * já tem outputs naturalmente enxutos * prefere ver sempre a saída completa sem nenhum filtro no meio ## Conclusão O RTK é uma ideia simples, mas bem alinhada com um problema real do uso de coding agents: **output demais também consome inteligência**. A proposta não é substituir o terminal nem inventar um novo workflow. É só reduzir o desperdício de contexto gerado por comandos que já são naturalmente verbosos. E o ponto mais convincente aqui é justamente o impacto prático: em vez de pequenas otimizações marginais, o RTK fala em **reduções típicas de 60% a 90%**, com alguns cenários indo além disso. Para quem usa agent o dia inteiro, isso deixa de ser detalhe e vira parte do workflow. Se você usa Claude Code, Codex ou fluxos parecidos no terminal, esse tipo de proxy pode fazer bastante sentido — principalmente em projetos onde testes, logs, Git e Docker já ocupam uma parte grande da conversa com o modelo. No mínimo, vale testar por alguns dias e olhar o que o `rtk gain` mostra no seu caso. ## Referências * Repositório do projeto: `https://github.com/rtk-ai/rtk` * Documentação de arquitetura: `https://github.com/rtk-ai/rtk/blob/master/ARCHITECTURE.md` * Troubleshooting: `https://github.com/rtk-ai/rtk/blob/master/docs/TROUBLESHOOTING.md`