[Bug]: Agents panel token counts for Claude subagents are context sizes, not totals: compaction erases earlier work, and Σ adds up context sizes

[Vantrongs]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. In a Claude thread, run subagents long enough that at least one auto-compacts.
2. Watch that subagent's row and the Σ total at the bottom of the Agents panel before and after its compaction.

Expected behavior

A row shows how much the subagent has used, and this number does not go down when it compacts; the current context can be shown separately. Σ adds up comparable numbers.

Actual behavior

For Claude subagents both the row and Σ are built from the subagent's context size on its latest request.

• Row. usage.total_tokens from task_progress / task_notification equals the context of the subagent's last API request (input + cache write + cache read + output). In one thread, the values reported for three subagents, 217,946, 311,267 and 317,140, match the last request in their transcripts exactly. A subagent continued with SendMessage reports 358,641 → 482,812 → 628,985 → 653,032: a growing context, not deltas.
• Compaction. One subagent auto-compacted (compact_boundary: preTokens 966,517, postTokens 14,683). Its row went from 969,529 to 44,138 in the next update and ended at 805,020. Over 883 requests it wrote 3.86M uncached tokens (input, cache writes and output) and read 410M from cache; the row shows 0.8M.
• Σ. This is the plain sum of these per-row values. For that thread it shows 15.5M, while the subagents processed 40M tokens without cache reads, or 2.16B with them. It also mixes Claude context sizes with Codex cumulative totals (CodexAdapter maps tokenUsage.total).

Cause, from main (de251fc):

• normalizeTaskUsage (apps/server/src/provider/Layers/ClaudeAdapter.ts) copies usage.total_tokens into typedUsage.totalTokens.
• Ingestion writes it to one activity per task with a fixed id, task-usage:<thread>:<task> (ProviderRuntimeIngestion.ts, task.progress). Each update replaces the previous one, so the value from before a compaction is gone before the client sees it. mergeUsageMax in foldSubagentActivities cannot bring it back.
• AgentsPanel.tsx shows agent.usage.totalTokens as "N tok"; Σ sums the same field across agents.
• The comments disagree with the data and with each other: RuntimeTaskUsage (packages/contracts/src/providerRuntime.ts) says Claude reports "per-activation deltas"; the mergeUsageMax comment says it is "cumulative per task".

Suggested fix

• Treat Claude's total_tokens as the current context size and fix both comments.
• Keep a second, cumulative number per task on the server. Sum per-request usage if the SDK forwards it for subagents; otherwise at least carry the high-water mark across drops, so a compaction does not erase earlier work.
• Show both in the row, for example 805k ctx · 3.9M processed · 1 compaction. Make Σ sum the cumulative number, or label it as current context.

Related: #12013 (closed PR that assumed the row was already cumulative for Claude), #4650 and #13659 (the same task_progress values inflate the main thread's context meter), #5793 (Codex subagent totals).

Impact

Minor bug or occasional failure

Version or commit

main @ de251fc; installed 0.0.43-nightly.20260926.2282

Environment

Desktop app on Linux (NixOS); Claude Code 2.1.283 through the Agent SDK

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

No response

[juliusmarminge]

Triage

Confirmed on main. The Agents panel is showing Claude subagent context size as if it were lifetime usage, and a compaction drop sticks. This is separate from the parent context-meter bugs.

normalizeTaskUsage in ClaudeAdapter.ts copies task_progress / task_notification usage.total_tokens straight into RuntimeTaskUsage.totalTokens. The parent meter already treats that field as current context: the task-progress test maps total_tokens: 321 to usedTokens: 321. A smaller update is dropped there (normalizeClaudeTaskProgressTokenUsage emits nothing unless the value is strictly above lastKnownTokenUsage), which is the ratchet in #4650. The panel does the opposite and renders the latest value, so the row falls across compaction.

The comments disagree with each other and with that behavior. RuntimeTaskUsage says Claude reports per-activation deltas. mergeUsageMax says the value is cumulative per task and must not shrink. Ingestion then keeps one usage row per task, task-usage:<threadId>:<taskId>, and upserts it in place (ProviderRuntimeIngestion.ts). The fold only sees the surviving snapshot, so mergeUsageMax cannot retain the pre-compaction number. The max-merge test only holds when both frames are still in the activity list; the stable id prevents that for live progress. task.completed is a separate row, but it carries the same final snapshot, so it does not restore the dropped work.

AgentsPanel.tsx prints that field as N tok on each row and on workflow group totals. The footer Σ is the plain sum in foldSubagentActivities. Chat spawn rows in MessagesTimeline.tsx use the same field. Codex rows are a different quantity: collabAgent/tokenUsage maps tokenUsage.total (cumulative, and #5793 includes inherited parent history). Adding those to Claude's latest context sizes is not a usage total.

Related, not duplicates:

• [Bug]: context meter ratchets up and never reflects /compact — task_progress writes cumulative tokens into usedTokens via Math.max #4650 and fix(server): the context meter must only consume per-request usage evidence #13659 are the parent context meter consuming this field. Fixing the meter does not fix the panel.
• [Bug]: Codex Agents panel counts inherited parent history in each child token total #5793 is Codex children counting inherited parent history.
• feat(web): show subagent context in Agents panel #12013 (closed, unmerged) assumed the Claude row was already cumulative and added a separate context-size mode. For Claude that would display the same snapshot twice.

The transcript totals in the report were not re-checked here. The code path will show the latest total_tokens and will drop it across compaction, which matches the 969,529 → 44,138 observation.

A fix needs a lifetime figure that survives compaction (sum per-request subagent usage when the SDK forwards it; otherwise at least a high-water mark stored outside the replaced snapshot), and Σ has to add that figure only. Current context can sit beside it, but it should not be the summed number. The two comments should be corrected in the same change.

[kvnloo]

One contract split seems worth making explicit before changing the panel:

• contextTokens: current occupancy. Snapshot semantics; it may decrease after compaction and must never be summed across time.
• totalTokens: cumulative attributable work. Monotonic/additive when the provider actually exposes enough evidence for it.

For Claude task_progress.usage.total_tokens, the evidence here says we only know the first quantity. I would rather emit that as contextTokens and leave totalTokens unknown than promote a high-water mark into a lifetime total.

That also gives the UI a safe rule: show 805k ctx for Claude; include a tok value and the footer Σ only for agents with a cumulative/additive total. A mixed-provider Σ should never add Claude context occupancy to Codex cumulative work.

If we later derive Claude lifetime usage from per-request evidence, it can populate totalTokens without changing the presentation contract.

This is the same incremental-vs-aggregate separation that prevents double counting in token accounting generally; the important part here is preserving unknown rather than turning a context snapshot into a total.