RTK, Caveman e TokenSave: a Stack Open Source que Corta 80% dos Tokens no seu Agente

Agentes de terminal como Claude Code e OpenCode têm um problema que não aparece nos benchmarks: eles incineram tokens de formas que você não antecipa.

Não é o custo da query em si. É o output de 400 linhas de um npm test que entrou inteiro no contexto. É o modelo explicando em três parágrafos o que vai fazer antes de fazer. É o agente rodando find e lendo arquivos inteiros só para achar a assinatura de um método. Cada um desses comportamentos é um vazamento diferente, e cada um exige uma solução diferente.

Existe uma stack de ferramentas open source — todas escritas em Rust, todas rodando localmente, todas com zero dependências pesadas — que ataca exatamente esses três vetores. RTK para o output de comandos. Caveman para o verbosismo do modelo. TokenSave para o overhead de descoberta de código.

Vou explicar cada uma com os números reais, as limitações que não aparecem no README, e como combinar as três de forma que faça sentido.

Por que Rust? Por que local?

Antes de entrar nas ferramentas, vale nomear a escolha de stack. As três são escritas em Rust porque o caso de uso exige latência mínima e zero overhead de runtime — você não quer que o seu interceptador de tokens esteja adicionando 200ms por chamada. Rodam localmente porque a privacidade do código importa e porque latência de rede mataria o benefício.

Para quem está acostumado com ferramentas Python do ecossistema LLM, a instalação via brew ou cargo é um contraste bem-vindo.

Ferramenta 1: RTK — Rust Token Killer

GitHub: github.com/rtk-ai/rtk

O problema que resolve

Quando um agente de terminal executa um comando — npm test, git log --oneline -50, eslint src/ — o output entra inteiro no contexto do LLM. Isso inclui linhas de progresso, warnings que você já sabe que são inofensivos, stacktraces com 80 linhas repetidas, e tudo mais que um humano processaria em segundos mas que o modelo vai tokenizar completamente.

RTK funciona como um proxy de CLI que intercepta o stdout e stderr antes de chegarem ao contexto do LLM. Ele filtra, comprime e entrega só o essencial: o resultado final, os erros reais, as linhas que efetivamente importam para a decisão do agente.

O número que o projeto reporta: até 90% de economia nos tokens de output de comandos.

Instalação e configuração

# Via Homebrew
brew install rtk

# Ou via Cargo
cargo install --git https://github.com/rtk-ai/rtk

Para inicializar como plugin global do OpenCode:

rtk init -g --opencode

Para verificar o ganho ativo na sessão atual:

rtk gain

Quando vale, quando não vale

RTK é muito útil se o seu agente executa muitos comandos de terminal com output verboso. Projetos com test suites longas, pipelines de lint, compilações com warnings, operações de git em repositórios com histórico extenso — são todos casos onde o RTK vai entregar savings reais e imediatos.

É inútil se o seu agente faz principalmente chamadas de API, geração de texto ou operações que não geram output de terminal. Não faz milagre onde não tem problema.

Um ponto de atenção: a filtragem é heurística. Em outputs de comandos muito específicos da sua stack, o RTK pode ocasionalmente filtrar informação que você precisava. Vale rodar com rtk gain ativamente nos primeiros dias para entender o que está sendo cortado.

Ferramenta 2: Caveman

GitHub: github.com/JuliusBrussee/caveman | Fork para OpenCode: github.com/anthonystepvoy/caveman-opencode

O problema que resolve

LLMs são treinados para ser assistentes conversacionais. Isso significa que o modelo natural de um LLM sem instruções específicas é: explicar o que vai fazer, fazer, resumir o que fez, pedir desculpa se algo não funcionou perfeitamente, e perguntar se você quer mais alguma coisa.

Em um chat de suporte, esse comportamento é desejável. Em um agente autônomo rodando dezenas de steps, é desperdício caro.

Caveman é uma skill de prompt que desliga o modo "assistente polido" do modelo e instrui o LLM a comunicar apenas o essencial, no menor número de tokens possível.

O impacto em números

O benchmark mais robusto que encontrei foi do Kuba Guzik, que testou o Caveman contra um baseline conversacional normal e contra um simples "seja conciso":

