Pular para o conteúdo
MÓDULO 3.1

⚖️ Cache vs Compactação

Cache e compactação parecem competir, mas otimizam coisas diferentes: um mexe no preço por token, o outro em quantos tokens você carrega. Quem entende os dois eixos decide certo — e para de pagar contexto gigante turno após turno.

6
Tópicos
~40
Minutos
Avançado
Nível
Decisão
Tipo
1

↔️ Dois eixos diferentes

Cache otimiza o preço por token do contexto. Compactar otimiza quantos tokens você carrega. São dois eixos que não competem no mesmo lugar — e é por isso que você quer os dois.

Compactar = resumir o histórico numa versão menor; no Claude Code, o comando é /compact. Ele não muda o preço por token; ele muda o tamanho do que você reenvia.

preço/token (cache ↓) quantidade de tokens (compactar ←) contexto cheio muitos tokens · 1× cache só cache muitos tokens · 0,1× compactar cache + compacto poucos tokens · 0,1×

Legenda: o cache só desce (preço); a compactação só anda pra esquerda (quantidade). Um não faz o trabalho do outro.

Cache

Mexe no preço por token

Compactar

Mexe na quantidade de tokens

/compact

Resume o histórico no Claude Code

Os dois

Eixos ortogonais, não rivais

2

💰 Contexto grande cacheado ainda é caro

O desconto do cache engana. Cache barateia por token, mas 400k tokens lidos a 0,1× ainda equivalem a ~40k de input cheio por turno — e isso todo turno, enquanto o contexto ficar desse tamanho.

A conta que assusta

400.000 tokens × 0,1× = 40.000 tokens-equivalentes de input cheio, pagos a cada mensagem. O hit alto (99%) não muda isso: o volume é grande.

400k lido @ 0,1× ≈ 40k-equiv / turno
× cada turno da conversa = soma que cresce sem parar
400k @ 1× (sem cache) 400.000 tokens-equivalentes × 0,1 (cache) 400k @ 0,1× (com cache) ≈ 40.000 tokens-equiv / turno — ainda grande

Legenda: um décimo de muito continua sendo muito. Cache aperta o preço; não encolhe o contexto.

Leia a soma, não o campo

Se input_tokens mostra pouco mas a conta veio alta, o grosso está em cache_read_input_tokens a 0,1×. É barato por token, mas o total do prompt é a soma dos três campos.

0,1×

O fator de leitura do cache

40k-equiv

400k lido, todo turno

Todo turno

O custo se repete, não some

Volume

Barato ≠ pequeno

3

🧱 O teto do contexto (1M)

Aqui o cache não ajuda. Ele deixa 900k tokens baratos, mas eles ainda ocupam 900k de 1M. Uma hora você não continua a conversa sem compactar ou /clear. O teto é sobre quantidade — e só compactar/limpar libera espaço.

Janela de contexto = 1.000.000 tokens contexto cacheado (barato, mas grande) 900k ocupados @ 0,1× 100k depois de compactar 20k · janela quase toda livre

Legenda: barato ≠ pequeno. O limite de 1M conta lugares ocupados, não preço — só compactar abre espaço.

O erro comum

Contar com o cache pra "aguentar" um contexto que só cresce. Ele segura o custo, não o tamanho. Perto do teto, a conversa trava — e aí é /compact ou /clear, não mais cache.

1M

Teto de lugares na janela

Barato ≠ pequeno

Cache não abre espaço

/compact

Reduz a ocupação

/clear

Zera quando não precisa do histórico

4

📉 Os números da compactação

Compactar troca um write frio único por turnos muito mais leves. Sem compactar, você paga o contexto grande toda mensagem. Compactando, você paga uma gravação só e todos os turnos seguintes ficam baratos. Veja a conta lado a lado.

