[BUG] API errors and sub-agent stalls - Repeated and often failures regardless of effort level, model or brief size.

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?

Bug report — subagents stall to death ("no progress for 180000ms") while Claude Status shows green

Reporter environment

• Claude Code 2.1.245 (env AI_AGENT=claude-code_2-1-245_agent)
• Windows 10 Pro 19045, terminal shell Git Bash, PowerShell 7 also available
• Model: claude-opus-5, effort high/xhigh
• Session id: b64cd3f1-ade6-4a84-a957-cebe5832a899
• Project: C:\AURA\aura-private-main (large C++/JUCE audio codebase)

Summary

Subagents dispatched via the Workflow tool fail with

agent stalled on all 6 attempts (no progress for 180000ms each)

— i.e. they make no tool call at all for the full 180 s stall window, six times consecutively,
then are abandoned. A second, rarer variant is API Error: The response stopped arriving.

This has been happening for over a week. Claude Status reported all-green throughout.

The failure is not random: it is strongly load-correlated, and completion rates have collapsed
between two dates on the same machine, same session, same scripts, same models.

Hard numbers — the same session, three days apart

Counted from the workflow journals under
~/.claude/projects/C--AURA-aura-private-main/b64cd3f1-ade6-4a84-a957-cebe5832a899/subagents/workflows/<run>/journal.jsonl
(started counts include the 6 retry attempts per agent, so the ratio is the useful signal).

| Date | Run id | started | results | starts per result |
|---|---|---:|---:|---:|
| 2026-08-22 09:44 | wf_2a2d3534-744 | 4 | 4 | 1.00 |
| 2026-08-22 11:26 | wf_31f5f53e-12b | 24 | 24 | 1.00 |
| 2026-08-22 12:46 | wf_63c8587e-a31 | 23 | 23 | 1.00 |
| 2026-08-22 12:53 | wf_5929f596-26c | 35 | 34 | 1.03 |
| 2026-08-22 12:59 | wf_ffdf8ed2-8ef | 76 | 75 | 1.01 |
| 2026-08-22 13:52 | wf_39084f1b-974 | 4 | 4 | 1.00 |
| 2026-08-25 13:56 | wf_46b3ceee-56b | 4 | 4 | 1.00 |
| 2026-08-25 19:31 | wf_f349a60a-b81 | 146 | 11 | 13.3 |
| 2026-08-25 22:24 | wf_921d04e0-5f3 | 224 | 62 | 3.6 |

On 22 Aug, 166 agent starts produced 164 results. On 25 Aug, 370 starts produced 73.
Roughly 27 and 22 agents respectively died having exhausted all six attempts.

Transcript directories for the two bad runs are the paths above; per-agent transcripts are
agent-*.jsonl beside each journal.jsonl.

What distinguishes the agents that die

Consistent and reproducible in this session:

• Long briefs die; short briefs survive. Two review agents with ~8 KB briefs each failed six

attempts, twice over (12 consecutive failures, zero output). Rewriting the same work as four
single-question briefs of ~1.5 KB produced a clean result on the first try, same model, same
effort, same minute.

• Agents holding large structured input die hardest. Document-writing agents receiving ~84

findings plus verdicts as JSON failed four times running across two runs.

• Effort level does not appear to matter — low-effort paste-only agents have also been lost.
• Retries do not help. An agent that stalls once stalls all six times. It is not a transient

blip being retried through; nothing ever gets going.

Client-side symptom that accompanies it

While many agents are in flight, the Claude Code TUI itself starves:

• Typed characters take minutes to appear in the terminal — this is plain typing, not submitting.
• Workflow elapsed-time counters stop updating smoothly and jump forward in 20 s to 2 min blocks.
• The rest of the OS is unaffected; only the Claude Code terminal is degraded.
• Relief is observable the instant an agent dies or completes, then it degrades again.

This suggests whatever is starving the agents is also starving the client's render/input loop,
which may be the more diagnosable half.

Possibly relevant

• Three Claude Code sessions were running concurrently in separate terminal windows on separate

projects when the worst run occurred. The reporter has run more than three concurrently in the
past without trouble.

• The reporter's recollection is that this began around the Opus 5 release. Prior multi-agent

runs on this same project and machine, using the same workflow patterns, completed at ~99 %.
The 22 Aug figures above are from that earlier, healthy period.

• One agent additionally reported: `claude-sonnet-5[1m] (the safety classifier) was unavailable

(timed out) when reviewing this subagent's work` — so a supporting service was also timing out
during the same window.

Impact

A single stalled agent occupies a concurrency slot for 6 × 180 s = 18 minutes before it is
abandoned, so a handful of them serialises an entire run and compounds the client starvation.
Multi-agent work on this project has gone from routine to needing three or four re-dispatches to
complete, at very large token cost for zero output — the two failed runs above burned roughly
10 M subagent tokens between them and produced two truncated files.

What would help

1. Surface why an agent made no progress — is it waiting on the API, waiting on a tool

permission, or genuinely thinking? The current message cannot distinguish these, and they have
very different fixes.

1. Make the 180 s stall window configurable (there appears to be no setting or env var for it).
2. Fail an unrecoverable agent faster than 6 × 180 s, or back off between attempts, so a bad agent

stops holding a slot.

1. If this is capacity-related, it is not being reflected on Claude Status.

It does not affect every session — and the difference may be the whole story

Reported concurrently with the failing run above, in a different session on the same machine at
the same time: a bounded-research task running 33 Opus 5 agents (11 + 12 + 10 across three
phases, standard subagent types, search and fetch at high effort, synthesis and verify at xhigh).
Zero failures.

The two workloads differ in one respect that lines up exactly with what the stall detector measures:

