Na minha análise, o desperdício de tokens em fluxos com agentes raramente mora dentro do modelo. Mora na interface entre humano, código de orquestração e a forma como informação entra e sai do contexto. Quatro abordagens cujo uso se difundiu no último ano atacam essa interface por ângulos diferentes, e analisá-las isoladamente rende menos do que tratá-las como pontos num espaço de dois eixos: escopo temporal e agressividade da técnica.
A primeira é o RTK, Rust Token Killer, um proxy CLI que intercepta a saída de comandos antes que ela entre na context window. Comandos como cargo build, git status e kubectl get pods enchem o contexto de boilerplate, e a maior parte é ruído. O RTK reescreve o output em trânsito via PreToolUse hook e entrega ao modelo só o que importa. Os números publicados reportam 89% de redução média de ruído sobre 2.900 comandos, sessões três vezes mais longas antes do estouro e economia aproximada de 70% em custo de API. É determinístico, com modo de falha específico: perder uma linha de log crítica quando o filtro interpreta mal o padrão. A compatibilidade cobre os principais agentes (Claude Code, Cursor, Gemini CLI, Aider, Codex, Windsurf, Cline) e a adoção é tempo de instalação.
O Token Efficiency Skill, de Delphine L., opera como protocolo que redefine o comportamento padrão do agente, fora da categoria de ferramenta instalável. Por padrão, agentes de código leem arquivos inteiros quando um grep resolveria. O mesmo se repete em escrita, onde reescrever o arquivo todo substitui um sed cirúrgico, e em consulta a JSON, onde a leitura completa toma o lugar de um jq '.metadata'. O skill troca esses padrões por equivalentes em bash e escolhe modelo conforme a fase, Opus pra aprender um codebase novo, Sonnet pro trabalho rotineiro. A economia documentada em operações de arquivo chega a 90–95%, e o efeito típico é a queda de 500K tokens por semana pra 30–50K. O risco é distinto do RTK: ao delegar operações a shell, o agente pode escolher o atalho errado num arquivo crítico, o que exige critério no uso.
O Caveman ataca o problema pelo lado oposto do pipeline. Enquanto RTK e Token Efficiency Skill reduzem o que entra no modelo, o Caveman reduz o que o modelo gera. E o output costuma custar três a seis vezes mais por token que o input nos principais provedores, o que torna essa otimização desproporcionalmente valiosa. O skill força o agente a se comunicar em linguagem telegráfica, sem artigos nem conjunções. Uma explicação de re-render em React que ocuparia 1.180 tokens em prosa cai pra 159, redução de 87%. A média reportada em tarefas diversas é 65%. A aplicabilidade é estreita. Cabe onde a comunicação é máquina-pra-máquina ou interna densa: tickets, documentação técnica, mensagens de commit. Sai de cena assim que o destinatário humano espera prosa: cliente final, material educativo, marketing.
A quarta muda de eixo. Obsidian, combinado com obsidian-skills de Steph Ango, o obsidian-mcp-server e o padrão infinite-context, não otimiza o que acontece dentro de uma sessão. Redistribui onde o conhecimento do projeto reside ao longo do tempo. Sem camada externa, toda nova sessão paga o preço de reconstruir arquitetura, convenções e decisões, e em semanas esse custo rivaliza com o desperdício intra-sessão. O padrão opera em três camadas: CLAUDE.md e MEMORY.md sempre carregados como índice de ponteiros; notas markdown de arquitetura no vault, lidas sob demanda; e o vault inteiro como camada persistente via MCP. O caso infinite-context reporta redução de 62% no overhead por sessão de 80 mensagens, com queda de ~32.000 tokens (MEMORY.md como storage) pra ~12.100 (como índice). Os números vêm de um único caso publicado, não de benchmark independente, o que torna prudente tratar o padrão como arquiteturalmente sólido e os valores como indicativos.
O risco é distinto: o vault só serve se mantido atualizado, e documentação divergente do código alimenta o agente com informação errada que chega com o mesmo peso da correta.
As quatro só fazem sentido cruzadas nos dois eixos. No eixo do escopo, RTK, Token Efficiency Skill e Caveman atuam dentro de uma sessão e entregam ganho imediato; Obsidian atua entre sessões, com ganho cumulativo que só compensa em projeto de semanas ou meses. No eixo da agressividade, o RTK é conservador, filtra de forma determinística. O Token Efficiency Skill fica num registro moderado, altera protocolo sem mexer na semântica. O Caveman é o mais agressivo do conjunto, distorce deliberadamente a saída. Já o Obsidian é estrutural, num plano distinto: muda onde o conhecimento reside, não como é processado. Pra mim, colocar Caveman e Obsidian na mesma coluna seria enganoso, um reduz tokens por reescrita extrema, o outro realoca custos pra fora do caminho crítico.
A ordem prática de adoção decorre do cruzamento. O RTK entra primeiro pelo perfil ganho-alto-risco-baixo de instalação trivial. O Token Efficiency Skill entra em seguida, já que internalizar as regras muda o modo padrão de operação sem exigir infraestrutura. O Obsidian entra quando o projeto tem horizonte de meses e o custo de manter o vault é menor que o de refazer o onboarding. O Caveman entra por último, e apenas onde cabe.
Nenhuma das quatro tenta otimizar o modelo. Todas movem o ponto de otimização pra fora dele. O RTK intercepta o input. O Token Efficiency Skill redefine como o agente opera. O Caveman reescreve o output, e o Obsidian realoca onde o conhecimento persiste no tempo.