CenárioCusto inicial (uma vez)Custo por turnoPayback
Sem compactar
400k no contexto
400k @ 0,1× ≈ 40k-equiv · pra sempre nunca melhora
Compactando
para 20k
1 write frio 20k @ 1,25× ≈ 25k 20k @ 0,1× ≈ 2k-equiv · por turno ~1 turno
Custo por turno (tokens-equivalentes) 0 40k Sem compactar · ~40k/turno pra sempre 25k Compactando · 1 write frio, depois ~2k/turno

Legenda: o único pico ciano (turno 0) é o write frio da compactação; depois dele, cada turno é ~20× mais leve que a barra roxa.

Dica prática

Pense em turnos à frente: se ainda faltam muitas mensagens, o write frio de 25k se dilui em nada perto de economizar 38k por turno. Se a conversa vai acabar agora, o write frio não compensa.

1 write frio

20k @ 1,25× ≈ 25k, uma vez

~2k/turno

Depois de compactar

~1 turno

Payback

~20×

Mais leve por turno

5

🧠 Qualidade e latência

Compactar não é só custo. Contexto inchado espalha a atenção do modelo (o "context rot") — ele erra e enrola mais. E, mesmo lido do cache, 400k levam mais tempo que 20k para o primeiro token (TTFT maior). Compactar melhora precisão e velocidade.

400k — atenção espalhada erra mais · TTFT maior 20k — atenção concentrada acerta mais · responde antes

Legenda: menos tokens = atenção concentrada + primeiro token mais rápido. Compactar é ganho de qualidade, não só de conta.

✓ Contexto compacto

  • Atenção concentrada no que importa
  • Menos "context rot", menos erro
  • Primeiro token mais rápido (TTFT menor)

✗ Contexto inchado

  • Atenção diluída, respostas que enrolam
  • Erros por perder o fio do que importa
  • Mais lento mesmo lido do cache
Context rot

Atenção espalhada em excesso

TTFT

Tempo até o 1º token

Cache ≠ rápido

Lido, mas ainda grande

Dois ganhos

Precisão + velocidade

6

🎯 Quando compactar / quando NÃO

A régua é simples. Conversa pequena → NÃO compacte: você só perde o cache quente sem ganho (essa intuição está certa). Contexto grande, perto do teto ou com qualidade caindo → compacte: você troca 1 write frio único por turnos muito mais leves.

Como está o contexto? tamanho · teto · qualidade conversa pequena NÃO compacte preserva o cache quente grande / no teto / caindo COMPACTE 1 write frio → turnos leves

Legenda: o ramo verde preserva o cache; o ramo roxo aceita 1 write frio pra ganhar em todos os turnos seguintes.

✓ Compacte quando

  • O contexto está grande e ainda faltam muitos turnos
  • Você está perto do teto de 1M
  • A qualidade caiu / o modelo está enrolando

✗ Não compacte quando

  • A conversa é curta e o cache já está quente
  • Vai acabar logo (não há turnos pra pagar o write frio)
  • Por hábito, sem olhar tamanho nem qualidade

Regra de bolso

Compacte pelo estado (tamanho, teto, qualidade), não por relógio. E lembre: cache e compactação trabalham juntos — depois de compactar, o novo contexto pequeno também é cacheado e fica quente de novo.

Pequeno → não

Preserva o cache quente

Grande → sim

Turnos muito mais leves

Pelo estado

Não por hábito

Juntos

Compacto também é cacheado

Resumo do módulo

Dois eixos — cache mexe no preço/token; compactar, na quantidade de tokens.
Cacheado ainda é caro — 400k @ 0,1× ≈ 40k-equiv por turno, todo turno.
O teto de 1M é quantidade — só compactar//clear libera espaço.
Compactar paga rápido — 1 write frio (~25k), payback em ~1 turno, depois ~2k/turno.
Melhora qualidade e latência — menos context rot, TTFT menor.
A régua — pequeno não; grande/no teto/caindo, sim.

Próximo módulo

3.2 — Arquitetura pró-cache e auditoria: desenhar o prefixo pra ele nunca invalidar sem querer.