A ilusão da compressão de tokens: por que sou cético em relação ao RTK

• O RTK promete reduzir custos comprimindo a saída do terminal de agentes de programação, mas a redução da saída bruta não significa automaticamente engenharia de software mais barata, segura e precisa
• “Redução de 60~90%” não quer dizer que a fatura do LLM caiu nessa mesma proporção; está mais perto da taxa de saída de linha de comando que o RTK removeu
• Se ocorrer silent failure, em que a saída do terminal é corrompida ou omitida silenciosamente, o agente pode tomar decisões erradas sem stack traces importantes ou sem o contexto do compilador
• Gráficos de economia de tokens, por si só, não bastam; são necessários a taxa de sucesso das tarefas e avaliações de precisão no estilo SWE-bench para mostrar se agentes autônomos realmente concluíram o trabalho
• O RTK parece mais um recurso de ferramenta de desenvolvimento do que um produto independente e, por ser frágil a mudanças na saída de CLI como git, cargo, npm e grep, traz alto risco operacional para colocá-lo no caminho crítico de agentes em produção

---

A estrutura real de custos escondida pelos números de economia

• O RTK promove redução no uso de tokens e diminuição de custos por meio da compressão da saída de terminal para agentes de programação
  • Conseguiu mais de 60k estrelas no GitHub, e o setor está reagindo fortemente a essa divulgação
  • Ainda assim, alegações de ferramentas de desenvolvimento que parecem “boas demais” precisam ser examinadas na sua estrutura real
• O número viral de “redução de 60~90%” não é o mesmo que redução real na cobrança da API
  • O que o RTK reduz é apenas parte da saída do Bash
  • Permanecem fatores de custo maiores, como leitura profunda de arquivos, contexto do repositório, prompt de sistema e tokens de raciocínio interno do modelo
  • Comandos como rtk gain parecem mais orientados a métricas boas para screenshots em redes sociais ou para mostrar a gestores não técnicos do que a otimizações arquiteturais fundamentais
  • Issues recentes no GitHub também começaram a levantar questionamentos sobre métricas exageradas

Precisão e estabilidade operacional são variáveis mais importantes

• Otimização não tem valor se a precisão não acompanhar, e já há casos em issues públicas do repositório em que a saída do terminal quebra silenciosamente ou é omitida
  • O risco central é que o agente de IA não sabe que o texto foi comprimido
  • Se o RTK remover linhas importantes de um stack trace ou do contexto do compilador para economizar alguns tokens, tanto o usuário quanto o LLM passam a trabalhar com informação incompleta
  • Adotar o RTK significa depender de uma camada externa que precisa fazer parsing, interpretar e resumir a saída de inúmeras ferramentas de CLI sem perda de significado
• O RTK mostra gráficos de economia de tokens, mas falta a métrica que realmente importa: a taxa de sucesso das tarefas
  • O ponto central é se o agente autônomo resolveu o problema de engenharia de software ao fim do loop de execução
  • Mesmo reduzindo o custo do prompt em 80%, se a degradação de contexto fizer o agente alucinar, falhar no build ou entrar em loop, no fim ele pode gastar ainda mais tokens
  • Até que surjam avaliações rigorosas de precisão no estilo SWE-bench junto com os gráficos de custo, a narrativa do RTK permanece incompleta
• Do ponto de vista de arquitetura, o RTK adiciona uma dependência externa frágil no caminho crítico síncrono entre o agente e o shell
  • A otimização da saída parece mais um recurso do que um produto independente ou uma plataforma
  • Se CLIs e ferramentas de desenvolvimento importantes passarem a oferecer flags nativas como --compact ou --json-stream voltadas ao consumo por LLMs, a principal vantagem do RTK pode desaparecer
• O RTK depende fortemente de fazer parsing de formatos de stdout/stderr feitos para humanos, o que dificulta sua manutenção
  • Se git, cargo, npm ou grep mudarem alguns espaços no formato do terminal ou o layout de erros, os regexes e filtros de parsing do RTK podem quebrar
  • Nesse caso, ele pode falhar silenciosamente em vez de emitir um erro explícito, fornecendo ao agente texto corrompido ou parcial