• Redução de output tokens vs baseline: 45%
• Redução vs "seja conciso": 39%

O delta de 39% em relação a simplesmente pedir brevidade é o dado mais revelador. Não é só que o Caveman funciona — ele funciona significativamente melhor do que a instrução óbvia.

Por que funciona melhor do que "seja conciso"

Tem uma pesquisa interessante aqui. O paper "Brevity Constraints Reverse Performance Hierarchies in Language Models" mostrou que brevidade forçada não apenas reduz tokens — em certos benchmarks, ela melhora precisão em até 26 pontos percentuais.

O mecanismo proposto: modelos grandes tendem a over-elaborar o raciocínio nos outputs, e esse excesso de elaboração introduz erros — o modelo "convence a si mesmo" de uma resposta incorreta ao detalhar demais um raciocínio que estava no caminho certo quando era compacto. Forçar brevidade remove esse mecanismo de auto-sabotagem.

Isso não significa que brevidade sempre melhora qualidade. Em tasks complexas que precisam de raciocínio explícito (matemática, análise multi-etapa), comprimir o output pode degradar a resposta. Mas em tasks de agente — onde o modelo está executando ações e reportando resultados — o benefício é real.

Os níveis do Caveman

Lite    → Remove filler words, mantém artigos e conectivos
Full    → Default. Remove artigos, usa fragments de frases  
Ultra   → Abreviações agressivas, usa → para causalidade
Wenyan  → Chinês Clássico (teto teórico de compressão, não prático)

Para agentes em português, o Full é o ponto de equilíbrio. O Ultra pode gerar outputs que, apesar de corretos, ficam difíceis de auditar se você precisar revisar logs.

Exemplo concreto (antes/depois no Full):

Antes: "Aqui está como a autenticação funciona nesta aplicação. Este é um sistema de autenticação simulado — sem backend real, sem senhas armazenadas de verdade. Foi construído especificamente para demonstrações de rastreamento..."

Depois: "Auth in app → demo-only, client-side, no security. Built for RUM tracking demos."

Sub-skills disponíveis

• caveman-commit: formata git logs de forma concisa
• caveman-review: retorna uma linha por achado em code review
• caveman-compress: reescreve documentos longos em estilo Caveman para uso como contexto comprimido em sessões futuras

Instalação

npx skills add https://github.com/juliusbrussee/caveman --skill caveman

Ativação dentro do agente:

/caveman      # Ativa modo Full
/caveman 2    # Ativa modo Ultra

A desvantagem que o README não destaca

A skill do Caveman em si é um system prompt relativamente longo. Na primeira request de uma sessão nova, você paga ~4 centavos de input para carregar a skill. Em uma sessão multi-turn com prompt caching ativo, esse custo é amortizado rapidamente e os savings de output dominam com folga.

Para queries isoladas e únicas, o custo de carregar a skill vai superar o saving gerado. Caveman é uma ferramenta de sessão, não de query individual.

Ferramenta 3: TokenSave

GitHub: github.com/aovestdipaperino/tokensave

O problema que resolve

Quando um agente recebe uma task de código — "adicione tratamento de erro na função de autenticação", "refatore o módulo de pagamentos" — a estratégia padrão da maioria dos agentes é brute-force: rodar find . -name "*.ts", ler vários arquivos inteiros, procurar padrões via grep, construir mentalmente um mapa do codebase.

Esse processo de descoberta pode consumir centenas de tokens por step, especialmente em repositórios maiores. E acontece repetidamente dentro da mesma sessão se o agente precisar explorar módulos diferentes.

TokenSave resolve isso indexando o codebase localmente como um grafo AST em SQLite. Em vez de explorar o filesystem com comandos, o agente consulta o MCP server do TokenSave e recebe snippets exatos — assinaturas de funções, definições de tipos, referências de imports — sem precisar abrir nenhum arquivo inteiro.

O saving reportado: 60-80% de overhead de descoberta de código.

Instalação e configuração

# Instalação
brew install aovestdipaperino/tap/tokensave

Configuração no ~/.config/opencode/opencode.json (formato MCP server):

{
  "mcpServers": {
    "tokensave": {
      "command": "tokensave",
      "args": ["serve"]
    }
  }
}

