Definition
An agent session can form a tree when one session spawns another. Each child has its own execution record and usage ledger, while the parent typically receives only the child's returned result.
A chat view suggests one line of work: you ask, the agent acts, the agent replies. Delegation breaks that line.
When an agent asks a helper to investigate part of the task, the helper usually gets its own instructions, context, model invocations, tools, and usage. The parent waits—or continues independently—then receives a result. What looks like one conversation is now a tree of sessions.
Open the session tree
Click the nodes — then choose which ones your total includes.
That “one agent” brought friends.
One clean line. But the parent transcript only kept a summary of an entire session somewhere else: “I checked how retry configuration is loaded.”
What is a subagent?
A subagent is an agent run created by another agent run. The parent delegates a bounded task such as exploring a code path, checking documentation, or reviewing a proposed change. The child performs that work and returns a result to the parent.
“Subagent” describes a relationship, not necessarily a different model or capability. The child may use the same model and tools as the parent. What makes it a child is topology: who spawned it and which session receives its result.
Why the parent session doesn’t contain the child’s work
The parent transcript normally records a spawn request and the child’s returned summary. It does not automatically contain every model request, file read, command, failure, and token from inside the child.
A child’s summary is context for the parent. It is not a substitute for the child’s execution record.
That separation is useful. It keeps the parent’s context from absorbing every exploratory detail. It also creates a common accounting mistake: measuring only the parent makes delegated work disappear from totals.
Parent session cost vs. session tree cost
In the specimen, the parent costs $4.63. The child costs $1.12. Both of these statements are correct:
- the parent session cost $4.63
- the complete session tree cost $5.75
The difference is scope.
| Boundary | Includes | Use when asking |
|---|---|---|
| Parent session | Only the parent ledger | How did the coordinating run behave? |
| Session tree | Parent plus every descendant | What did the delegated task consume in total? |
Turns, tool calls, tokens, duration, and cost all need the same boundary. Adding a child’s cost while leaving out its calls produces a hybrid total that describes no real execution scope.
parent_session_id: the field that holds the tree together
A child needs a stable identity and a relationship back to its parent—commonly a parent_session_id, plus information about the spawn event. With that relationship, records can be traversed in both directions:
- from parent to every descendant
- from child to the work that requested it
- from a task-level total to each contributing session
Without linkage, the child still exists. It merely appears as an unrelated top-level session. Similar timestamps and titles may suggest a relationship, but inference is not evidence.
Session trees can be deeper than two levels
A child can spawn another child. Several children can run in parallel. A parent can retry a delegation by creating a second child. The familiar parent-and-helper picture is only the smallest tree.
For a node n, an additive tree total is recursive:
total(n) = own(n) + total(child₁) + total(child₂) + …
This holds for additive metrics: cost, tokens, tool-call count, and invocation count each sum cleanly up the tree. It is reliable only when identity and parentage are captured consistently, and missing one link can detach an entire subtree from the total.
Not every measurement aggregates by addition. Elapsed wall-clock duration is the exception, because child branches can run concurrently and their time overlaps rather than stacks. The next section separates the two.
Parallel subagents: elapsed time vs. aggregate agent time
Costs usually add across branches. Wall-clock duration does not. If two children run at the same time for four minutes, the tree consumed eight agent-minutes but may add only four minutes to elapsed time.
That produces another pair of valid measures:
- elapsed duration: time from the root session’s start to finish
- aggregate agent time: the sum of active duration across all nodes
Use elapsed time to describe user wait. Use aggregate time to describe total execution consumed. A tree makes the distinction visible.
The mental model: sessions are nodes, spawns are edges
Treat each session as a node with its own ledger. Treat each spawn as an edge. The transcript is one view of one node.
When you ask what an agent task did or cost, decide whether you mean the current node or the whole tree. Delegated work is real work even when the parent compresses it into one paragraph.
Why root-session totals undercount delegated work
When only root sessions are measured, the work the agent delegated quietly falls out of the numbers:
- delegated cost is undercounted
- child work disappears from task totals
- ownership and attribution drift away from where the work actually happened
Attributing a task correctly means measuring the whole tree, with the linkage that holds it together.
Sometimes even the session tree is not the whole unit of work: one human intent can span several sessions and several trees. That is a thread for another day.