I tested nested subagents in Claude Code
Claude Code now let's you run nested subagents. But is it useful?
Hey 👋,
Claude Code recently shipped support for nested subagents.
If you’re anything like me, the first thing you wonder is what you’d actually use it for. So this week I want to break down how I think about them, and the one pattern I’ve found genuinely useful.
First, what a subagent is, in case you’re new to this. When you have an agent like Claude Code, it can spawn off another agent through a tool call. That new agent runs with a fresh context window, does its work, and reports the result back to the parent. It’s a token-efficient way to work. The classic example is code review. If a coding agent reviews its own work, it’s biased by everything already in its context. Spawn a separate agent with a clean context window to do the review, and you get a more honest look at the code.
Nested subagents take this one step further. A subagent can now spawn its own subagents.
Boris announced the feature with a cap of five levels deep. The change log says the same thing. I went past it. I tested the recursion depth on one of my own projects and got to about thirty levels before I cancelled it, with no obvious guardrail stopping me. I don’t know if that’s a bug or deliberate, but it’s worth knowing, and I’ll come back to why it matters.
The interesting question isn’t how deep you can go. It’s the pattern that’s actually worth using. For me that’s three levels: orchestrator, worker, sub-worker.
The orchestrator sits at level one. Its only job is to manage the workflow. In the demo it fetches a GitHub issue, runs the pipeline, and opens a pull request at the end. It never edits code itself.
The workers sit at level two. These do the actual work. One implements the code, one reviews it, one runs the tests.
The sub-workers sit at level three. These are specialised jobs a worker delegates. In the demo, the code implementer spawned a check runner that ran go vet and go build, and the reviewer spawned a correctness reviewer. So you get a subagent of a subagent, each focused on one part of the problem.
I ran a real ticket through this on a Go project I’m building.
I gave the coordinator the issue number and a prompt telling it to manage the work and never edit code directly. From there I just watched. The code implementer wrote the change. The check runner verified the build. The test runner ran the tests. The reviewer, and its own sub-reviewer, found a handful of warnings and nitpicks, nothing critical. The orchestrator fixed them, re-verified, and opened the pull request.
One principle worth repeating here. Never trust agents. Every time they write code, there’s something to fix. The review step is what catches it, which is exactly why building it into the pipeline matters.
Something else I always do now: get the agents to write their findings into the ticket. When you’re only reviewing agent code, you’re abstracted from the details. So when the agent opens a pull request, I want the review findings and test results written into it. It’s good practice in software generally, and agents are very good at it.
Now the honest evaluation. I love this pattern. The separation of concerns is genuinely useful, and it’s the way I think about coding with agents right now. But it has real costs. This one ticket used 148,000 tokens across six runs and took 21 minutes, with no code edited by me directly. I was running Claude Fable and hit my session limits quickly. The quality is higher, but you pay for it in tokens and time. Everything in software is a tradeoff, and this is another one.
This works in Codex too. Codex doesn’t enable nested subagents by default. You set max_depth in the agents config. Depth 0 is the coordinator, depth 1 is a subagent, depth 2 is a nested subagent. What I like is that you can put a guardrail on it. That’s the thing missing in Claude Code, where I could nest about thirty levels deep with nothing stopping me. That’s dangerous and burns tokens for no reason. If you know the depth setting in Claude Code, tell me in the comments.
So my honest take: use the orchestrator, worker, sub-worker pattern, but don’t go deeper than about three levels. Past that it stops making sense and just gets you into a mess.
I made a full walkthrough with the live demo in both Claude Code and Codex here.
If you want to go deeper on building real software with AI agents, that’s what I’m building inside AI Engineer.
Thanks for reading. Have an awesome day!
Owain