• O RTK troca confiabilidade determinística, completude semântica e simplicidade arquitetural por uma métrica chamativa de redução bruta de tokens no terminal
  • Até resolver a silent degradation e fornecer benchmarks transparentes de precisão nas tarefas, colocá-lo no caminho crítico de workflows de agentes em produção traz um risco operacional alto demais para o tamanho do desconto

[GN⁺]

Comentários do Hacker News

• Fico feliz que textos como este finalmente estejam ganhando força em relação à indústria da caixa mágica de LLMs como um todo
  Do caveman mode ao RTK e à busca semântica, parece que os desenvolvedores viraram mais feiticeiros recitando encantamentos do que engenheiros, e no trabalho isso é especialmente cansativo porque cada um tem certeza de que o seu próprio feitiço é a forma definitiva de economizar tokens
  Meu critério é este: ideias que não estão dentro de um harness de avaliação em geral não prestam, e ideias boas acabam subindo para o Codex/Claude. Também é difícil acreditar em anúncios no GitHub dizendo que economizam alguns por cento de tokens
  É difícil evitar ferramentas picaretas nessa área, e queria que as pessoas começassem a olhar isso de forma mais crítica

  • Isso está completamente errado, e você está subestimando o quanto as empresas da linha de frente são incompetentes em áreas que não sejam criar modelos de LLM
    Ao longo de um ano houve até casos como TUIs piscando “escritas como engines de jogo”, e rodando vários benchmarks por conta própria vi que existem métodos comprovados de reduzir tokens mantendo o mesmo resultado. Por exemplo, encontrar o mesmo CVE ou achar o mesmo bug numa revisão de código
    Você pode ver uma pequena prova minha em https://maki.sh
  • Por isso eu faço testes A/B cegos em tudo
    Queima muitos tokens, mas é preciso provar que há valor real, e a maioria das coisas fica muito aquém desse critério
    Meu agente de IA também tem vários recursos, mas não acho que o resultado de um teste A/B cego de 4 meses atrás continue válido hoje. Só a escolha das palavras que eu uso já pode mudar bastante o resultado
    Ainda assim, eu testo para verificar o valor diretamente e ver com os próprios olhos. Não faço questão de divulgar resultados específicos dos testes A/B cegos
    Também vi outras pessoas fazendo testes A/B cegos de forma muito errada, e se a medição é ruim o teste em si não significa nada
    Todos nós estamos tentando resolver esse problema juntos, e há muita magia negra, então dependo bastante de hooks. Meu pequeno agente de IA provavelmente também está cheio de magia negra
    A única coisa de que tenho certeza é que funciona para mim. Sem isso, sinceramente não sei como as pessoas estão trabalhando com IA hoje
    Vou deixar o link, mas isso não significa que eu recomende, seja lá o que você fizer. No geral só outros engenheiros de software usam isso, e ele é muito especializado no tipo de trabalho que eu preciso fazer. Na melhor das hipóteses, pode te dar ideias para implementar por conta própria
    https://github.com/notque/vexjoy-agent
  • A frase “ideias boas sobem para o Codex/Claude” só vale quando alguém cria ferramentas como o RTK e outras pessoas podem experimentá-las
    Tudo bem só observar esta rodada de fora, mas ferramentas como RTK, Headroom e caveman mode reduzem os tokens de entrada e saída que precisam ser processados, e em LLMs locais podem gerar ganhos mensuráveis de velocidade
    Ainda não há dados suficientes para dizer se isso prejudica a qualidade da saída final, mas é divertido fuçar para descobrir
  • A ideia em si é válida. Se der para reduzir a relação sinal-ruído da janela de contexto, isso é uma coisa boa
    Só que ainda não foi demonstrado que o RTK de fato faz isso. Em vez de frases sem sentido como “até 90%”, eu queria ver benchmarks adequados da diferença real que essa ferramenta produz
  • Indo além, algumas das otimizações que vi no rtk para comandos como git status parecem já ter subido para a camada do modelo
    O Codex agora costuma fazer chamadas de ferramenta como git status --short em vez de git status

