Persistent ECONNRESET (errno=0) on api.anthropic.com/v1/messages?beta=true — fails through all 10 retries

Summary

Claude Code intermittently fails with ECONNRESET on requests to
https://api.anthropic.com/v1/messages?beta=true. The error has errno: 0
(suggesting an HTTP/2 stream cancellation rather than a TCP-level reset) and
persists through all 10 retry attempts, surfacing to the user as
"API Error: Unable to connect to API (ECONNRESET)".

The issue has occurred across 151 distinct error events in 4 sessions over
a ~12 day period, spanning two Claude Code versions (2.1.114 and 2.1.126).

Environment

• Claude Code: 2.1.126 (also reproduced on 2.1.114)
• Node: v24.14.0
• macOS: 26.3.1 (build 25D2128)
• Network: home WiFi, no VPN, no proxy, no endpoint-security software
• Other devices on the same network: unaffected
• curl to api.anthropic.com from the same machine: succeeds in <100ms,

both IPv4 and IPv6

• DNS, /etc/hosts, NODE_OPTIONS, HTTP(S)_PROXY: all clean

Error event (from session log)

{
  "type": "system",
  "subtype": "api_error",
  "level": "error",
  "cause": {
    "code": "ECONNRESET",
    "path": "https://api.anthropic.com/v1/messages?beta=true",
    "errno": 0
  },
  "retryAttempt": 1,
  "maxRetries": 10,
  "version": "2.1.126"
}

All 151 error events share identical shape: code=ECONNRESET, errno=0,
same endpoint, no other distinguishing detail.

Failure pattern

In one heavily-affected session (132 errors), retry sequences played out as:

| Sequence ended at attempt | Count |
|---------------------------|-------|
| 5 | 1 |
| 6 | 1 |
| 9 | 1 |
| 10 (max — full failure) | 10 |

So 10 out of 13 retry sequences exhausted all attempts. Time between attempts
ranges from ~500ms (first retry) up to ~38s (later retries with exponential
backoff). The session itself stayed broken for 15+ hours — not a transient
network blip.

Why I believe this is server-side, not network-side

1. errno: 0 with code: ECONNRESET — a TCP-level reset from a network

middlebox produces errno: 54. errno: 0 typically indicates an HTTP/2
RST_STREAM from the peer.

1. 10/13 retry sequences fail at max retries. Real network blips would

succeed on retry 2 or 3. Failure persisting through 10 attempts with up
to 38s spacing rules out transient packet loss.

1. Direct curl to the same host succeeds with sub-100ms latency at the

same time the SDK request is failing.

1. Other concurrent network activity is unaffected.
2. **Other Claude Code projects on the same machine had only 1-2 transient

errors** during the same window; one specific long-running session
accounts for 132 of the 151 errors. This suggests the failure mode may
correlate with request size / context length / streaming duration rather
than connectivity.

What I tried that did NOT fix it

• NODE_OPTIONS="--dns-result-order=ipv4first" (force IPv4)
• Lowering interface MTU to 1400 (rule out path-MTU blackhole)
• Verifying no VPN, proxy, or endpoint-security software is interfering
• Verifying both IPv4 and IPv6 paths to api.anthropic.com work via curl

Suggested investigation

The combination of ?beta=true endpoint, errno: 0 ECONNRESET, persistence
across all retries, and concentration in one long-context session suggests
either:

• a server-side stream cancellation triggered by certain request

characteristics (large context window with Opus 4.7 1M, long streaming
duration), or

• an HTTP/2 client-side issue in the Anthropic SDK / undici handling of

RST_STREAM frames, or

• an account-tier-specific limit being enforced as stream cancellation

rather than a 429.

Happy to provide additional log context (sanitized) on request.