"API Error: The response stopped arriving" — 33 times in one day, zero on any prior day; error provides no attribution to diagnose it

Claude Code version: 2.1.246 (auto-updated from 2.1.227 the same morning)
Platform: Windows 11 Pro, 10.0.26200.9168 · Node v25.8.1 · npm 11.11.0
Model: claude-opus-5[1m] (1M context)

---

Summary

On 2026-08-26, Claude Code repeatedly terminated model responses mid-stream:

API Error: The response stopped arriving. The response above may be incomplete.

33 occurrences between 08:53:36Z and 18:26:21Z. The identical error appears zero times on any
previous day in this project's transcripts, which go back months.

Two related errors appeared the same day and never before:

API Error: No response from API                                                 (1x, 09:47:01Z)
API Error: Connection lost mid-response. The response above may be incomplete.  (1x, 13:18:00Z)

A third, distinct failure — the auto-mode permission classifier timing out and hard-blocking tool calls —
occurred 3 times (see "Secondary defect" below).

From the user's side all four present identically: work stops partway through, apparently at random,
several times an hour, for an entire working day.

Failure census

From ~/.claude/projects/<project>/**/*.jsonl, records where isApiErrorMessage is set:

| count | message | days seen |
|---|---|---|
| 33 | API Error: The response stopped arriving. The response above may be incomplete. | 2026-08-26 only |
| 3 | You've hit your monthly spend limit | 2026-07-29 only (unrelated) |
| 2 | Login expired · Please run /login | 2026-08-23, 2026-08-26 |
| 1 | API Error: No response from API | 2026-08-26 only |
| 1 | API Error: Connection lost mid-response. | 2026-08-26 only |

Plus 3 auto-mode classifier timeouts, recorded separately as tool errors.

Total distinct failure events on 2026-08-26: 38. Prior days: none of this class.

The recorded count is a floor — failures are being under-recorded

The 33 above are only the failures written to disk. Measured directly in one session:

| | |
|---|---|
| User-reported timeouts in one session, 18:36:08Z–20:01:02Z | 15 |
| API errors recorded in that window | 0 |
| Classifier errors recorded in that window | 1 (18:53:57Z) |
| Last response stopped arriving written to disk anywhere | 18:26:21Z |

During an 85-minute window with 15 user-visible interruptions, the transcript records one. The
true count for the day is therefore well above 38 — accurately stated, "at least 38, with a measured
14-of-15 under-recording rate in the one window where it was counted."

This compounds the primary bug: local logs cannot be used to reconstruct the incident, which is what both
self-diagnosis and support triage depend on.

Timeline

| time (UTC) | event |
|---|---|
| 2026-08-26T05:44:40.954Z | npm auto-update 2.1.227 → 2.1.246, outcome success |
| 2026-08-26T08:53:36.963Z | first response stopped arriving — 3h 9m after the update |
| 2026-08-26T18:26:21.018Z | last occurrence of the day |

No failure of this class exists anywhere in this machine's recorded history before the update.

Hypotheses tested and rejected

Recording these because the failure's presentation actively misleads, and each exclusion cost real time.

Local network fault — REJECTED by measurement

Measured while failures were still occurring:

| suspect | measurement | verdict |
|---|---|---|
| IPv6 / v4–v6 interaction | IPv6 unbound on the only adapter; no v6 address, no ::/0 route | eliminated — no IPv6 path existed while failures continued |
| Bandwidth to api.anthropic.com | 3 MB HTTPS POST: 10.1–11.6 MB/s | healthy |
| Packet loss | 2 retransmits in ~11,900 segments over six consecutive 3 MB POSTs | healthy |
| Connect / TLS | 6–8 ms connect, 15–22 ms TLS handshake | healthy |
| Bulk transfer | 92 MB npm package fetched, no stall | healthy |
| Proxy / MITM | no WinHTTP proxy, no WinINET proxy, no *_PROXY env | not a factor |
| Ephemeral ports | 101 of 16,384 in use | not a factor |
| Path MTU | real path MTU 1492 vs interface 1500, ICMP blackholed | real, but not implicated |

Caveat, stated honestly: these are bulk throughput tests. They do not exercise a long-lived
streaming connection with idle gaps, which is what actually fails. An attempt to test idle-connection
survival was inconclusive (the third-party endpoint used ignored its own delay parameter). This machine
sits behind carrier-grade NAT (100.64.0.0/10 at hop 2), so a NAT idle timeout on long-lived streams is
NOT excluded. This is the most important open question here.

The auto-mode classifier as primary cause — REJECTED

Two independent reasons:

