claude-code - 💡(How to fix) Fix Persistent ECONNRESET (errno=0) on api.anthropic.com/v1/messages?beta=true — fails through all 10 retries [1 comments, 2 participants]

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:

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.
2. 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.
3. Direct curl to the same host succeeds with sub-100ms latency at the same time the SDK request is failing.
4. Other concurrent network activity is unaffected.
5. 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.