title: "Economia de Tokens em CLIs de IA: Skills, Dispatch, RTK e Caveman sem Folclore" subtitle: "Como montar um stack de produtividade para Claude Code, Codex CLI e Gemini CLI que reduz contexto inútil, custo operacional e retrabalho" date: "2026-05-02" slug: "economia-tokens-stack-skills-cli" tags: ["ai", "codex-cli", "claude-code", "gemini-cli", "token-economy", "developer-productivity"] excerpt: "Um guia completo para entender e implementar um stack de economia de tokens com skills-selector, smart-dispatch, RTK, caveman e context-mode em CLIs de IA, separando ganhos reais de promessas exageradas."

English summary (PT-BR article): A practical guide to reducing token waste in AI coding CLIs with skills-selector, smart-dispatch, RTK, caveman, and context-mode. It explains the definitions, the architecture, the realistic savings model, example skill files, and the trade-offs that matter in real engineering work.

Economia de Tokens em CLIs de IA: Skills, Dispatch, RTK e Caveman sem Folclore

O desperdício de tokens em um CLI de IA quase nunca parece desperdício no momento em que acontece.

Parece só uma busca grande demais. Um git diff sem filtro. Um log de teste com 800 linhas. Um agente explicando o óbvio em cinco parágrafos antes de tocar no arquivo. Uma skill inteira carregada para uma tarefa que precisava de duas linhas. Um modelo caro respondendo uma tarefa mecânica. Uma sessão longa que se perde porque o contexto ficou cheio de ruído operacional.

Isoladamente, cada evento parece pequeno. Em uma semana de trabalho real, eles viram custo.

O ponto central deste artigo é simples: economia de tokens em CLIs de IA não é uma técnica única. É uma arquitetura de execução.

Você não resolve esse problema apenas escrevendo "seja breve" no final do prompt. Isso ajuda, mas não governa o fluxo inteiro. O ganho aparece quando o stack reduz desperdício em cinco pontos diferentes:

• escolha de instruções;
• escolha de modelo ou agente;
• saída de shell;
• comunicação do assistente;
• armazenamento de contexto pesado fora da janela principal.

Esse é o papel do stack formado por skills-selector, smart-dispatch, rtk, caveman e context-mode.

Não é mágica. Também não é desculpa para comprimir informação crítica. É engenharia operacional aplicada ao uso diário de Claude Code, Codex CLI, Gemini CLI e ferramentas semelhantes.

O que significa economia de tokens em um CLI de IA

Em uma aplicação tradicional de LLM, você costuma pensar em tokens como custo de API: entrada, saída, preço por milhão, latência e limite de contexto.

Em um CLI de IA, tokens têm uma função mais ampla. Eles viram largura de banda operacional.

Cada token usado para carregar uma instrução irrelevante é um token que não pode carregar código importante. Cada token gasto em log repetido reduz espaço para raciocínio sobre o bug. Cada resposta longa demais aumenta latência, custo e risco de a próxima iteração começar com contexto pior.

Em trabalho agentic, token não é só unidade de cobrança. É unidade de atenção.

Um stack eficiente precisa responder quatro perguntas:

1. Qual instrução realmente precisa entrar nesta tarefa?
2. Qual modelo ou agente é suficiente para este tipo de trabalho?
3. Qual saída de ferramenta precisa chegar ao contexto principal?
4. Qual parte da conversa precisa ser completa, e qual pode ser comprimida?

Quando essas perguntas ficam implícitas, o modelo decide no improviso. Quando viram stack, o comportamento fica repetível.

O stack em uma frase

A ordem importa:

skills-selector -> smart-dispatch -> rtk -> caveman -> context-mode

Essa ordem não é estética. Ela segue o caminho do desperdício.

Primeiro você evita carregar instrução errada. Depois evita escolher modelo errado. Depois filtra o que ferramentas devolvem. Depois reduz ruído na resposta do agente. Por fim, tira material pesado da janela principal quando ele precisa existir, mas não precisa ser lido inteiro pelo modelo.

A diferença entre prompt curto e sistema econômico

Muita gente tenta resolver custo com um comando de estilo:

responda curto

Isso melhora a saída do modelo, mas não resolve:

• skill carregada por engano;
• modelo caro usado para tarefa simples;
• git status expandido;
• npm test despejando stack trace duplicado;
• log grande ficando preso na conversa;
• contexto permanente com regras que só importam uma vez por mês.

Economia de tokens séria atua antes, durante e depois da resposta.

Esse diagrama mostra o motivo do ganho composto. Cada componente reduz uma categoria diferente de tokens. Se você usa só um deles, melhora um ponto. Se usa todos com critério, reduz desperdício em várias camadas do workflow.

skills-selector: a skill que impede a biblioteca de skills de virar ruído

skills-selector é uma meta-skill.

O trabalho dela não é resolver a tarefa final. O trabalho dela é decidir qual skill merece entrar no contexto agora.

Isso parece detalhe até você ter 40, 80 ou 120 skills instaladas. Sem curadoria, uma biblioteca de skills vira um novo problema: triggers concorrentes, instruções redundantes, workflows pesados para tarefas pequenas e contexto tomado por material que não participa da decisão.

