The one thing subagents are for

You asked how session timeouts work in a codebase you did not write. Claude grepped, read session.ts, then timeouts.ts, then four config files, and answered in two paragraphs. The answer was right. But six thousand tokens of file contents now sit in your window and get re-sent with every message for the rest of the session — for two paragraphs you would have been happy to receive on a sticky note.

This level is the first time you hand work to something that is not you. Start with the smallest version of that: subagents are

Delegated workers inside one session that do a side task in their own context and return a summary — Run agents in parallel

Inside one session is what separates this lesson from the rest of the level. Subagents work within a single session and report results back to the conversation that spawned them. One running in the background is not invisible — /tasks lists it and lets you check on, attach to, or stop it. But its findings arrive in your conversation when it finishes, and that is the fact the rest of this lesson turns on.

Delegation is a context decision, not a speed decision

The docs open the subagent page with the use case rather than the mechanism, and the use case is context:

Use one when a side task would flood your main conversation with search results, logs, or file contents you won't reference again: the subagent does that work in its own context and returns only the summary. — Create custom subagents

Note the qualifier: you won't reference again. That is the whole test. Lesson 3.1 established that your window is a budget and that every token in it is paid for on every subsequent turn. A subagent does not stop the files being read, and running one is not free — the docs note that several subagents at once multiply token usage. It moves the reading somewhere you are not paying rent on.

Since context is your fundamental constraint, use subagents to keep research out of it. When Claude researches a codebase it reads lots of files, all of which consume your context. Subagents run in separate context windows and report back summaries — Best practices

The mechanism is stated plainly, and Lesson 8.2 is entirely about its consequences:

Each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions. — Create custom subagents

Which makes a subagent the second of the two documented ways out of the infinite exploration — scope the investigation narrowly, or delegate it so the reading does not consume your main context. Lesson 1.4 builds that failure and both fixes in full. What it does not settle — and what the rest of this lesson is about — is how much of the delegated reading comes back anyway.

What comes back, and what it costs

Be exact about the return value, because everything else follows from it. The context-window walkthrough traces a subagent that researches session timeouts:

Only the subagent's final text response comes back to your context, plus a small metadata trailer with token counts and duration. The subagent read 6,100 tokens of files. You got a 420-token result. That's the context savings. — Context window

Read the third row twice. The saving is not a property of delegating; it is the gap between what was read and what was returned. Six thousand tokens read and four hundred returned saves you most of six thousand. Six thousand read and four thousand pasted back saves you very little, and cost a round trip to get.

The trap: treating subagents as free parallelism

The obvious move once you learn this is to fan out — five subagents, one per module, all at once. The docs flag exactly that shape:

When subagents complete, their results return to your main conversation. Running many subagents that each return detailed results can consume significant context. — Create custom subagents

Parallel research is a documented pattern and works best when the research paths do not depend on each other. But the number that matters is not how many subagents you spawned; it is the total size of what they hand back.

When the main conversation is the right place

The docs give the decision as two lists, not a rule. This is the whole of it:

That last row is the one that catches people who have just learned the trick. The docs spell out why: a subagent that isn't a fork "starts fresh and may need time to gather context" — it re-derives what you already have. For a thirty-second question that is a bad trade. Lesson 8.3 covers forks, which are the exception to that sentence.

There is also a cheaper instrument you already own. Lesson 3.2 introduced /btw, and the subagent page points at it by name: for a question about something already in your conversation, use /btw instead of a subagent. It sees your full context, has no tool access, and the answer is not added to history. If the answer is already in the room, do not send someone out for it.

The built-in agents you already have

You do not have to author anything to start delegating. Claude Code ships several built-in subagents and delegates to them on its own, based on the task description in your request, the description field in subagent configurations, and current context. Three of them account for most of what you will see:

Claude delegates to Explore when it needs to search or understand a codebase without making changes, which is most of the delegating you will see. The denial is a documented property of the agent, not a hopeful instruction in its prompt: Write and Edit are denied. Plan is why Level 4 felt cheaper than it should have — in plan mode, research is delegated to the Plan subagent so exploration output stays in a separate context window while the main conversation remains read-only. You were already using this level's mechanism; you just were not the one who asked.

Scoping the brief so the summary stays small

Two facts about how a subagent is briefed, both of which change what you type.

First, you are not writing the subagent's prompt. Claude writes it from your message, and an @-mention only pins which subagent receives it — Lesson 8.2 quotes that rule and works out the rest of what the brief has to carry. So a request is not a handover. Whatever you want the subagent to be told has to be recoverable from what you said to Claude.

Second, the docs' own example of a good delegation names the report, not the topic:

Use a subagent to run the test suite and report only the failing tests with their error messages

Compare that with "use a subagent to run the tests". Both delegate. Only one constrains the return value, and the return value is the part you pay for. The phrase carrying the weight is report only. It generalises to three clauses:

Lesson 2.3 made the case for pointing at the pattern rather than the outcome. This is the same instinct aimed at a different target: describe the deliverable, because with a subagent the deliverable is the only thing that survives the trip.

Which is the point to leave with. A subagent is not a faster Claude and not a second pair of hands. It is a boundary you draw around a piece of reading, and the brief is where you decide how much comes back across it.