1. It accounts for 3 of 38 failures.
2. Leaving auto mode did not stop the failures — direct experimental refutation.

"The 2.1.227 → 2.1.246 update introduced the classifier" — REJECTED

The 2.1.227 Windows binary was downloaded and string-compared against the installed 2.1.246 binary:

2.1.246 (installed):   "auto mode cannot determine the safety of"  x2
2.1.227 (downloaded):  "auto mode cannot determine the safety of"  x2

The classifier already existed in the version that had run without incident, so no downgrade was performed.

Scope limit: this disproves only that narrow claim. It says nothing about whether 2.1.246 changed
streaming or timeout handling, which is the behaviour that actually broke. A streaming regression in
2.1.246 remains an open and untested hypothesis.

Server-side signals — supportive but not conclusive

• One of four identical POSTs to api.anthropic.com returned HTTP 502 (the other three returned the

expected 401 for a deliberately invalid key).

• status.anthropic.com reported "All Systems Operational", page updated 2026-08-26T19:04:25.579Z,

no incidents listed — concurrent with the observed 502 and the ongoing failures.

Secondary defect — classifier timeout hard-blocks tool calls

Three times (14:45:58.356Z, 16:20:20.910Z, 18:53:57.975Z) a Bash tool call was refused outright:

claude-sonnet-5[1m] is temporarily unavailable (timed out), so auto mode cannot determine the
safety of Bash right now. [...] Note: reading files, searching code, and other read-only
operations do not require the classifier and can still be used.

When the permission classifier is unavailable, the tool call is blocked rather than degrading to the
ordinary interactive approval prompt. The user is present and able to approve; an advisory safety check
being unreachable should not stop work. The message also does not tell the user that leaving auto mode
restores full function.

Questions

1. Did streaming or stream-timeout behaviour change between 2.1.227 and 2.1.246? The single most

useful question. Correlation is strong (first failure 3h after auto-update; zero prior occurrences
ever) and it cannot be tested from outside.

1. When a response stops arriving, **can the client surface the request id, elapsed time, and whether the

stream was closed by the server, the client, or the socket?**

1. Does the failure correlate with 1M-context sessions or long generation times? All affected sessions

were claude-opus-5[1m], and failures clustered on long responses.

1. Why is a classifier timeout a hard block rather than a fallback to manual approval?
2. Why did the status page show all-operational while 502s were reproducible?

Requested changes

• Attribution in the error — request id, elapsed time, and who closed the stream. Without it this is

undiagnosable from the user side; here it produced two successive wrong root causes (first IPv6/MTU,
then the permission classifier), both of which were acted on before being caught and retracted.

• Graceful degradation for the classifier — fall back to the manual approval prompt, and name the

failing dependency in the message.

• Record every user-visible failure in the transcript. In one session the user observed ~6 timeouts

but only ~1 was written to that session's transcript, which makes self-diagnosis unreliable.

---

Update — 2026-08-27

The classifier hard-block recurred today on 2.1.247, one day after the fix shipped. At
2026-08-27 during an ordinary Bash call:

claude-sonnet-5[1m] is temporarily unavailable (timed out), so auto mode cannot determine
the safety of Bash right now.

This matters because the 2.1.246 changelog states:

"Fixed auto mode tool calls being denied as 'temporarily unavailable' on very large sessions by scaling the safety-check deadline with prompt size"

The three occurrences on 2026-08-26 listed above were already running 2.1.246 — the machine
auto-updated to it at 05:44:40Z, before the first failure. Today's occurrence was on 2.1.247, in a
session with a small prompt (~40 transcript records at the time). Deadline-scaling by prompt size
therefore does not cover this failure: it fires on small sessions too, which suggests the timeout is
in reaching the classifier model rather than in the size of what it is asked to classify.

The primary request stands unchanged: fall back to the manual approval prompt instead of blocking.

Related issues

Cross-referencing rather than duplicating:

• #88900 — streaming stalls after 0.5–2.7 KB triggering the 180s byte-watchdog. Closest match to the

primary defect here; open with no response. This report adds a Windows datapoint and the
under-recording measurement.

• #67766 — socket closed mid-stream, with packet captures showing a server-initiated FIN. Open since

2026-06-12.

• #87972 — Stop hooks do not fire on stall-terminated turns; a downstream consequence of the same

failure.

• #87246 — closed not planned on 2026-08-18, the same day a detailed repro was posted to it

(≈50% subagent mortality, with completed work discarded).

The distinct contribution of this report is the under-recording rate: 15 user-visible
interruptions in one 85-minute window produced 1 transcript record. If that ratio generalizes,
server-side telemetry for this failure class is undercounting it by roughly an order of magnitude.