[BUG] API Error 500 (no body) on Opus 4.7 with 1M context, intermittent across different requests
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?
Persistent intermittent 500 errors throughout a single session. Roughly 50% failure rate per request. Failures hit different requests rather than the same one looping, so this is not a poisoned tool result or stuck session state. Retries eventually succeed (typically attempt 2 or 3 of 10), then the next turn fails again (10/10) and shows the full API 500 error message. /login reauth noticeably improved the success rate but did not eliminate the failures.
The in product /feedback command also returns 500, which is why I'm filing here instead of through feedback.
A separate Claude.ai web session briefly wobbled at the same time, suggesting the issue may extend past just the Opus 4.7 1M pool.
What Should Happen?
Requests to Claude Code complete successfully within normal latency. Retries should not be needed for routine requests on a healthy session with low context usage.
Error Messages/Logs
API Error: 500 status code (no body). This is a server-side issue, usually temporary, try again in a moment. If it persists, check status.claude.com.
Couldn't send feedback (server returned 500). If it keeps failing, you can file at https://github.com/anthropics/claude-code/issues instead.Steps to Reproduce
Not reliably reproducible on demand. The failure correlates with periods when the Opus 4.7 backend pool is strained (see "Additional Information" for related incident history).
Approximate setup at time of failure:
Start a Claude Code session on a Claude Max account, default model (Opus 4.7 with 1M context)
Work normally, including parallel subagents and MCP tool calls
Around 32% context usage, requests begin returning 500 (no body) intermittently
Retries succeed after 2 to 3 attempts; failures resume on subsequent turns
/feedback also returns 500
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
2.1.146
Claude Code Version
2.1.146
Platform
Anthropic API
Operating System
macOS
Terminal/Shell
Other
Additional Information
Using Ghostty
Status page (status.claude.com) showed no incidents at time of failure, but Opus 4.7 has had "Elevated errors" incidents recurringly over the past two weeks (May 20, 19, 18, 14, 12, 8, 7). Likely the same underlying issue not yet crossing the public reporting threshold today.
Happy to provide session ID privately if useful for diagnosis. Omitting here for privacy.
6 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Constantly happens in my sessions too.
Also struggling with this. Hard to tell, but it seems like starting a new session gets things back in gear. Same setup-ish as OP, Claude Max, ghostty
Same here, on two independent accounts (one is Max / one is Team).
I can confirm that starting a new session "solves" the problem, until you hit that ~32% mark again.
UPDATE (1 June 2026): Resolved — this turned out to be local to my machine, not server-side.
A full laptop reboot cleared it completely. Across the 24 hours of normal use since, the connection resets went from ~250 in the final afternoon to zero (verified against the same
claude --debug apilogs). The most likely cause was a wedged network/daemon state after a long uptime on this Mac; the same reboot also cleared an unrelated stuck local tool, which points to a machine-wide state issue rather than anything upstream. The cross-network reproduction below misled me: the constant across all those networks was my laptop carrying the wedge, not my account. Apologies for the premature "client fully ruled out / server-side" conclusion.Caveat: the extended-thinking 400 ("thinking/redacted_thinking blocks cannot be modified", #63213 / #63335 / #64213) does persist after the reboot and looks like a genuinely separate upstream bug.
_Original report below, left intact for the record._
---
Adding fresh, instrumented data from today (2026-05-31), captured with
claude --debug api(Claude Code v2.1.158, macOS, Max/Opus). Updated after ~4 hours of debugging across multiple networks.TL;DR: It is not a connect failure and not a client-side network/software issue (ruled out exhaustively below). Requests connect fine and begin streaming, then stall mid-generation (no tokens for 15s, then 30s), then the socket is reset —
ECONNRESET, surfaced asAPI Error: Unable to connect to API (ECONNRESET). The empty-body 500 appears to be the variant where this fails at/near the start of the stream instead of mid-stream.1. Low context, not 1M. At ~14% context utilization on small
repl_main_threadrequests, well below the 1M window. The request-size / 1M-fleet angle does not explain it here.2. Mid-stream stall → reset, confirmed.
[Stall] stream_idle_partial lastChunkAgeMs≈15000, then≈30000— no tokens for 15s/30s at a time.API error (attempt N/11): undefined Connection error.(SDK-wrappedECONNRESET; no HTTP status, no body, no serverrequest_id).ECONNRESETsimultaneously hits first-party and OTEL telemetry exports, i.e. long-lived/streaming connections specifically.3. Client side fully ruled out. The exact same failure reproduces identically across every combination of:
lsof).curl https://api.anthropic.com/v1/messagessucceeds 12/12 (clean 401s), and a 50 MB Cloudflare download completes clean at ~8 MB/s. So the pipe handles big sustained transfers fine — only api.anthropic.com streaming stalls.That eliminates local network, ISP, region/PoP, VPN, firewall, DNS, MTU, and proxy. The only invariant across all of it is the account hitting the backend.
4. Auto-recovery degrades within a window. Early in the burst these cleared by attempt ~4 of 11. Later, single requests burned the entire ladder before giving up:
On the final retry the payload also trips the separate "thinking/redacted_thinking blocks cannot be modified" 400 (#63213, #63335, #64213), so the two compound: reset → retry → 400 → strip-and-retry.
96 such resets between 16:10 and 20:12 UTC today, still ongoing (~4h window, far longer than the usual ~1h). No server
request_idon these (the response never forms), so the only correlation handle is the client-request-id + UTC timestamp. Representative sample from the 18:23–18:24 cluster:<details>
<summary>Full list of all 96 connection-reset client-request-ids (2026-05-31 UTC, snapshot — burst still ongoing)</summary>
</details>
Suggested reframing: mid-stream generation stalls that culminate in a connection reset (
ECONNRESET), server-side, with the empty-body 500 being the start-of-stream variant of the same failure. Happy to share raw[Stall]→ECONNRESETdebug excerpts.This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.