Economia de Tokens — Context Window como Recurso Finito

O context window é o recurso mais valioso e mais desperdiçado no desenvolvimento com IA. Quanto mais você coloca no context window, pior ficam os resultados. Isso é contra-intuitivo — mais informação deveria ser melhor. Mas não é.

"You only have approximately 170k of context window to work with. The more you use, the worse the outcomes." — Geoffrey Huntley

Dominar a economia de tokens é o que separa um dev que usa IA de um dev que extrai o máximo da IA.

O problema do context window

Por que mais contexto = pior resultado

1. Atenção diluída — o modelo distribui atenção entre todo o contexto. Quanto mais dados, menos atenção por informação relevante
2. Confusão de prioridades — com muitas specs, regras e código, o modelo perde o que é importante agora
3. Custo crescente — cada token de input custa dinheiro. Contextos inflados = contas infladas
4. Latência crescente — mais tokens = mais tempo de processamento

O tamanho real do context window

O "útil de fato" é onde o modelo mantém qualidade de raciocínio. Depois desse limite, a qualidade degrada silenciosamente.

Estratégias de economia

1. Fresh Context > Compaction

A estratégia mais importante: não tente manter tudo em um contexto. Em vez de compactar, comece de novo.

❌ RUIM: Uma sessão de 5 horas acumulando contexto
  → Context window cheio
  → Modelo "esquece" o início
  → Qualidade degrada sem aviso

✅ BOM: Nova sessão por tarefa
  → Context window limpo
  → Modelo descobre estado do filesystem
  → Qualidade consistente

Por que funciona: modelos como Claude Code são bons em descobrir estado — lendo arquivos, rodando comandos, consultando git. O estado vive no filesystem, não no context window.

2. Uma tarefa por sessão

❌ RUIM:
  "Implemente autenticação, corrija o bug do dashboard,
   adicione testes ao módulo de billing e atualize a docs"

✅ BOM:
  Sessão 1: "Implemente autenticação conforme specs/auth.md"
  Sessão 2: "Corrija o bug do dashboard — veja logs em logs/dashboard.log"
  Sessão 3: "Adicione testes ao módulo billing conforme specs/billing.md"
  Sessão 4: "Atualize docs/api.md com os novos endpoints"

3. Subagentes como workers

Contexto principal (Scheduler):
  → Lê a spec
  → Divide em subtarefas
  → Cria subagentes para cada subtarefa
  → Cada subagent tem SEU context window limpo

Subagent 1: Lê auth.md, implementa POST /register
Subagent 2: Lê auth.md, implementa POST /login
Subagent 3: Lê auth.md, escreve middleware

Regra: subagentes para search/read (paralelo), um agente para build/test (sequencial).

4. State em arquivos, não em memória

Salve progresso em arquivos que o agente lê a cada iteração:

# progress.txt
- [x] Schema de usuários criado
- [x] POST /register implementado e testado
- [ ] POST /login — PRÓXIMO
- [ ] Middleware de auth
- [ ] Testes de integração

# context.md (resumo do projeto)
Stack: Next.js 16 + Go 1.23 + MongoDB
Auth: JWT HS256, 15min expiry, bcrypt cost 12
DB: MongoDB Atlas, collection cms_users
API: Gin framework, port 8080

5. Specs enxutas (< 200 linhas)

❌ RUIM: spec de 500 linhas com toda a API
  → Consome 30% do context window
  → Modelo perde foco

✅ BOM: spec de 150 linhas para um módulo
  → Consome 5% do context window
  → Modelo mantém foco

Divida specs grandes em módulos:

specs/
├── auth-register.md    (120 linhas)
├── auth-login.md       (100 linhas)
├── auth-middleware.md   (80 linhas)
└── auth-refresh.md     (90 linhas)

6. Imports seletivos no CLAUDE.md

❌ RUIM: CLAUDE.md de 500 linhas com tudo
✅ BOM: CLAUDE.md enxuto + @imports seletivos

# CLAUDE.md
## Stack
TypeScript, Next.js 16, Go 1.23

## Commands
pnpm dev, pnpm lint:fix, pnpm build

## Rules
@docs/conventions.md       ← importado só quando necessário
@specs/current-sprint.md   ← importado na sessão relevante

Effort Levels (Anthropic, 2026)

Claude Opus 4.7 introduziu controle granular de esforço computacional:

Regra prática: use xhigh para coding com agentes, high para tarefas moderadas. Evite low em implementações e max em tarefas simples.

Custo real por tipo de tarefa

Estratégia de custo:

• Tarefas simples → Sonnet 4 (barato, rápido)
• Implementação complexa → Opus 4.7 (melhor qualidade)
• Refatoração → Sonnet 4 com fresh context (custo-benefício)

O incidente de qualidade da Claude Code (Abr 2026)

A Anthropic revelou em post-mortem que 3 mudanças no system prompt degradaram a qualidade do Claude Code:

1. Effort default mudou high → medium (4 Mar) — revertido 7 Abr
2. Thinking limpo a cada turno em sessões idle (26 Mar) — causou esquecimento
3. Constraint de verbosidade "≤25 words between tool calls" (16 Abr) — prejudicou qualidade de coding em 3%

Lição: mudanças no system prompt têm efeitos desproporcionais e imprevisíveis. Faça ablações antes de mudar configurações.

Checklist de economia de tokens

• Uma tarefa por sessão (fresh context)
• Specs < 200 linhas por módulo
• Progresso salvo em arquivos (progress.txt, fix_plan.md)
• CLAUDE.md < 100 linhas (usar @imports)
• Subagentes para operações paralelas de leitura
• Effort level adequado à complexidade da tarefa
• Sonnet para tarefas simples, Opus para complexas
• Context nunca ultrapassa 70% do window

Conteúdo Relacionado