[BUG] Workflow subagents retry from blank context after session-limit errors, duplicating usage

What’s wrong?

When a multi-agent Workflow reached my session usage limit while subagents were still running, affected subagents were automatically retried from blank context instead of the workflow stopping or pausing.

The retries re-read the same project files, rebuilt their plans, and repeated work that previous attempts had already completed.

One visual-QA subagent ran three attempts. Its first attempt had already completed the Playwright setup and generated the required screenshots. Later attempts restarted cold and repeated the capture process, producing no additional usable output.

I submitted the affected session privately through /bug. I can provide the corresponding feedback reference, session ID, workflow run ID, background task IDs, and local transcripts privately if required.

Observed sequence

I started a multi-agent Workflow using claude-fable-5.
Several subagents were running concurrently.

Claude Code reached the session limit and displayed:

You've hit your session limit · resets 5:50pm

Subagents that failed on the limit error were automatically retried.
The retries started without the previous attempt’s context.
They re-read files and repeated completed work.
One visual-QA task was attempted three times, despite artifacts from the first attempt already existing.
The repeated attempts produced no additional usable result.

I have not intentionally reproduced this again because doing so would consume additional paid-plan usage.

Actual behavior

A session-limit error is treated as retryable. Failed subagents restart from blank context and redo previously completed work, with the repeated work counted against the user’s usage allowance.

Existing artifacts from earlier attempts are not reliably reused.

Expected behavior

A session-limit or quota error should act as a circuit breaker:

• Stop or pause the affected workflow.
• Do not retry while the same usage limit remains exhausted.
• Respect the reset time returned with the error.
• Preserve partial subagent state where possible.
• Reuse valid artifacts created by earlier attempts.
• Require explicit user confirmation before resuming work that may repeat substantial usage.

Workflow scale and model selection

For context, I asked Claude to create a dynamic Ultracode workflow to refine the appearance of an existing form step, generate four layout variants, and add a small selected-option chip interaction.

I expected a workflow demonstrating Claude Code’s orchestration capabilities, so I accept that multiple agents could reasonably be involved. However, I did not specify the number of agents or instruct Claude to use Fable 5 for every stage.

Claude selected approximately 13 Fable 5 agents for a relatively contained set of CSS, TSX, interaction, and visual-review tasks. Before launching, Claude Code did not show:

• The planned number of agents
• The model assigned to each agent
• An estimated usage range
• A warning that the workflow could consume a substantial part of the weekly allowance
• An option to use cheaper models for mechanical audit, verification, or QA stages
• A confirmation prompt before starting the high-usage workflow

This is relevant because the orchestration scale greatly increased the impact of the retry bug. I am not claiming that all multi-agent usage was invalid, but users should be able to understand and approve the approximate cost and model allocation before a workflow of this size begins.

Usage impact

The local workflow journal recorded:

Initial run: approximately 857,688 subagent tokens
Resumed run: approximately 232,590 subagent tokens
Total: approximately 1,090,278 subagent tokens
Estimated duplicated retry work: approximately 250,000–300,000 tokens

The estimated duplicate portion was approximately 22.9–27.5% of the workflow’s total subagent-token usage and produced no additional usable output.

The overall workflow also appeared to reduce my weekly Fable usage allowance by close to 20 percentage points.

These figures are based on the local run journal. Anthropic’s server-side logs should contain the authoritative usage and retry records.

Error message
You've hit your session limit · resets 5:50pm

No separate application crash occurred. The problem was the automatic retry behavior after this error.

Environment

Product: Claude Code VS Code extension
Plan: Max 20x
Model: claude-fable-5
Operating system: macOS
Date observed: July 22, 2026
Time window: approximately 17:29–18:30 CEST

##Additional context

I understand that the successful work performed by the workflow legitimately counts toward usage. This report concerns only the automatic retries that repeated completed work after a known session-limit error and produced no additional result.

The affected session and diagnostic identifiers have been submitted privately through /bug rather than included here because this GitHub issue is public.