• Sou o autor do texto. Sinceramente, escrevi isso porque, como engenheiro de software, o rtk ai me pareceu muito estranho
  A falta de números, a ausência de qualquer menção à precisão, e a forma como a gerência empurra isso em nome da otimização de custos me incomodaram. Agora as pessoas estão tentando envolver com rtk todos os comandos possíveis, processar todos os comandos principais e até decidir que saída deve ser recebida

  • Gostaria sinceramente de ouvir opiniões sobre https://www.github.com/jahala/tilth
    É uma abordagem diferente do RTK, e foi benchmarkada com uma redução de cerca de 40% no custo por resposta correta
  • Não entendi por que não apresentaram nenhum número de uso real para sustentar a afirmação. Não ajudou muito

• A saída das ferramentas representa uma parte grande da minha saída. Se eu puder economizar 3,7 milhões de tokens de 3,9 milhões de tokens de entrada, eu aceito. Token economizado é token economizado
  Como usuário do RTK, seria bom ter benchmarks de precisão, mas ainda não vi evidência de que o modelo deixou passar algo importante por causa da compressão
  Pela filosofia de design, a preservação da precisão é tratada com muito rigor, a ponto de voltar para a saída original se o filtro falhar. Também vi diretamente o código-fonte de comandos usados com frequência, gostei do que vi e, até agora, diria que ganhou minha confiança
  Também existe a preocupação de que, se git, cargo, npm ou grep mudarem algumas colunas da formatação do terminal ou o layout de erros, os regexes e parsers do RTK possam quebrar. Mas, se o filtro falhar, ele volta para a saída original. O RTK é uma ferramenta projetada para não alimentar o agente com texto corrompido ou parcial
  A preocupação é válida, mas eu gostaria que a crítica fosse sustentada por evidências. Fico curioso para saber se usaram o RTK e se encontraram evidências de que ele não preserva a precisão

  • Vi isso enquanto investigava o assunto, e alguns problemas que chamaram atenção parecem bem ruins
    https://github.com/rtk-ai/rtk/issues/2494
    https://github.com/rtk-ai/rtk/issues/2462
    https://github.com/rtk-ai/rtk/issues/2395
  • Às vezes token economizado não é token economizado
    O RTK remove flags e outras informações. Às vezes isso faz você gastar mais tokens depois para recuperar aquilo. Mesmo que tenha economizado 70% dos tokens naquela chamada de ferramenta, a métrica não mostra se você fez 3 chamadas de ferramenta em vez de 1
    Também é preciso considerar se a saída removida faz você gastar mais tokens de raciocínio
  • Não acho que só preservar a precisão com muito rigor seja suficiente
    Considerando a diferença de custo entre modelos de ponta e modelos open weight defasados, ou entre o maior modelo e o modelo logo abaixo dele, o desempenho precisa ser medido com muito cuidado
    Em vez de dizer que quem critica é que precisa apresentar provas, o RTK precisa provar que não piora o desempenho

• O ponto central é que existem incontáveis ferramentas que dizem melhorar a IA, mas não há maneira de medir se a IA realmente está funcionando melhor
  Grandes empresas com produtos populares têm um jeito de fazer isso. Em algum ponto entre analytics tradicionais de produto e avaliação de chatbot, elas entendem se o usuário está tendo sucesso na sessão. Esse é o trabalho
  Mas um desenvolvedor individual rodando 3 a 50 sessões por dia quase não tem como saber o que está melhorando o LLM. É tudo no feeling
  Na nossa empresa, temos a stack inteira: harness, modelo, skills e até estrutura de código preferidos. Mesmo em uma escala de um milionésimo do Claude Code, deveria haver uma forma de medir se essa configuração funciona para nós

  • No meu produto, eu digo explicitamente para perguntar ao agente. Há exemplos reais e repositórios reais que você pode testar por conta própria
    https://gitsense.com
    https://github.com/gitsense/smart-ripgrep
    https://github.com/gitsense/smart-codex
    Não me importo tanto com economia média de tokens. O que mais me importa é se a IA não está colocando arquivos desnecessários no contexto, porque isso pode afetar o raciocínio
    Depois da tarefa, basta perguntar ao agente: “quantos arquivos você acha que não teria lido se soubesse antes qual era o propósito deles?”
  • O esforço para criar um benchmark válido é enorme. Provavelmente isso é verdade, e é justamente por isso que irrita mais
    Já havia muita discussão mesmo com frameworks existentes, e isso é muito pior. Vira uma disputa de meu feeling contra seu feeling. Quem diria que saídas não determinísticas nos levariam até aqui
  • Existe uma resposta. Essas ferramentas precisam ser avaliadas não por simples economia de tokens, mas por custo por resposta correta