Antes de cada sessão, indexe o repositório:

tokensave sync

O sync precisa rodar quando o codebase muda significativamente. Para projetos em desenvolvimento ativo, um sync no início da sessão de trabalho é suficiente.

TokenSave suporta mais de 30 linguagens — TypeScript, Python, Go, Rust, Java, e outros.

Quando faz sentido

TokenSave entrega savings reais em codebases de tamanho médio a grande (a partir de uns 50+ arquivos de lógica de negócio). Em projetos pequenos, o overhead de rodar tokensave sync não se justifica — o agente vai achar o que precisa em poucos greps de qualquer forma.

É especialmente útil em sessions longas onde o agente vai explorar múltiplos módulos. O índice AST é consultado várias vezes por sessão, então o custo do sync inicial se amortiza rápido.

Combinando as Três: Sequência de Inicialização

As economias não são multiplicativas de forma direta. Cada ferramenta age sobre uma fatia diferente do custo total de uma sessão:

• RTK: tokens de output de comandos de terminal
• Caveman: tokens de output do modelo
• TokenSave: tokens de input de descoberta de código

Uma sessão típica de agente tem contribuições de todas as três fatias, então combinar as três faz sentido. A sequência:

# 1. Indexa o codebase antes de abrir o agente
tokensave sync

# 2. Verifica se RTK está ativo
rtk gain

# 3. Abre o agente e ativa Caveman na primeira interação
/caveman 1

Estimativa honesta dos savings combinados

Os números que circulam na internet somam os percentuais de forma otimista: "RTK -90% + Caveman -45% + TokenSave -70% = economia dramática". Isso é matematicamente incorreto.

O que você pode esperar de forma realista, em uma sessão de desenvolvimento típica com Claude Code ou OpenCode em um repositório médio:

• Sem nenhuma ferramenta: baseline de custo
• Só RTK: redução de 30-50% se o agente roda muitos comandos (a fatia de output de terminal pode ser grande)
• RTK + Caveman: redução de 55-70% em sessões longas
• RTK + Caveman + TokenSave: redução de 70-85% em codebases maiores

O caveat: se o seu agente não roda comandos de terminal, RTK não ajuda. Se você não tem um codebase com estrutura complexa, TokenSave não ajuda. As ferramentas são aditivas quando todas as condições se aplicam, e neutras quando não se aplicam.

O que não está incluído

Essa stack não substitui as otimizações de prompt (estrutura estático-antes-dinâmico-depois) nem o Prompt Caching do provider. Idealmente você empilha essa stack com as camadas de cache do provider e obtém o maior benefício agregado possível.

A hierarquia de impacto, grosso modo: estrutura de prompt + KV cache (gratuito, maior impacto) → Prompt Caching (baixo esforço, desconto direto na fatura) → RTK + Caveman + TokenSave (esforço de configuração, savings significativos em sessões longas).

Conclusão

Não existe bala de prata para custo de tokens em agentes. Existe uma série de problemas distintos que precisam de soluções distintas.

RTK, Caveman e TokenSave são três ferramentas bem focadas: cada uma resolve um problema específico, tem custo de configuração baixo, roda local sem dependências pesadas, e entrega savings mensuráveis nas condições certas.

A pergunta certa antes de instalar qualquer uma delas é: qual é a maior fatia de custo na minha sessão típica? Se é output verboso de comandos, comece pelo RTK. Se é o modelo sendo prolixo, comece pelo Caveman. Se é overhead de descoberta em um codebase grande, comece pelo TokenSave.

E se as três fatias são relevantes para o seu caso de uso, a combinação das três entrega resultados que justificam o esforço de configuração — especialmente em sessões longas e repositórios com alguma complexidade de estrutura.

Fontes:

• Paul Hackenberger — The Ultimate Token Saving Stack: RTK, Caveman and TokenSave
• Better Stack — Caveman LLM
• GitHub — rtk-ai/rtk
• GitHub — JuliusBrussee/caveman
• GitHub — aovestdipaperino/tokensave
• Kuba Guzik — I Benchmarked the Viral Caveman Prompt, Then My 6-Line Version Beat It