Toda sessão do Claude Code tem um limite de tokens — a janela de contexto. Tudo que você digita, tudo que o modelo responde, cada arquivo lido, cada busca feita: tudo ocupa um pedaço dessa janela. Quando ela enche, o modelo começa a esquecer o começo da conversa. Usar um subagente não é sobre fazer duas coisas ao mesmo tempo — é sobre evitar que a leitura bruta envenene o seu contexto antes da hora.
↑ Sem subagente: a leitura bruta consome 90% da janela. Com subagente: apenas o resumo entra — contexto livre para o que importa.
Conteúdo detalhado
📏 A janela de contexto: tokens, status line e %
Cada sessão do Claude Code tem um orçamento de tokens. A status line — aquela barra no rodapé do terminal — mostra em tempo real quanto desse orçamento você já consumiu. Quando chega perto do limite, o modelo começa a "esquecer" as partes mais antigas da conversa. Não existe compra de tokens extras no meio do caminho.
📊 O que ocupa tokens
Read ou Grep injeta o conteúdo bruto na janela — e fica lá.maestro · Opus ──────────────────────────────────── ctx 18% ↑cost $0.04
# leu 3 arquivos? ctx sobe para 34%
# leu 40 arquivos? ctx vai para 87% — quase no limite
# enviou subagente ler 40 arquivos? ctx fica em 18%
🚰 Poluição: tudo que você lê fica a sessão toda
Este é o ponto que a maioria ignora: no Claude Code, quando você pede para ler um arquivo, o conteúdo bruto entra na sua janela e fica lá. Ele não sai quando a leitura termina. Ele não some quando você muda de assunto. Só some quando a sessão encerra. Isso significa que ler 50 arquivos no meio de uma tarefa longa pode consumir a janela inteira antes de você chegar na parte que importa.
Você pede "leia estes 10 relatórios"
O modelo usa a ferramenta Read dez vezes.
Cada chamada injeta o texto bruto na janela. 10 relatórios de 5 páginas = ~50k tokens consumidos num piscar de olhos.
O conteúdo bruto fica na janela
Mesmo depois de o modelo "ter lido".
O Claude já processou a informação — mas o texto das páginas 1-50 continua ocupando slot na janela. É como manter 50 abas abertas que você não vai mais usar.
A janela enche antes da parte importante
O modelo começa a esquecer.
Com 90% da janela ocupada por leitura bruta, não sobra espaço para as instruções do final — e o modelo pode "esquecer" o objetivo original da sessão.
⚠️ A armadilha invisível
Você não percebe que está poluindo porque o modelo ainda responde bem por um tempo. O problema aparece só no final: quando você precisa de uma análise complexa e a janela já está quase cheia de leitura descartável. Nesse ponto, não tem como recuperar — a sessão está comprometida.
⚖️ Fazer você mesmo × enviar subagente
Às vezes você mesmo deve ler o arquivo — quando a leitura é rápida e você vai precisar raciocinar sobre ela logo em seguida. Mas quando a leitura é pesada, ampla ou descartável (você só quer a conclusão), enviar um subagente protege a sua janela. A distinção é simples: vai sobrar algo útil na minha janela depois que eu ler isso?
✓ Use subagente quando
- ✓Leitura pesada: muitos arquivos, logs longos, PDFs volumosos
- ✓Você só precisa da conclusão (não do texto bruto)
- ✓Busca na web com retorno de páginas inteiras
- ✓Tarefa repetível que não depende do contexto atual
✗ Faça você mesmo quando
- ✗É um único arquivo curto que você vai referenciar logo depois
- ✗A tarefa exige o histórico inteiro da conversa
- ✗A decisão depende do contexto que só o maestro tem
- ✗A leitura é a tarefa em si — não há "resumo a extrair"
💡 A pergunta de ouro
Antes de mandar o Claude ler qualquer coisa pesada, pergunte: "Eu vou precisar relê-la no contexto ou só da conclusão?" Se a resposta for só da conclusão, envie um subagente. Simples assim. Esse filtro sozinho evita 80% das sessões comprometidas.
📬 O resumo limpo que volta ao maestro
O subagente faz a leitura pesada na janela dele — que é separada, descartável, e some quando ele termina. O que volta para o maestro é apenas a saída estruturada que você pediu: 3 fatos, 1 parágrafo, uma lista de caminhos, um número. Nada do texto bruto que o subagente leu chega na sua janela.
📊 O que "volta" vs. o que "ficou lá"
Ficou na janela do subagente (descartado)
- ✗O texto bruto dos 300 PDFs
- ✗Resultados intermediários das buscas
- ✗Erros e tentativas de leitura
- ✗Tokens de raciocínio interno
Chegou na sua janela (o que importa)
- ✓A conclusão: "X aconteceu em 18% dos contratos"
- ✓Os caminhos relevantes: ["doc/contrato-12.pdf", …]
- ✓Flags explícitos: "cláusula de rescisão ausente em 4"
💡 Formatar a saída é parte do briefing
O subagente vai devolver exatamente o que você pedir. Se você escrever "devolva no máximo 3 bullets com o que encontrou", ele devolve 3 bullets. Se você escrever "devolva o JSON com os campos X, Y, Z", ele devolve JSON. A compactação do resumo é controlada por você no briefing — não é magia, é instrução.
🏆 Por que contexto limpo bate velocidade
Falar que subagentes são "mais rápidos" é tecnicamente verdade para leituras em paralelo — mas é o motivo errado para usá-los. Um subagente serial (um de cada vez) ainda assim protege a janela. A razão nº 1 é qualitativa: uma sessão com contexto limpo raciocina melhor, comete menos erros de "esquecimento" e pode continuar até o fim sem degradação.
⚡ Velocidade (motivo secundário)
- →Paralelismo reduz tempo total quando há múltiplos subagentes
- →Mas um único subagente serial não é mais rápido que o maestro fazendo ele mesmo
- →Latência de iniciar o subagente pode até aumentar o tempo total em tarefas pequenas
🧠 Contexto limpo (motivo nº 1)
- ✓O maestro raciocina sobre o problema, não sobre os dados brutos
- ✓Sessão longa não degrada — a janela nunca enche de lixo descartável
- ✓Respostas do maestro mantêm coerência do início ao fim da tarefa
📊 Dados que ajudam a internalizar
- →Um arquivo típico de código ocupa ~2–5k tokens. Ler 40 arquivos = 80–200k tokens a mais na janela.
- →Com um subagente reader, esses 200k ficam na janela dele — na sua janela entra só o resumo de ~500 tokens.
- →Economia potencial: 99,75% do custo de contexto nessa leitura específica.
📚 Caso concreto: 300 páginas → 3 fatos
O caso mais expressivo do curso: você tem 300 páginas de relatórios financeiros e precisa de
3 fatos para a sua apresentação de amanhã. Se o maestro ler os 300
documentos, a janela explode. Se um researcher (Haiku) ler tudo na janela
dele e devolver apenas os 3 fatos, a sua janela não sai de 15%.
🔢 Os números do caso
Exemplo real: o subagente researcher
O researcher é o subagente arquétipo de proteção de contexto: usa
Haiku (barato e rápido), só lê (sem escrever, sem executar), e é
explicitamente instruído a devolver apenas o resumo. É o modelo que você
vai replicar para qualquer tarefa de "leitura pesada → conclusão compacta".
--- # frontmatter: configuração do subagente
name: researcher
description: Pesquisador de contexto limpo. Use quando precisar
ler muitos arquivos ou buscar na web e só quiser a
conclusão — não o conteúdo bruto. Mantém a janela
do maestro quase intacta.
tools: Read, Grep, Glob, WebSearch, WebFetch
model: haiku # barato e rápido para leitura volumosa
---
# corpo: o comportamento do researcher
You are a research assistant focused on context efficiency.
Primary rule: Never return raw file content or raw web pages.
Always distill. Your output must be ≤ 10% of what you read.
When invoked:
1. Understand what facts the orchestrator needs.
2. Read or search as much as needed (your context, not theirs).
3. Identify only the facts that answer the question.
4. Return a structured summary: bullets, JSON, or a short paragraph.
Output contract:
- Max 5 bullets OR 1 short paragraph OR 1 JSON object.
- Include file paths or URLs as references, not content.
- If nothing found, say so in ≤ 2 sentences.
Do not: paste raw file content · return full web pages ·
exceed the output contract · ask clarifying questions.
⚙️ Por que cada escolha importa
- Haiku — o mais barato: leitura pesada não precisa de raciocínio profundo.
- Read+Grep+Web — só leitura: sem risco de escrever ou executar acidentalmente.
- "≤10% do que leu" — a regra numérica que ancora o output contract.
- Sem perguntas — o researcher não interrompe o maestro no meio da tarefa.
🧩 Quando acionar este agente
- →"Vasculhe os logs de erro das últimas 2 semanas"
- →"Leia os 8 PRDs e me diga quais mencionam 'autenticação'"
- →"Pesquise na web o estado da arte em RAG e me traga 5 bullets"
- →"Varra a codebase buscando todos os TODO e categorize"
Prompts prontos (copie e cole)
Use estes prompts para delegar pesquisa pesada ao researcher e manter
a sua janela limpa. Repare no padrão: pedir explicitamente
só a conclusão e especificar o formato de saída.
Use o researcher pra varrer os PDFs em docs/contratos/
e me trazer só os 3 contratos que mencionam "rescisão
unilateral". Devolva: nome do arquivo + trecho exato (1 linha).
Não cole o conteúdo completo aqui.
Abra o researcher e peça para ele pesquisar na web
"Claude Code subagent best practices 2025" e me trazer
5 bullets com as principais recomendações. Sem colar
páginas inteiras — só a síntese.
Use o researcher pra varrer toda a codebase buscando
chamadas a `fetch()` sem tratamento de erro. Devolva
em JSON: { "arquivo": "...", "linha": N, "trecho": "..." }
para cada ocorrência. Não cole o código dos arquivos.
Tela simulada: researcher lendo 300 páginas
Veja como a status line do maestro quase não se move enquanto o
researcher consome a leitura pesada. O maestro fica livre para raciocinar.
↑ Recriação ilustrativa do terminal (não é screenshot real). Researcher consome 204k tokens na janela dele; o seu contexto fica em 14%.
Exercício: estime os tokens poupados
Pegue uma tarefa real do seu dia — algo que você já pediu ao Claude e que envolveu leitura de vários arquivos. Calcule (de forma estimada) quantos tokens a mais teriam entrado na sua janela se você tivesse feito sem subagente.
Como fazer (3 passos)
- Escreva a tarefa: ex. "ler os logs de deploy da semana (8 arquivos, ~600 linhas cada)".
- Estime o tamanho bruto: nº de arquivos × linhas médias × ~4 (tokens por linha) = tokens se o maestro lesse.
- Estime a saída do subagente: quantos bullets ou linhas você realmente precisaria como resposta? Multiplique por 4. Essa é a saída que entraria na sua janela com o researcher.
✅ Critério de verificação
Você acertou se:
- →Calculou o token-count bruto (entrada) e o token-count do resumo (saída) separadamente.
- →A diferença entre os dois é maior que 10× (lembrete: a regra do researcher é "≤10% do que leu").
- →Consegue dizer em qual % da janela o maestro ficaria — e isso te preocupa ou não preocupa.
Bonus: se a tarefa não tivesse leitura pesada o suficiente para justificar um subagente, a resposta correta é "não valeria a pena delegar" — e isso também conta como acerto.
Exemplo resolvido
Tarefa: "ler os logs de deploy da semana" — 8 arquivos × 600 linhas × 4 tok ≈ 19.200 tokens brutos se o maestro lesse. Resumo útil: 5 linhas de erro + 2 linhas de conclusão ≈ 28 tokens com o researcher. Economia: 99,85%. O maestro ficaria em ~20% da janela com a leitura bruta — já preocupante para uma sessão longa. Vale delegar.
✅ Resumo do módulo
Próximo módulo:
1.3 — Agente × Subagente × Skill. As três primitivas, suas diferenças e quando escolher cada uma.