TaskStop does not stop subagent children: 750k tokens billed after kill, with no live usage visibility and no cap

Update, ~30 minutes later: it is worse than reported. TaskStop cannot even FIND deeper descendants.

After filing this, a sixth orphan surfaced in the UI, still running, roughly 40 minutes after both parents were killed. The user spotted it herself in the agent list.

TaskStop succeeded on that one:

{"message":"Successfully stopped task: af298e0ee977dc606 (Research retrieval and resurfacing)","task_type":"local_agent"}

Its final message on being killed was:

"Agent 2 delivered. Retrying the Meyer essay while agent 1 finishes."

So that orphan had children of its own. Inspecting the subagent transcript directory found two more agents that had been writing minutes earlier:

662360   17:04  agent-af298e0ee977dc606.jsonl   <- killed successfully
6001921  17:04  agent-a5e1a037f67b50abf.jsonl   <- 6 MB transcript
622154   17:01  agent-a3000dc7d4f4e4875.jsonl

Attempting to stop either of the remaining two:

TaskStop(a5e1a037f67b50abf) -> No task found with ID: a5e1a037f67b50abf
TaskStop(a3000dc7d4f4e4875) -> No task found with ID: a3000dc7d4f4e4875

These are at least three levels deep (parent -> child -> grandchild) and TaskStop has no visibility into them at all. They are not merely unstoppable via the parent, which is the original report. They are unaddressable individually. The only reason their existence is known is that their transcript files are on disk.

They appear to have stopped on their own: both transcripts grew 0 bytes over a 45-second observation window. But that cannot be confirmed, and one carries a 6 MB transcript, which suggests a very large amount of work.

Revised severity

The original report said a killed parent's children keep billing. The accurate statement is stronger:

• A subagent tree can nest at least three levels deep.
• TaskStop reaches only the level it was given, and returns No task found for anything deeper.
• There is no enumeration API for the tree. Discovering the descendants required listing ~/.claude/projects/<project>/<session>/subagents/*.jsonl by modification time.
• Therefore there is no supported way to stop a runaway subagent tree, only the level you happen to hold an ID for.

Add to the suggested fixes: an enumeration call that lists all live agents in the session with their depth, parent, and accumulated usage. Without it, neither the user nor the orchestrating model can tell what is running.

Update: Anthropic Support has confirmed this behaviour in writing, and confirmed there is no billing remedy for it

I raised the billing side of this incident with Anthropic Support separately (2026-07-30). Quoting their replies here because they settle two questions this issue was implicitly asking, and they settle them against any non-product fix.

1. The behaviour is confirmed.

"child agents may not stop when a parent process is stopped"

2. There is no billing remedy, and no exception process.

"there is no exception process for billing adjustments on consumed usage, including cases where a stop command reports success but subagents continue running. Our Credit Terms apply uniformly to all API usage regardless of the underlying cause, and this policy does not have exceptions."

3. Support characterises the combination as a product design issue, and restates it accurately:

"You've identified a legitimate product design issue: the combination of a stop command that reports success without stopping child agents, no real-time visibility into running agent token usage, and no budget controls at launch creates a scenario where usage can run beyond what a user can observe or halt."

They have recorded it as product feedback for the team.

Why this matters for prioritising this issue

Taken together, those three statements mean the exposure is unbounded and has no remedy after the fact. A user cannot observe the spend while it accrues, cannot cap it at launch, cannot stop it once running (the stop control reports success without acting), and cannot recover it afterwards. There is no layer at which this is currently recoverable except the product itself.

In my incident that was 750,460 tokens metered after TaskStop returned success — 43% of a 1,735,218-token session, and roughly ten percentage points of a weekly Max allowance, in about forty minutes. Those figures are the harness's own reported subagent_tokens values from its completion notifications, not estimates.

I am not re-raising the billing question; that is answered and closed. I am noting that the answer removes the only fallback, which changes what the three fixes below are worth.

The asks, unchanged from the original report

1. TaskStop on a parent terminates its subtree — or the response states plainly that children remain alive and lists them so they can be stopped individually.
2. A running agent's accumulated usage is queryable mid-flight, so "what is consuming my tokens" can be answered while it still matters.
3. Agent launch accepts a token budget, a tool-call cap, and max_depth / allow_subagents: false. A prompt instruction is not an enforcement mechanism.

Of the three, (1) is the one support's confirmation makes urgent: a control that reports success without acting is worse than no control, because it stops the user looking.

Corroborating another incident with the same root cause, same day (2026-08-20).

A /code-review style skill was run at "max" effort against a single small PR (~2 files changed). The orchestrator fanned out into 20+ concurrent/sequential sub-agents. TaskStop was called on the top-level orchestrator, which reported success — but ListAgents immediately afterward showed several of its children still running, including one that alone had already consumed ~186K tokens by the time it finished. Stopping the run required 2-3 more rounds of ListAgents → individually TaskStop-ing each still-running child, since some children had themselves spawned further children.

Given the confirmation already on record here that Anthropic Support has ruled out billing exceptions for this bug, not pursuing a credit request for this instance — just adding the data point in case it's useful for prioritizing a fix.