[BUG] Workflow started 189 additional subagents after a session-limit error, with no recorded usage

Summary

A model-authored copy-review script executed through Workflow created 221 subagents over 51 minutes. After the first recorded session-limit error, 189 additional subagents were started over the following 3m20s. All failed, with no recorded model responses or token usage in those 189 transcripts.

The script's large context and fan-out explain the earlier token volume; I am not attributing that volume to these 189 failed agents. The behavior I am reporting is continued execution after a terminal quota error, and uncertainty about how agent() exposes that failure to its caller.

Environment

• Claude Code 2.1.266, Windows 11, desktop Code session, Max 20x.
• Model: claude-fable-5-1 in all recorded model responses.
• Script: 18 static agent() call sites with mixed effort settings (11 high, 6 xhigh, 1 medium); these are call-site counts, not request counts.
• Date: 2026-09-12, 13:12:12 to 14:03:25, UTC-3.
• 221 unique agent IDs, 29 successful outcomes, 192 failed outcomes.
• Maximum observed transcript-window overlap: 10, not 221 simultaneous agents. This is not a measurement of simultaneous HTTP requests.

Expected and observed behavior

The task was a copy review of three documents. I expected a session-quota failure to stop further dispatch or propagate a distinguishable error that the script could handle.

| Phase | Agents | Completed | Recorded model responses | Accounted tokens, including cache |
|---|---:|---:|---:|---:|
| Ground | 5 | 5 | 57 | 11,063,801 |
| Find | 24 | 24 | 165 | 35,885,272 |
| Merge | 3 | 0 | 3 | 516,226 |
| Subsequent five phases | 189 | 0 | 0 | 0 |

• Last recorded model response: 13:52:28.807.
• First session-limit error: 14:00:05.110: You've hit your session limit · resets 4:50pm.
• First subsequent-phase agent: 14:00:24.665.
• Run ended: 14:03:25.794.

The intervening gap before the error is not explained by the available records; I cannot establish whether it was retry backoff or waiting.

Script contribution and error propagation

The merge stage used this fallback:

const res = await agent(/* merge prompt and schema */);
merged[dk] = res ? res.findings : items;

After the merge failures, the script continued with 143, 143 and 144 raw findings. Batching each document by eight, with three verifiers per batch, produces (18 + 18 + 18) × 3 = 162 verification agents, matching the journal.

This fallback is a weakness in the generated script. The observed continuation is consistent with a falsy result reaching it. The failure journal entries do not, by themselves, prove the exact return value of agent(). Please clarify whether quota errors return null, throw, or expose an error through another documented mechanism. I have not verified the claim that quota failure and legitimate empty results are indistinguishable.

Measurement and impact

An independent local recount grouped records by agent ID + request ID + message ID, taking the final usage snapshot ordered by timestamp and block index. Per-field maxima produced identical totals.

There are 1,018 assistant content-block records but only 225 distinct request IDs and 225 distinct message IDs. Counting every record UUID would repeat input/cache usage and incorrectly produce 201,174,305 tokens. The corrected figures are:

| Metric | Tokens |
|---|---:|
| Uncached input | 6,212 |
| Cache creation | 8,507,425 |
| Cache read | 37,920,023 |
| Output | 1,031,639 |
| Total, including cache | 47,465,299 |

These are transcript-accounted tokens, not a billing statement. The 225 responses do not count unlogged HTTP attempts. The 192 synthetic failure markers are not counted as model responses.

The UI showed 100% five-hour usage, 22% weekly all-model usage and 42% weekly Fable usage. These are observed final states, not this run's exclusive quota consumption. Results from the 29 completed agents were recovered, but the final review was not completed.

I had $20 in usage credits available to continue investigating. A later screenshot shows $17.70 used; I have not isolated that amount between the incident, investigation and subsequent work.

Configuration and limitations

Workflow was presented as a built-in tool. Its implementation has not been located, so ownership of the dispatch/error-handling component remains unverified. The orchestration script was generated in-session.

The local investigation reports that skipWorkflowUsageWarning was enabled before the incident; who enabled it is unknown. It has since been disabled, and a local hook now blocks workflows by default. I am not claiming the execution could not be manually stopped.

No minimal reproduction has been rerun. Original transcripts and the workflow journal are preserved; sanitized excerpts can be provided.

Requested investigation

1. Should a terminal session-quota error cancel remaining workflow dispatch, or is explicit script-level handling required?
2. How should scripts distinguish quota failure from an empty result?
3. Is an enforced per-workflow token/agent budget available?
4. What live usage visibility and cancellation mechanisms should users rely on?

Please investigate the post-quota behavior and clarify the supported error contract. Account-specific quota or credit requests will be handled privately.

Related report: https://github.com/anthropics/claude-code/issues/80253 describes retries after session-limit errors. The distinguishing observation here is 189 subsequent agents with no recorded model responses or usage, rather than duplicated successful work. A shared cause has not been established.

Version follow-up

The incident is preserved from version 2.1.266. A later local CLI version check returned 2.1.267, while the latest GitHub release checked was 2.1.269. I install updates when prompted, but I have not reproduced this incident on 2.1.269 and am not claiming that I have.

Usage screenshot

This later screenshot shows the quota state and usage credits at capture time. It does not isolate the incident from subsequent investigation or work.

!Usage limits and credits after the incident