[Bug] Anthropic API Error: Response stalled mid-stream - step change 700x rate on 2026-07-26

Bug Description

API Error: Response stalled mid-stream - dated onset 26 Jul 2026, with local causes ruled out

Related: #70840 (closed as duplicate), #69415

Summary

"API Error: Response stalled mid-stream" went from effectively nonexistent to routine on my machine
overnight on 2026-07-26, with no corresponding change to my client version, model, context sizes, or
network. I scanned my full local session transcript history (3.5 GB, ~200k assistant messages) to
normalise the rate and eliminate local variables. Posting the numbers because the tracked issue
appears to have no published root cause.

Onset

Stall count per day, normalised against assistant-message volume from the same transcripts:

| Period | Stalls | Assistant msgs | Rate per 1k |
|---|---|---|---|
| 7 Jul - 25 Jul | 3 | ~193,200 | 0.016 |
| 26 Jul | 81 | 7,645 | 10.6 |
| 27 Jul (partial day) | 30 | 1,836 | 16.3 |

A step change of roughly 700x, not a drift. The 3 baseline events were single isolated stalls on
7 Jul and 12 Jul.

It arrives in bursts, not uniformly

Stalls per hour:

• 2026-07-26 13:00 - 32 stalls
• 2026-07-26 14:00 - 15
• 2026-07-26 23:00 - 11
• 2026-07-27 10:00 - 29 stalls

with multi-hour quiet stretches in between, during continuous heavy use.

Local variables ruled out

Client version is not the trigger. 2.1.220 first went live for me at 2026-07-25T08:12:29Z. It ran
10,668 transcript entries on 25 Jul with zero stalls. Stalls began the next morning on the same
binary.

Older versions stall too, concurrently. Client version stamped on stalling entries:

79  2.1.220
 2  2.1.218
 2  2.1.201
 1  2.1.205

2.1.218 was actively running on 26 Jul (318 entries in the 13:00 hour, the same hour as the 32-stall
burst) and stalled as well. Two client versions running side by side that afternoon, both affected.
#70840 was also filed from 2.1.191.

Context size is not the trigger. I run 1M-context sessions daily. Distribution per day:

| Day | median ctx | p90 | max | % >200k | Stalls |
|---|---|---|---|---|---|
| 21 Jul | 453k | 829k | 989k | 75.5% | 0 |
| 24 Jul | 247k | 762k | 999k | 53.8% | 0 |
| 25 Jul | 338k | 840k | 999k | 59.3% | 0 |
| 26 Jul | 192k | 553k | 882k | 48.4% | 81 |
| 27 Jul | 386k | 757k | 970k | 62.9% | 30 |

26 Jul had smaller contexts than 25 Jul and 81 more stalls.

Model switch is not the trigger. I moved to claude-opus-5 on 25 Jul: 4,961 messages that day,
zero stalls. Stalls are predominantly on claude-opus-5 because that is what I now run, but
claude-opus-4-8 entries also stall during the affected window, so it is not exclusive to Opus 5.

Network is not the trigger. Since boot, netstat -s -p tcp reports 0 retransmits, 0 resets,
0 keepalive timeouts, 0 connections dropped by retransmit or persist timeout. Route to
api.anthropic.com resolves direct over en0, MTU 1500, RTT 46ms, not through any VPN tunnel.
A link or tunnel severing long-lived streams would leave a trace in these counters. There is none.

Environment

• Claude Code 2.1.220 (native install), macOS 25.5.0 arm64, node v23.11.0
• Model opus[1m], effortLevel: xhigh, alwaysThinkingEnabled: true
• Long-running interactive sessions, typically several hours

What would help

Given every client-side variable is eliminated by a same-machine A/B across the onset boundary, the
change appears to be in the serving path rather than the client. If that is known and tracked
elsewhere, a pointer to the tracking issue would be useful, since #70840 was closed as a duplicate
without one.

If it helps narrow things, I can supply per-request timings or the hourly stall distribution over a
longer window.

Method

Counts extracted from ~/.claude/projects/**/*.jsonl by matching the literal error string and the
timestamp, version, model, and token-usage fields on surrounding entries. Rates are per
assistant message from the same files, so volume changes between days are accounted for. Per-turn
model attribution uses the nearest preceding model field and is approximate; the version, date,
and context-size figures are exact.

Environment Info

• Platform: darwin
• Terminal: iTerm.app
• Version: 2.1.220
• Feedback ID: e8ccc35d-5280-4fc8-9276-91c137e67eac

Errors

[]