Every Claude Code session has a token limit — the context window. Everything you type, everything the model responds, every file read, every search made: it all takes up part of that window. When it fills up, the model starts to forget the beginning of the conversation. Using a subagent isn’t about doing two things at once—it’s about avoid letting raw reading poison your context ahead of time.
↑ Without a subagent: the raw reading consumes 90% of the window. With a subagent: only the summary goes in — context stays free for what matters.
Detailed content
📏 The context window: tokens, status line, and %
Each Claude Code session has a token budget. A status line — that bar at the bottom of the terminal shows in real time how much of this budget you’ve used. As you approach the limit, the model starts to “forget” the oldest parts of the conversation. You can’t buy extra tokens midway through.
📊 What takes up tokens
Read or Grep injects the raw content into the window — and it stays there.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%
🚰 Pollution: everything you read stays for the entire session
This is the point most people miss: in Claude Code, when you ask it to read a file, the raw content enters your context window and stays there. It doesn't leave when reading is done. It doesn't disappear when you change the subject. It only disappears when the session ends. That means reading 50 files in the middle of a long task can consume the entire context window before you get to the part that matters.
You ask, “read these 10 reports”
The model uses the tool Read ten times.
Each call injects the raw text into the window. 10 five-page reports = ~50k tokens consumed in the blink of an eye.
The raw content stays in the window
Even after the model has “read it.”
Claude has already processed the information — but the text of pages 1–50 still takes up space in the context window. It’s like keeping 50 tabs open that you won’t use again.
The window fills up before the important part
The model starts to forget.
When 90% of the context window is occupied by raw reading, there's no room left for the instructions at the end — and the model may "forget" the session's original goal.
⚠️ The invisible trap
You don’t notice that you’re adding clutter because the model still responds well for a while. The problem only shows up at the end: when you need a complex analysis and the context window is nearly full of disposable reading. At that point, there’s no way to recover—the session is compromised.
⚖️ Do it yourself × send a subagent
Sometimes you should read the file yourself — when reading it is quick and you’ll need to reason about it right afterward. But when reading it is heavy, broad, or disposable (you only want the conclusion), sending a subagent protects your window. The distinction is simple: will anything useful remain in my window after I read this?
✓ Use a subagent when
- ✓Heavy reading: many files, long logs, large PDFs
- ✓You only need the conclusion (not the raw text)
- ✓Web search with full-page results
- ✓Repeatable task that doesn’t depend on the current context
✗ Do it yourself when
- ✗It’s a single short file that you’ll reference right afterward
- ✗The task requires the entire conversation history
- ✗The decision depends on context only the conductor has
- ✗Reading is the task itself—there’s no "summary to extract"
💡 The golden question
Before asking Claude to read anything heavy, ask: "Will I need to reread it in context, or is the conclusion enough?" If the answer is only the conclusion, send a subagent. It’s that simple. This filter alone prevents 80% of compromised sessions.
📬 The clean summary that goes back to the maestro
The subagent does the heavy reading in the its window — that it is separate, disposable, and disappears when it finishes. What returns to the conductor is only the structured output that you asked for: 3 facts, 1 paragraph, a list of paths, a number. None of the raw text the subagent read reaches your context window.
📊 What “comes back” vs. what “stays there”
Stayed in the subagent window (discarded)
- ✗The raw text from the 300 PDFs
- ✗Intermediate search results
- ✗Errors and read attempts
- ✗Internal reasoning tokens
It reached your window (what matters)
- ✓The conclusion: "X happened in 18% of contracts"
- ✓The relevant paths: ["doc/contrato-12.pdf", …]
- ✓Explicit flags: "termination clause missing in 4"
💡 Formatting the output is part of the brief
The subagent will return exactly what you ask for. If you write "return at most 3 bullets with what you found," it returns 3 bullets. If you write "return the JSON with fields X, Y, Z," it returns JSON. Summary compression is controlled by you in the briefing — it's not magic, it's an instruction.
🏆 Why clean context beats speed
Saying that subagents are "faster" is technically true for parallel reads — but it's the wrong reason to use them. A serial subagent (one at a time) still protects the context window. The reason #1 is qualitative: a session with clean context reason more carefully, makes fewer “forgetting” mistakes and can continue to the end without degradation.
⚡ Speed (secondary reason)
- →Parallelism reduces total time when there are multiple subagents
- →But a single serial subagent isn’t faster than the orchestrator doing it itself
- →The latency of starting a subagent can even increase the total time for small tasks
🧠 Clean context (reason #1)
- ✓The orchestrator reasons about the problem, not the raw data
- ✓Long sessions don't degrade — the window never fills up with disposable junk
- ✓The orchestrator’s responses remain consistent from start to finish of the task
📊 Data that helps with internalization
- →A typical code file takes ~2–5k tokens. Reading 40 files = 80–200k more tokens in the context window.
- →With a reader subagent, those 200k stay in its context window — your window gets only the ~500-token summary.
- →Potential savings: 99.75% of the context cost for this specific read.
📚 Real-world case: 300 pages → 3 facts
The course’s most compelling use case: you have 300 pages of financial reports and need to
3 facts for your presentation tomorrow. If the orchestrator reads all 300
documents, the context window will blow up. If an researcher (Haiku) read everything in its window
and return only the 3 facts, your window stays at 15%.
🔢 The case numbers
Real example: the subagent researcher
O researcher is the archetypal context-protection subagent: it uses
Haiku (cheap and fast), only reads (without writing or executing), and is
explicitly instructed to return only the summary. It's the model you'll
replicate for any "heavy reading → concise conclusion" task.
--- # 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.
⚙️ Why each choice matters
- Haiku — the cheapest option: heavy reading doesn't require deep reasoning.
- Read+Grep+Web — read-only: no risk of accidentally writing or executing.
- "≤10% of what it read" — the numerical rule that anchors the output contract.
- No questions — the researcher doesn't interrupt the orchestrator mid-task.
🧩 When to invoke this agent
- →"Search the error logs from the last 2 weeks"
- →"Read the 8 PRDs and tell me which ones mention 'authentication'"
- →"Research the state of the art in RAG on the web and give me 5 bullets"
- →"Scan the codebase for all TODOs and categorize them"
Ready-made prompts (copy and paste)
Use these prompts to delegate heavy research to researcher and keep
your window clean. Notice the pattern: explicitly asking for
only the conclusion and specify the output format.
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.
Simulated screen: researcher reading 300 pages
See how the status line of orchestrator barely moves while the
researcher handles the heavy reading. The orchestrator is free to reason.
↑ Illustrative recreation of the terminal (not a real screenshot). Researcher consumes 204k tokens in its own window; your context stays at 14%.
Exercise: estimate the tokens saved
Take a real task from your day—something you’ve already asked Claude to do that involved reading several files. Calculate (as an estimate) how many extra tokens would have entered your context window if you had done it without a subagent.
How to do it (3 steps)
- Write the task: e.g., "read this week's deploy logs (8 files, ~600 lines each)".
- Estimate the raw size: number of files × average lines × ~4 (tokens per line) = tokens if the maestro read them.
- Estimate the subagent's output: how many bullets or lines would you actually need in the answer? Multiply by 4. That's the output that would enter your context window with the researcher.
✅ Verification criteria
You got it right if:
- →Calculated the raw token count (input) and the summary token count (output) separately.
- →The cost difference between the two is greater than 10× (reminder: the researcher's rule is "≤10% of what it read").
- →Can say what percentage of the window the orchestrator would use—and whether that concerns you.
Bonus: if the task didn't involve enough reading to justify a subagent, the correct answer is "wouldn't it be worth delegating" — and that also counts as a success.
Solved example
Task: "read the deploy logs from the week" — 8 files × 600 lines × 4 tok ≈ 19,200 raw tokens if the orchestrator were to read it. Useful summary: 5 lines of errors + 2 lines of conclusions ≈ 28 tokens with the researcher. Savings: 99.85%. The orchestrator would be at ~20% of the window with the raw read—already concerning for a long session. Worth delegating.
✅ Module summary
Next module:
1.3 — Agent × Subagent × Skill. The three primitives, how they differ, and when to choose each.