Uma boa skills-selector faz quatro coisas:

• classifica a intenção principal do usuário;
• mapeia candidatos de skill;
• corta skills caras quando o ganho não justifica;
• emite um plano curto de seleção antes da execução.

O princípio é: skill só entra quando reduz risco real ou melhora o resultado da tarefa atual.

Exemplo de comportamento esperado:

O ganho vem de evitar a falsa sofisticação. Em tarefas simples, o melhor stack é quase nenhum stack.

Exemplo de arquivo skills-selector/SKILL.md

O exemplo completo usado como artefato deste artigo está em examples/skills-selector/SKILL.md. Uma versão reduzida:

---
name: skills-selector
description: Meta-skill que roda primeiro em cada nova tarefa para escolher o menor conjunto de skills necessario.
allowed-tools: Read, Grep, Glob
---

# Skills Selector

## Protocolo

1. Classifique a intencao primaria: build-code, fix-bug, review, docs, content, ops ou trivial.
2. Liste skills candidatas apenas quando reduzem risco ou trabalho real.
3. Corte skills pesadas se a tarefa couber em resposta inline ou poucas chamadas de ferramenta.
4. Emita um bloco curto:

```text
SKILLS: [skill-a, skill-b]
INTENT: content
REASON: artigo + publicacao via MCP
BUDGET: medium
NEXT: ler fonte e criar arquivo
```

## Regras

- Nunca selecione a si mesma.
- Prefira skill de dominio a skill generica.
- No maximo duas skills por turno, salvo pedido explicito.
- Se nenhuma skill ajuda, use `SKILLS: []`.

O ponto não é copiar esse arquivo literalmente. O ponto é capturar o papel de um classificador: antes de trabalhar, decidir qual workflow deve governar o trabalho.

smart-dispatch: economia por escolher o executor certo

smart-dispatch resolve outra camada do problema.

Mesmo com a skill correta, você ainda pode gastar demais se usar o modelo errado. Nem toda tarefa precisa do modelo mais caro, do maior contexto ou de um subagente autônomo. Também nem toda tarefa deve ser empurrada para um modelo barato.

O objetivo do smart-dispatch é responder:

• isso é tarefa mecânica, implementação moderada ou raciocínio arquitetural?
• precisa de multimodalidade?
• precisa de contexto gigante?
• precisa de subagente paralelo?
• é melhor fazer inline?

Esse roteamento reduz custo de duas formas.

Primeiro, evita usar capacidade excessiva para trabalho simples. Segundo, reduz retrabalho causado por escolher um executor fraco demais para uma tarefa complexa.

O erro comum é pensar que economia significa sempre escolher o mais barato. Não significa. Economia significa escolher o menor executor que ainda entrega qualidade suficiente.

Exemplo de arquivo smart-dispatch/SKILL.md

O exemplo completo está em examples/smart-dispatch/SKILL.md. Versão reduzida:

---
name: smart-dispatch
description: Roteia tarefas para o modelo, agente ou provedor adequado por custo, capacidade e risco.
---

# Smart Dispatch

## Matriz

| Tarefa | Caminho |
| --- | --- |
| mecanica | inline ou modelo rapido |
| implementacao padrao | modelo padrao de codigo |
| arquitetura | modelo de raciocinio forte |
| imagem ou UI visual | modelo multimodal |
| contexto acima de 100k tokens | modelo/contexto grande |

## Regras

- Use subagente apenas quando trabalho paralelo reduz caminho critico.
- Nao delegue a proxima tarefa bloqueante.
- Prefira executor barato quando risco e ambiguidade forem baixos.
- Prefira executor forte quando erro custar retrabalho.

Uma boa dispatch policy é uma planilha de trade-offs dentro do workflow. Ela transforma "qual modelo eu uso?" em decisão operacional, não preferência pessoal.

rtk: o proxy que impede o terminal de inundar o contexto

rtk significa Rust Token Killer.

Na prática, ele atua como um proxy para comandos de shell. Em vez de deixar o CLI despejar a saída bruta no contexto do agente, o rtk executa o comando e devolve uma versão filtrada, agrupada ou resumida.

Isso importa porque shell é uma das maiores fontes de desperdício em sessões reais:

• git status repete instruções humanas irrelevantes;
• git diff pode trazer contexto demais;
• testes mostram centenas de linhas antes da falha real;
• linters repetem erros semelhantes;
• listagens de arquivo crescem rápido;
• containers, logs e cloud CLIs tendem a ser verbosos.

Segundo a documentação pública do RTK consultada em 2 de maio de 2026, o projeto declara reduções típicas de 60% a 90% em comandos comuns de desenvolvimento, com estratégias como filtragem, agrupamento, truncamento e deduplicação. Esses números devem ser tratados como estimativas dependentes do projeto, não como garantia universal.

O valor arquitetural do rtk não é só "resumir". É resumir antes de o conteúdo entrar na janela de contexto.

Exemplo:

rtk git status
rtk git diff
rtk pytest
rtk npm test
rtk rg "UserRepository"
rtk gain --history

O comando mais importante para governança é:

rtk gain

Sem medição, economia de tokens vira crença. Com medição, você começa a enxergar quais comandos realmente queimam contexto.