• Eu usei diretamente, e as mensagens que ocupam 90% do meu contexto não são comprimidas, então ele comprimiu só uma parte pequena do uso total de tokens
  Se você ler o post com atenção, ele já diz isso claramente. Se olhar o /context, provavelmente verá que onde os tokens estão sendo gastos não é nas chamadas de ferramenta. Então um proxy que só comprime chamadas de ferramenta não causa grande impacto, mesmo que seja verdade que comprime chamadas de ferramenta em 8x
  Em sessões longas de programação, isso não foi tão importante para mim
  “native/built-in Read or cat tools, the data is not intercepted by RTK's shell hook”

• Este post quase não tem dados que sustentem a refutação e, em grande parte, soa como um texto gerado por LLM

• Também já recebemos reclamações assim na Semble. Acho que é uma reclamação válida, mas criar esse tipo de benchmark é muito difícil e caro por causa da combinação harness × modelo × MCP/CLI
  Em ferramentas tradicionais ou em machine learning tradicional, não mostrar benchmark normalmente era um sinal de alerta. Mas em ferramentas para LLM, eu já não sei

• Se você fizer o agente perceber a compressão do RTK e tiver uma opção de bypass, existe uma maneira de fazê-lo detectar truncamento. Eu uso RTK_DISABLE=1 para restaurar o texto original completo
  Funciona bem, e sim. Como ele só comprime a saída de comandos, do ponto de vista de “compressão” isso afeta apenas os tokens de entrada

• É verdade que CLIs e ferramentas de desenvolvedor mais populares poderiam oferecer flags nativas como --compact ou --json-stream voltadas ao consumo por LLM, mas eles não vão fazer isso tão cedo
  É por isso que ferramentas como rtk, caveman e ponytail continuam tentando reduzir esses custos crescentes. Em uma organização de 2 mil pessoas, isso hoje fica em algo como 2,5 milhões de dólares, e todo mundo está ajustando isso ciente desses trade-offs
  Ao contrário do que o autor afirma, nós conhecemos muito bem esses trade-offs e usamos essas ferramentas fazendo fork, benchmark e validando se a qualidade da saída atende às nossas necessidades. Não estamos usando às cegas
  Para um desenvolvedor individual, talvez isso realmente não seja necessário, e talvez seja melhor fazer self-host de outro modelo para reduzir custos. Mas em organizações isso pesa bastante
  É bom que posts como este tragam o assunto à tona, mas, assim como fazemos com ferramentas, também é preciso ler esse tipo de post com algum filtro

• Testei rtk gain no Mac. Não consegui verificar na minha máquina principal de desenvolvimento porque a reimagei por causa de problemas de memória e algumas coisas ficaram bagunçadas, mas no Mac ele reduziu cerca de 51 mil tokens de entrada e 23 mil tokens de saída, e economizou em média 3 segundos por comando
  Não entendo muito bem por que estão tão indignados com isso, nem por que sentiram necessidade de escrever um texto sobre o assunto
  Não sei quem estaria mandando stack traces para o RTK por pipe. Eu só uso isso em um programa bem específico, e enfiar a saída do compilador ali parece uma bobagem. Basta instruir o agente a usar RTK apenas para um conjunto específico de comandos