Claude Code subagents: when to delegate and when to open a new session

You ask Claude Code where the rate limiter actually gets configured. Instead of reading forty files into your conversation, it spawns a subagent: a spinner labelled Task ticks away for ninety seconds while something explores the repo off-screen, then four sentences come back with the answer and the three files that matter. Your context window barely moved. It feels like magic.

A week later you hand the same setup a real feature, and the orchestrator cheerfully farms the implementation out to three subagents. Twenty minutes of spinners, a confident summary, and a diff you watched none of get written. The magic feels different now.

Both sessions used the same tool. The difference is what it was asked to hide.

What a Claude Code subagent actually is

A subagent is a second agent your main session spawns to handle a piece of work in its own separate context window. It gets a brief written by the main agent, runs its own tool calls (reads, greps, test runs), and reports back a summary. Then it evaporates.

The key property: none of the subagent's work enters your conversation, only its conclusions do. The forty files it read, the dead ends it chased, the failing command it retried, all of that stays in a context you never see and never pay for again. Your main session receives a paragraph.

That single property explains both when subagents are brilliant and when they quietly hurt you.

Delegation is context management, not extra horsepower

The tempting mental model is "more agents, more speed." The accurate one is narrower: subagents are a way to keep the noisy middle of a task out of your main window.

Long sessions degrade for a mechanical reason: every file read and failed attempt occupies context until the constraint you gave at the start stops being visible. Exploration is the worst offender, because it is high volume and low value once finished. You need the answer; you do not need the eleven files that ruled themselves out.

So the rule of thumb: delegate work whose byproducts you don't need, keep work whose decisions you do. In practice, subagents earn their keep on:

• Codebase archaeology. "How does auth actually flow?" is a perfect subagent job: heavy reading in, one tidy explanation out.
• Wide searches. Hunting a symbol across a monorepo ten ways at once, without ten sets of grep output in your transcript.
• Verification passes. Run the suite, read the failures, report the three that matter. The scrollback stays in the subagent.
• A second opinion. A fresh-context reviewer looking at the diff cold will catch things the agent that wrote it cannot, because it does not share the author's assumptions.

Notice what is missing from that list: the implementation itself.

Where subagents go wrong

The honest section, because aggressive delegation has real costs:

• The work is invisible. You cannot watch a subagent think, steer it when it takes a wrong turn, or interrupt it halfway. With implementation work, the middle is exactly where things go wrong, and a subagent's middle is a spinner.
• You review a summary of a summary. The orchestrator compresses what the subagent claims into what it reports to you. Every hop loses detail, and the detail it loses is precisely what a careful review of agent work exists to catch.
• The brief is written by a model, not by you. When the main agent spawns a worker, it also writes the worker's instructions. Any ambiguity in your original ask gets re-interpreted a second time before code gets written.
• Tokens multiply quietly. Each subagent starts cold and re-reads files the main session already knows. Three subagents exploring the same corner of the repo pay for it three times.

None of these costs matter for a search. All of them matter for a feature.

Subagents or a second session? The actual decision

Here is the test that settles it: if a piece of work deserves its own acceptance criteria, it deserves its own session. Subagents are for subordinate work inside a task. They are the wrong shape for work that is a task.

A task, properly sized, has a brief you wrote, a diff you will read, and a definition of done you can check. Bury it inside another agent's session and you lose all three: the brief gets paraphrased, the diff gets summarized, and "done" gets decided by the orchestrator instead of you.

Running parallel top-level sessions keeps each piece of real work visible, steerable, and individually reviewable. The two patterns compose nicely: three sessions carrying three tasks, each spawning subagents for its own exploration and verification. Delegation inside, accountability outside.

Keeping the visible half organized in SanuDesk

The moment you run the visible half properly, you have several live sessions and a queue of task briefs to manage, and that is the part SanuDesk was built for. It is a desktop app that puts your Claude Code, Codex and Gemini sessions in one tiled grid, so every top-level agent has a pane you can actually watch, next to a Kanban board that does the dispatching: write the task as a card, deploy it to a fresh session with one click, and the card parks itself in a review lane when the agent stops, with a "what changed, how to test it" note attached.

Inside any of those sessions, the agent is free to spawn all the subagents it wants. The board does not care how a card got done; it cares that a human signs off before it counts. Loops handle the recurring jobs on a schedule, it is bring-your-own-model so your existing agent accounts do the work, and the grid and board are in the free plan (details on pricing).

Try this on your next feature

Next time you hand an agent a real task, say this in the brief: "use subagents to explore and to verify, but implement in this session." Then watch the shape of the transcript. The reading happens off-stage, the writing happens where you can see it, and the diff that lands is one you watched being made.

That split, curiosity delegated and accountability kept, is the whole trick.

Download SanuDesk free and give every visible agent a pane and every task a card, or see how the grid, board and Loops fit together on the features page.