[BUG] Subagent cost is invisible, unattributable and unstoppable: background-task chips open uncapped sessions, prompts are billed per turn

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Four independent gaps in how subagent cost is surfaced, attributed and controlled. Together they consumed a weekly allowance in ninety minutes with no signal available to the operator until after the fact. Every figure below comes from each agent's own completion record or from the app's own usage panel.

1. A background-task chip opens a full session with an uncapped fan-out

A suggestion chip is presented in the UI as a small deferred item. Clicking one opens a separate session which then fans out on its own. No cost estimate appears before the click, during the run, or after it. Four chips clicked in one day produced 31 subagents.

2. The session that offers a chip is blind to it and cannot stop it

The subagents created by a chip never appear in the offering session's ListAgents output, and no consumption figure is ever returned to it. Asked to account for its own spend, the offering session reported 2 subagents, in good faith, because that was the only number the product had given it. The real figure was 33. When the operator said stop, that session could terminate its own agent with one call, but for the sessions its chips had created it could only send messages and rely on each one choosing to comply.

3. A subagent's prompt is billed on every turn, not once

A lane re-sends its prompt and everything it has read on each tool turn, and a working lane takes 100-330 turns. A 70,000-token reading list on a 300-turn lane is 21,000,000 tokens before the lane does any work. Nothing in the briefing interface indicates this multiplication. Across one day, 33 agents: two billion cache reads.

Related: messaging a running subagent to correct its instructions re-sends that agent's entire accumulated context. The interface presents this as appending a note. One session measured that close to half its total spend was context re-transmission and nothing else.

4. Concurrency and usage are enforced and displayed per session, never per account

Each session enforces its own concurrency ceiling and cannot see any other. Four sessions each staying inside their own limit produced 33 concurrent and near-concurrent agents against one shared allowance.

What Should Happen?

Subagent cost is visible, attributable, and stoppable by the session that caused it.

• A background-task chip shows an estimated cost before the click and a running figure while the session it created is active.
• The subagents a chip creates appear in the offering session's ListAgents output, and their consumption is reported back to it.
• The offering session can enumerate and stop the sessions its own chips created.
• Spawning a subagent shows expected prompt cost multiplied by turn count, and resuming a running subagent warns that the full accumulated context will be re-sent.
• Concurrency limits and a running usage total are enforced and displayed at the ACCOUNT level, not per session.

Error Messages/Logs

No error. The client's own usage panel, after the fact:

100%  came from subagent-heavy sessions
 92%  ran above 150k context
 66%  came from sessions active for 8+ hours
 32%  ran while 4+ sessions were in parallel

Per-session cost, same day, same account:
  main session      $771.15   cache read 2,000,000,000
  chip session A    $267.25   cache read   376,200,000
  chip session B    $192.15   cache read   354,600,000
  chip session C    $132.03   cache read   216,100,000
  chip session D      $8.08   cache read     7,700,000

Steps to Reproduce

1. From a session, offer a background-task suggestion chip and click it. A separate session opens with its own fan-out. No cost estimate is shown before, during, or after.
2. In the offering session, run ListAgents. The subagents created by that chip do not appear, and no consumption figure from them is ever returned to it.
3. Ask the offering session to account for its own subagent usage. It reports only the agents it spawned directly - 2 in our case, against a real figure of 33 across the account.
4. Spawn a subagent with a large mandatory reading list and let it run past 100 tool turns. The prompt and reading list are re-sent on every turn. Nothing at spawn time indicates that the reading list is multiplied by the turn count.
5. Send a correction to a running subagent. Its entire accumulated context is re-sent. The UI presents this as appending a note, with no cost shown.
6. Open four sessions on one account. Each enforces its own concurrency ceiling and none can see the others; together they exceed any single session's limit against one shared allowance.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

1.37937.1 (edbd3c) - Claude for Windows desktop app

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Shell: Git Bash (D:\Git\bin\bash.exe) via the desktop app's Bash tool. The Terminal/Shell list has
no entry for it; PowerShell was selected as the nearest available option and is only used here for
Windows toast notifications.

Claude Code Windows desktop app, version 1.37937.1 (edbd3c) - not a terminal shell, and the Terminal/Shell field has no option for it. Max (20x) subscription.

Measured over one working day on a single machine and a single account: 33 subagents across five sessions, approximately 17,000,000 tokens, two billion cache reads, $1,370.66. Four of the five sessions were created by background-task chips.

The failure mode is not a runaway loop. Every individual decision looked correct and diligent; the cost was structural and invisible until after the allowance was gone. That is the hardest class of problem for a user to self-diagnose, and it is fixable entirely at the surface level.