[BUG] Subagent output discarded when spend limit terminates fanout — tokens billed, zero results returned

Adding related public pattern context for Anthropic Billing Platform / cost-control triage, because this thread describes tokens/purchased overage being consumed while spend-limit termination discards the deliverable.

Related open Anthropic-owned cost/billing reports:

• Workflow fan-out inherited an expensive tier and triggered automatic usage-credit purchases/card charges without a per-agent or per-workflow spend gate: https://github.com/anthropics/claude-code/issues/68285
• Max plan usage billed to Extra Usage while plan usage was far below limits: https://github.com/anthropics/claude-code/issues/68501
• Purchased/personal credits consumed while subscription quota appeared available: https://github.com/anthropics/claude-code/issues/64613

Sanitized public evidence hub collecting related manual-credit, extra-usage, entitlement-routing, auto-topup, and support-routing examples: https://coolak.github.io/anthropic-claude-billing-incident/

Request: please route this failure family to a human Billing Platform / cost-control owner. A spend limit that bills tokens/overage and returns no recoverable work needs billing-ledger reconciliation and product-level spend-gate review, not only generic usage-limit guidance.

Second data point, from the Claude Code CLI rather than Cowork, and from a session limit rather than a monthly spend limit — same discard-on-termination behavior, so the failure family looks broader than the billing surface it was first reported on.

Three independent occurrences across three worktrees of the same project, v2.1.220, Opus 5, Claude Pro:

| Date | Agents dispatched | Killed | Tool uses (killed) | Tokens (killed) | Output returned |
|---|---|---|---|---|---|
| 2026-07-29 | 3 × Explore (foreground) | 2 | 25, 30 | 74,102 + 68,910 | preamble sentence only |
| 2026-07-30 | 1 × Plan (background) | 1 | — | — | "I'll verify the key files before designing." |
| 2026-07-31 | 2 × Explore (foreground) | 1 | 25 | 67,570 | "I'll explore these components in parallel." |

~211,000 tokens across 80 tool calls in the foreground cases, and what came back was each agent's opening sentence — the text it emitted before its first tool call. None of the retrieval work survived.

The transcript structure for a killed foreground agent:

{
  "status": "completed",
  "totalTokens": 67570,
  "totalToolUseCount": 25,
  "content": [
    { "type": "text", "text": "Agent terminated early due to an API error: You've hit your session limit · resets 4:20pm\n\nEverything below is PARTIAL output recovered from the agent before it was cut off. The agent did NOT finish its task — treat these results as incomplete." },
    { "type": "text", "text": "I'll explore these components in parallel." }
  ]
}

Two things worth adding to the picture here:

The termination is recorded as success. status: "completed", is_error absent. In the terminal the killed agents render as Done with their token counts, indistinguishable from agents that actually finished. I've filed that separately as #82829 since it's a distinct defect from the discard itself.

There is no pre-flight check on the CLI either. In the 2026-07-31 case the You've used 99% of your session limit warning was already on screen while the agents were mid-flight. Everything they burned after that point was structurally unrecoverable, and nothing stopped the fan-out or warned before dispatch. That matches the "no budget check before fan-out" point in the original report.

Adding this because the original report is scoped to Cowork + monthly spend limits; the same architecture discards work on the CLI under ordinary subscription session limits, which is a much more frequently hit condition.

Your table shows the real shape of this: 285k tokens across 4 agents, and the loss isn't just "no partial recovery" — it's that the four agents had no shared budget accounting. Each one independently kept spending until the account limit tripped, so there was never a point where agent 2 could know agent 1 had already consumed the remaining headroom. A pre-flight check on the parent (your fix #1) helps decide whether to fan out at all, but once they're in flight the missing piece is a shared, decrementing budget the agents draw from — otherwise N agents race the same limit and all of them lose when it hits. Pre-flight sizing and a shared runtime budget are two different controls; you want both.

On partial-result loss (your fix #2), the reason it's total rather than partial is architectural: only an agent's final return value propagates to the parent. All the intermediate tool results — the 25–43 tool calls each agent made — are real work that lived only in that agent's context, and the context dies with the agent. That's genuinely thrown away, and it's why "one status line" is all that came back.

But that same fact gives you a workaround that works today, before any fix: have each subagent checkpoint its findings to disk as it goes — append each retrieved result to a scratch file (findings/agent-3.ndjson) the moment it has it, not at the end. Then a spend-limit kill costs you only the last in-flight step; everything already written survives in the filesystem, and the parent (or a rerun) reads the scratch files instead of re-fetching. For your clinical-trials case that's the difference between losing 110 tool calls' worth of retrieval and losing one. It also makes the run resumable: on restart, skip trials already present in the scratch files. The durability boundary you want is the disk, precisely because it's the one thing that outlives an API-terminated agent.