| | research run (healthy) | audit run (failing) |
|---|---|---|
| dominant activity | web search / fetch | reading a large local C++ tree and reasoning over it |
| natural gap between tool calls | seconds | tens of seconds to minutes |
| input held per agent | a page at a time | 250 KB diffs, ~84 findings as structured JSON |
| brief size | small | ~8 KB |
| margin against a 180 s no-tool-call window | very large | narrow by nature |

Hypothesis (offered as inference, not established)

The stall detector measures wall-clock time between tool calls, which is a proxy for liveness
that penalises thinking rather than stalling. Reasoning-heavy agents have presumably always run
close to the 180 s line. If model latency or queueing has risen even moderately, their think-time
inflates past the threshold and they die en masse, while search-shaped agents — with seconds of
margin — are entirely unaffected by the same slowdown.

This would account for every observation in this report simultaneously:

• a research run and an audit run, same machine, same hour, opposite outcomes;
• 22 Aug at ~99 % on the same analysis workload and the same model as 25 Aug at 8–28 % — the

workload did not change, the margin did;

• short briefs surviving where long ones die (less reasoning per gap);
• retries never helping (a threshold crossed, not a transient missed);
• the reporter's sense that it began around the Opus 5 release, a model that reasons for longer.

What follows from it, if true

• A configurable stall window becomes a real fix, not a workaround. (The reporter found no

setting or environment variable exposing it.)

• The detector would be better keyed to evidence of liveness from the model — tokens arriving,

reasoning in progress — than to tool-call arrival, which conflates "hung" with "thinking hard".

• Failing after 6 × 180 s of a condition that will not clear wastes ~18 minutes and a concurrency

slot per agent. If the first attempt stalls for a full window, the remaining five are near-certain
to as well.

A server-side testable prediction

The reporter observes that the failures track high-token, long-horizon tasks rather than task
count. That is the same mechanism seen from the other end: more tokens per agent means longer
reasoning per turn, which means a longer gap between tool calls, which means less margin against
the 180 s window.

This is checkable in telemetry without reproducing anything: for agents killed by the stall
detector, compare tokens-per-turn and time-to-first-tool-call against agents that completed, over
the same window. If the hypothesis holds, killed agents should cluster at the high end of both,
and the distribution should have shifted between 22 and 25 Aug while the workload did not.

A concurrent run in another session (the research-shaped workload described above) has so far seen
2 failures across 23 completed agents (~9 %), with 10 still running of 33 total. It began the
run with zero failures and began losing agents only later, as the reasoning-heavy session degraded
alongside it.

For contrast, over the same period the reasoning-heavy audit workflow in this session lost
6 agents out of 37 and spent ~5.0 M tokens doing it. Both sessions are degrading; the
search-shaped one is degrading far more slowly.

Note on partial output

A stalled writer leaves a truncated file, not an absent one. In this run a complete, verified
204 KB document was overwritten by a re-run whose writer died three sections in, leaving 6 KB.
Any agent that writes incrementally should banner its file as a draft until it completes, so a
half-written artefact is not mistaken for a finished one.

What Should Happen?

A subagent that is actively reasoning should not be killed for it.

1. Liveness should be measured from the model, not from tool calls. The current watchdog fires in the gap between a tool result and the next assistant chunk, which measures thinking rather than hanging. An agent still producing reasoning tokens is alive and should not be aborted. As it stands the check penalises exactly the work it should protect — long-horizon analysis — while short search-shaped work never approaches the limit.
2. If a fixed window must exist, it should be configurable and consistent. One report documents a 600 s watchdog with an environment variable; these failures report 180 s with that variable unset. Whichever governs the Workflow path should be nameable and settable.
3. Retries should back off or stop. Six identical attempts with a 0% recovery rate is not resilience — it wastes about eighteen minutes and a concurrency slot per agent, and compounds the load that caused
4. The failure message should say which condition fired — waiting on the API, waiting on a tool, or reasoning. Those have entirely different fixes and are currently indistinguishable.
5. A killed agent should not be able to destroy completed work. Here a killed writer truncated a finished 204 KB document to 6 KB, because it had already opened the file. Partial output should be written to a draft path, or bannered, until the agent completes.

Error Messages/Logs

Steps to Reproduce

Not reproducible on demand; reproduces reliably during degraded periods. The shape that triggers it:

1. Open a session on a large local codebase (this one is a ~200k-line C++/JUCE tree).
2. Via the Workflow tool, dispatch 6–8 concurrent read-only subagents at xhigh effort on Opus, each given a brief of ~8 KB and told to read a 250 KB diff plus several 1000-line source files and return structured findings. Each agent's working context reaches 100k+ tokens.
3. Observe: a proportion make no tool call for 180 s and are killed. They are retried 6 times and fail identically every time — never partially, never recovering.

Control A — same session, same hour, different workload shape. Dispatch agents whose work is web search and fetch rather than local analysis. These complete normally. Search agents call a tool every few seconds; analysis agents think for tens of seconds between calls.

Control B — same task, shorter briefs. Take one brief that failed 6 attempts twice over (12 consecutive failures, zero output) and split it into 4 single-question briefs of ~1.5 KB. Same model, same effort, same minute — they complete first time.

Rate varies by day, not by workload. Identical scripts on the same machine: 22 Aug, 166 agent starts → 164 results. 25 Aug, 370 starts → 73.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.145

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

This has been occurring across multiple sessions for a couple of weeks now across many different Claude Code versions and continues to effect me to this day (08/27/2026). My current version is 2.1.247 and its still occurring. The above report comes from a session that just happened to capture it perfectly... then it took me a couple of days to submit.