MÓDULO 1.2

🔄 A Releitura a Cada Mensagem

Por que o custo cresce em curva e não em linha reta. Como o prompt caching muda o jogo (economia de até 10×), e o que você precisa fazer para não quebrá-lo.

6
Tópicos
35
Minutos
Básico
Nível
Teoria
Tipo
1

🏗️ Transformers não têm memória

Entre uma chamada e outra, o Claude esquece tudo. Não existe estado persistente interno — cada requisição é autossuficiente. Para "continuar a conversa", a aplicação (Claude Code) envia todo o histórico de volta, toda vez.

Como o Claude recebe 3 turnos consecutivos

TURNO 1 ~5k tokens
[system] + [CLAUDE.md] + [user_1]
TURNO 2 ~11k tokens (+6k)
[system] + [CLAUDE.md] + [user_1] + [assistant_1] + [user_2]
TURNO 3 ~18k tokens (+7k)
[system] + [CLAUDE.md] + [user_1] + [assistant_1] + [user_2] + [assistant_2] + [user_3]

Cada turno processa tudo que veio antes mais o novo par user/assistant. Essa é a razão estrutural do crescimento do custo.

🧠Implicação prática

"Lembrar" para o Claude significa anexar de volta no próximo turno. Pedir "lembre-se disso" sem que "isso" esteja visível é pedido vazio.

É por isso que o CLAUDE.md funciona: ele é re-carregado automaticamente. É por isso que um handoff estruturado funciona: ele reanexa o essencial em nova sessão.

2

📈 A curva de custo

Se cada turno relê tudo que veio antes, o custo de input cresce como uma soma progressiva. Isso produz uma curva que desarma muita gente.

Input acumulado por turno (sessão média, sem cache)

Turno Enviado Acumulado Custo turno (Sonnet)
15k5kUS$ 0,015
520k60kUS$ 0,060
1040k225kUS$ 0,120
2080k850kUS$ 0,240
30130k1,95MUS$ 0,390

Os últimos 10 turnos custam mais que os primeiros 20 somados.

📊Regra quadrática

O custo total de uma sessão é ~proporcional ao quadrado do número de turnos, não linear. Dobrar o tamanho da sessão quadruplica o custo.

Sessão de 10 turnos
~US$ 0,50
Sessão de 20 turnos
~US$ 2,00
Sessão de 40 turnos
~US$ 8,00

💡Moral

Duas sessões de 15 turnos custam menos da metade de uma de 30. Esta é a base matemática para a regra de ciclos curtos da Trilha 2.

3

💾 Prompt caching — o alívio

A Anthropic sabe que a releitura é cara. A resposta oficial é o prompt caching: quando partes do prompt se repetem, o servidor armazena o resultado do processamento e cobra apenas 10% do preço ao reutilizar.

❌ Sem cache (preço cheio)

50k tokens de baseUS$ 0,15
× 20 turnos
Total de inputUS$ 3,00

✅ Com cache bem usado

1ª escrita (1,25×)US$ 0,19
19 reads (0,1×)US$ 0,29
Total de inputUS$ 0,48
Economia
~6×
no mesmo exemplo de 20 turnos sobre 50k de base

Preço do cache oficial (Anthropic)

Operação TTL 5 min TTL 1h
Escrever no cache1,25× input2,0× input
Ler do cache0,1× input0,1× input

5 min é o padrão. 1h funciona sem beta header desde 2025.

Boa notícia: o Claude Code faz sozinho

Você não precisa configurar nada manualmente. O Claude Code já aplica caching automaticamente no system prompt e histórico. Sua responsabilidade é não quebrar o cache — e é disso que falam os próximos tópicos.

4

🎯 Como maximizar cache hits

O cache funciona por prefixo exato. Qualquer mudança no meio invalida tudo depois. A estratégia é simples: estático primeiro, dinâmico por último.

Estrutura de prompt que maximiza cache

🧱
1. System prompt (muito estável)
Raramente muda entre turnos
cache ✓
📘
2. CLAUDE.md + skills estáveis
Mudam entre sessões, não no meio
cache ✓
📄
3. Arquivos do projeto
Estáveis enquanto não forem editados
cache ~
💬
4. Histórico da conversa
Cresce a cada turno
parcial
✏️
5. Sua mensagem atual
Sempre nova
sem cache

✓ Hábitos que protegem o cache

  • CLAUDE.md curto e estável — edite entre sessões
  • Anexar arquivos grandes uma vez, não repetidamente
  • Manter MCPs fixos durante a sessão
  • Skills fixas — não ativar/desativar no meio

✗ Ações que quebram o cache

  • Editar CLAUDE.md no meio da sessão
  • Ativar/desativar MCPs em runtime
  • Adicionar timestamp dinâmico no system
  • Mudar a ordem de arquivos entre turnos
5

⚠️ O que quebra o cache

Você pode estar pagando preço cheio sem saber. Estas são as armadilhas mais comuns — e o jeito de detectar cada uma.

1

TTL expirou

Cache de 5min vence se você ficar muito tempo sem mandar mensagem. Próxima chamada re-escreve tudo.

→ Se vai pausar bastante, usar TTL de 1h pode compensar.

2

Edição no prefixo

Mexeu no CLAUDE.md, trocou MCP ativo, editou um arquivo já lido. Cache a partir daquele ponto é invalidado.

→ Planeje edições de configuração entre sessões, não dentro.

3

Conteúdo dinâmico no topo

Data/hora atual, IDs gerados, qualquer coisa que muda a cada chamada. Se estiver no prefixo, mata o cache.

→ Conteúdo dinâmico sempre no final do prompt.

4

Mudança de modelo

Cache é por modelo. Trocar de Sonnet para Opus re-escreve tudo.

→ Escolha o modelo antes de abrir a sessão e mantenha.

6

🧮 Exemplo de cálculo real

Um projeto real: refatoração de um módulo de 1500 linhas. 25 turnos de conversa. Contexto médio de 60k tokens (CLAUDE.md + arquivos + histórico). Vamos ver a conta de 3 formas.

Cenário A
Sem cache
Input total1,5M
Output total~50k
CustoUS$ 5,25
Cenário B
Cache automático
Write (base)60k × 1,25
Reads24 × 0,1
Output~50k
CustoUS$ 1,80
Cenário C
Ciclos curtos + cache
2 sessões de 122× write
Context menor~35k
Output~50k
CustoUS$ 0,85
Economia A → C
~6×

Mesmo trabalho. Mesma qualidade. 1/6 do custo.

🎯O que fez a diferença

  • Cache automático do Claude Code (A → B):
  • Dividir em 2 sessões curtas reduz input médio (B → C):
  • Combinação: — e é o mesmo trabalho

📋Resumo do Módulo

Transformers não têm memória — cada turno reenvia tudo
Custo é quadrático — 2× turnos ≈ 4× custo
Cache cobra 0,1× — economia de até 10×
Estável antes, dinâmico depois — a regra de ordenação
Editar em runtime quebra cache — configure antes de abrir sessão
6× de economia é real — no exemplo concreto, com hábitos certos

Próximo módulo:

1.3 — 🍂 Context Rot: O Apodrecimento

Por que a qualidade cai antes mesmo do limite de tokens.