One session is doing a job too big for it, so you give half to a second session. That part works. What decides whether the arrangement is safe is what happens when the second session reaches the same conclusion you did.
The worked example is Clawdline, our local daemon and web console, which dispatches between local Claude Code and Codex sessions. The argument transfers to anything that can start an agent.
The second dispatch is the one nobody decided
A session that can hand work out will eventually hand out work you never asked about. It is your own reasoning — this is bigger than one context window, split it — applied by something with your tools, your permissions and no view of your bill.
Then the arithmetic. One task becomes five becomes twenty-five, each a real terminal tab running a real assistant against a real API bill. Sixty tabs, with no way to tell which one started it, is an incident rather than a scale problem. So the tree needs a bottom.
A limit in the prompt is one the agent can talk itself out of
Put “do not open more sessions” in a system prompt and the rule holds as long as attention does. Instructions are read by something that can be argued with, distracted, or mistaken about which rule applies. That is not a criticism of any model. It is what instructions are.
Our own records make the point. For months every child session carried 28,000 characters explaining how to dispatch, and across two hundred-odd dispatches not one of them dispatched anything. They could not. A briefing is a good place to explain a rule and a bad place to keep one.
The limit belongs in whatever grants the resource: the thing that opens the tab, holds the API key, spends the budget. Here that is the daemon. A root can open children; a child does one task and opens nothing. A dispatch names who is asking, the task lands one level below that name, and past the floor it is refused before anything is spent. Nor can a caller lie upward: two signals name the asker, and the deeper answer wins.
The floor is a constant in our source, not a value in a settings file. A limit a hand-edit can restore is not a limit.
If you are assembling anything out of agents: which of your limits would survive a session that ignored its instructions? The ones in whatever hands out the process, the key, the tab or the budget. The rest are advice.
No floor
Floor at one
Then the worst case is arithmetic you can do before you install anything
Once the tree cannot grow itself, the worst case stops depending on judgement and becomes a sum. These are the ceilings on our own dispatching, to check against whatever you run today:
| What is bounded | The number | Yours to change |
|---|---|---|
| Children one session may have out at once | Five | Yes, one to ten |
| Children a child may have | None | No — there is no second level and no setting that adds one |
| Dispatched sessions on the whole Mac | Twenty, four roots’ worth | No |
| Dispatches in any ten minutes | Ten, or one full tree’s worth if that is more | No |
| How long one task may run | Four hours at most, thirty minutes by default | Yes, per task |
A shell script that starts agents in a loop has no such number, and neither does a prompt asking for one. The floor bounds how wrong things get.
Fan out at the top, and keep the parallelism inside the task
The floor costs one thing: a session cannot decide halfway through that the job needs four more. Decide at the top instead. Breadth before depth — two children splitting a job beat one that hands half of it on.
A root that opens four sessions holds the plan they were cut out of and can join what they produce. A child that quietly opens a fifth takes over the planning, and the best-placed reviewer is then the session that commissioned it.
Parallel work inside one task is untouched by any of this. It goes to the assistant’s own subagents, Claude Code’s Task tool and Codex’s subagents, which run inside the session that asked, open no tab and hold no depth.
| The assistant’s own subagent | A dispatched session | |
|---|---|---|
| Where it runs | Inside the session that asked | Its own terminal tab |
| Registered with the daemon | No | Yes — task id, secret, timeout, result file |
| Spends a child slot or a level of depth | Neither | Both |
| Where its answer arrives | Back in the conversation | In a file somebody has to wait for |
| Can be watched, typed into, cancelled | No | Yes |
Read that as a routing rule, not a ranking. Anything needed inside the current turn belongs on the left; anything a person might want to watch or take over belongs on the right, and costs a slot.
What the floor does not do
It does not tell you whether to split the work at all, and that is the more common mistake. Work that divides into pieces which need not talk to each other does well with several sessions. Work where each step depends on the last does badly: the handoffs break a chain that needed to stay whole.
It bounds sessions, not writes. A task declares which paths it may write, and a conflicting dispatch is refused at the door. That is a gate, not a lock: nothing stops a running process writing outside what it declared. What that costs is its own post.
It does not notice a session going the wrong way. A task inside every cap can still spend half an hour on the wrong thing. That has a mechanism of its own: a sentence at minute three, before the work rather than during it.
And closing a root has victims. An explicit close cancels the tasks under it; closing the tab by hand does not, because a terminal that briefly lost permission looks the same. One close on 27 August 2026 took four briefed tasks in fourteen seconds.
Work moves the other way too: not a task handed down, but a whole line of work handed to a session that was not there for it. That one is what a handoff carries.