[Bug]: Orchestrator V2 shows no token usage for subagents #15429

Activity

1. juliusmarminge commented on Oct 4, 2026

   

   juliusmarminge

   on Oct 4, 2026 – with Cursor

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks @jlipworth for tracing this through the contracts. I confirmed it on current main (f90b77d809). It's a separate gap from #15214 (subagent effort) and #15250 (Codex model label): this one is token usage.

   What I found

   Lineage rows and SubagentTooltipContent show title, model, status and duration, with no slot for tokens. The usage never reaches the client:

   • OrchestrationV2Subagent has no usage field.
   • projectedSubagentsToRuntime sets usage: null. RuntimeSubagent still has SubagentUsage, but the web UI doesn't read it.
   • Claude's task_progress handler keeps description and drops usage, and task_notification keeps summary and drops usage too. The SDK's usage object is { total_tokens, tool_uses, duration_ms }, and the recorded subagent fixture in this repo carries it.
   • Subagent tokens also stay off the parent's context meter, and Claude child threads don't show one either.

   The Agents panel that showed <n> tok, group totals and Σ <n> tok was removed in #12835, which matches what you saw between 0.0.45 and the 0.0.46 nightlies.

   A caveat about the old numbers

   #14003 found that Claude's usage.total_tokens is the subagent's latest context size, not a lifetime total. It can drop after compaction, and the old Σ added those snapshots together. Closed PR #14223 explored splitting context tokens from cumulative tokens. So copying total_tokens straight back into a tok column would likely bring #14003 back.

   Likely fix area

   Whether lineage should show usage at all is a product call. If it does, some options:

   • For Claude, carry task_progress / task_notification usage through OrchestrationV2Subagent and show it as context occupancy rather than a summable total. The tool-use count could come from the same object.
   • Codex and OpenCode already record turn tokenUsage on the child provider turn, but it isn't copied onto OrchestrationV2Subagent, so those providers would need their own mapping.

   For now, Codex and OpenCode child threads show their own context meter once you open them. Claude child threads and the lineage list don't.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 4, 2026
3. jlipworth commented on Oct 4, 2026

   

   jlipworth

   on Oct 4, 2026

   Author

   More actions

   Thanks for the triage. One clarification on what's being asked: the missing piece is how many tokens a subagent run consumed, not context occupancy.

   Before / after

   • Through 0.0.45: the Agents panel showed <n> tok on each subagent row (plus tool-use count when known), a per-group total, and a Σ <n> tok footer. You could see what each subagent cost without leaving the parent thread.
   • 0.0.46 nightlies (V2): none of that appears anywhere. The Lineage rows, the subagent tooltip, the child thread and the parent's context meter all lack it. The child thread's meter, when shown, is context occupancy, which doesn't answer "how much did this run use".

   The data already exists for Codex

   V2 records per-run consumption on each child provider turn as turnTokenUsage (input/cached/output), separate from tokenUsage.usedTokens. A real example from my local statev2.sqlite: a parent thread that spawned six gpt-6-luna subagents.

   Thread	Input (cached)	Output	Peak context
   6 subagents combined	3.11M (2.82M)	102k	~40–49k / 258k each
   Parent	973k (898k)	5.3k	~48k / 258k

   So the subagents were about three-quarters of the run's input tokens, and none of it is visible in the UI.

   Because these are per-run cumulative totals rather than context snapshots, summing them shouldn't reintroduce #14003. The Claude path would still need the snapshot-vs-cumulative care you described.
4. fixfon commented on Oct 4, 2026

   

   fixfon

   on Oct 4, 2026

   Contributor

   More actions

   Another data point for the product call, this time from a Claude thread: what one run consumed, and what V2 already receives about it.

   Setup. macOS desktop 0.0.46 nightly (2648, updated to 2652 during the run), Claude Code 2.1.289, Agent SDK 0.3.276. A Claude Fable 5.1 parent at xhigh ran one long phase over about 12.5 hours and launched 65 subagents with the Agent tool: 51 Opus 5.5 at high, 2 Opus 5.5 at xhigh, 12 Sonnet 5.5 at high. Sources: statev2.sqlite, the thread's provider event log, and the message.usage fields of the Claude Code transcripts (metadata only). The CLI emits one assistant message per content block, so every figure below takes the last usage per message.id.

   As a check on that method, the parent's 183 turnTokenUsage rows in statev2.sqlite sum to the same input and output totals as its own transcript, to the token.

   Where the tokens went.

   	Parent (183 turns)	65 subagents (3,376 requests)
   Input, including cache reads and writes	204.7M	959.8M
   Output	0.5M	3.5M
   Total	205.2M	963.3M

   Subagents account for 82% of this thread's tokens and 88% of its output. None of it is visible. The child threads have no provider turns and no contextUsage, and the subagent records have no usage field.

   Context occupancy answers a different question. For the 61 subagents that sent a final task_notification, its usage.total_tokens matches the subagent's last request context within 1%, as #14003 found. Those values sum to 14.9M, while the same subagents processed 954.2M. The median subagent processed 25 times its final context. The largest one ended at 899K context after processing 191.2M. #15446 is right to show that number as context and not to add it up. It still doesn't say what a subagent cost.

   What V2 already receives. The provider log for this thread has 6,329 assistant messages from subagents (parent_tool_use_id set), all carrying message.usage, with 3,376 distinct ids, the same request count as the transcripts. Summing the last usage per id gives input plus cache reads and writes of 959,766,109, identical to the transcripts. ClaudeAdapterV2 already reads message.model from these messages to label the subagent, but its usage branch only runs when parent_tool_use_id === null.

   Output is the gap. On these per-block messages output_tokens is not final, as the SDK's SDKAssistantMessage docs say: they add up to 70K against 3.53M actual. Subagent message_delta events don't reach the host, as there are none in this log. So the stream gives an exact cumulative input figure but not output. The final output would have to come from somewhere else, such as the agent_transcript_path in the SubagentStop hook input. Otherwise it stays unknown.

   For Codex, the child provider turn already records per-run turnTokenUsage, as @jlipworth showed, so it could be mapped onto the subagent, with #5793's inherited-history caveat for forked children.

   Possible shape, as a follow-up to #15446 rather than a change to it. Add a cumulative field next to usage.contextTokens, set only when the provider gives per-request or per-run evidence and left unset otherwise. Show it beside context, for example 899K context · 191M processed. Only the cumulative figure would ever be summed, which keeps apart the two quantities #14003 separated. Whether output is included, and from which source, is the main open question.

   If this direction is wanted, I can take it on after #15446 lands. The scope would be the Claude adapter sum plus the Codex mapping, displayed in the same tooltip and mobile row.
5. nbrosei commented on Oct 15, 2026

   

   nbrosei

   on Oct 15, 2026

   More actions

   Orchestrator V2 is great but the inability to see token usage is a regression compared to the previous simple subagents implementation which did have it.
   Without that feature I use more tokens to know how many tokens I used, by asking the agent to keep track of token usage.