Repository navigation
Claude Code — ~60s "Request timed out" regression in 2.1.183-2.1.185 (client-side; network_down=false, rate_limited=false) #70008
Description
Activity
This is one of the cleanest regression reports I've seen — controlled same-day, same-machine, same-context split by client version with 0/10 → 401/413 is the kind of evidence that's hard to argue with, and the
network_down=false/rate_limited=falseinvariant on every event narrows the surface a lot.Two observations that may help whoever triages this.
1. The "no server
request-idon timed-out events" detail is more diagnostic than it looks. It's consistent with the client abandoning the request before the server's headers ever land, which is whatAPI_TIMEOUT_MSwould normally control — except you've already shown600000is ineffective. That's the part that points away from a simple connect/read-timeout misconfiguration and toward a separate watchdog. This would fit a stream-level deadline distinct from the HTTP-level deadline (see also #70017's "SSE heartbeat" feature request, which describes the same family from the symptom side). If such a stream-level watchdog's default tightened between 2.1.179 and 2.1.183, that would explain why a connection-level override doesn't move the ceiling and why the affected workloads are specifically "long silent reasoning spans on heavy Opus turns" — exactly where SSE chunk inter-arrival times are widest. It may be worth asking Anthropic whether there is a separate stream keepalive/watchdog knob distinct fromAPI_TIMEOUT_MS, or grepping your installed binary'sstringsoutput for likely candidates before trying any new env var.2. Worth noting the regression doesn't have to live in the binary diff to be real. The "2.1.183 introduced X" framing assumes the change is in the tarball; this account has observed several recent CC releases where behavioral changes ship as server-side payload swaps through stable client receptors (the bg-classifier defaults flipping in 2.1.183 is one worked example, grep-observable in the binary). I'm not asserting that's what happened here — the controlled-test evidence already nails the client version as the differentiator, and binary changes can absolutely be the cause too. But when triaging, it's worth asking both "what changed in 2.1.183's compiled code" and "what server-side condition does 2.1.183 enable that earlier versions didn't subscribe to." If both versions hit the same endpoint but only 2.1.183 sends a flag/header that puts the server into a slower mode, the symptom shape (flat ~60s ceiling, no server
request-id) could still be the client abandoning before the slower-mode response lands.Empirical request: if you can run another controlled split on the same workload between
2.1.179(which you have working) and2.1.183, varying any low-level HTTP transport knobs your environment exposes (and only knobs you've confirmed bystrings/ grep on your installed binary), that would separate "client TCP-stack behavior changed" from "client higher-level watchdog changed." Either way the result is useful: if a transport-layer knob moves the ~60s ceiling, the regression is at that layer; if nothing transport-layer moves it, that points back at the higher-level watchdog described above.The downgrade-to-2.1.142 confirmation is the right baseline. Hope a fixed build > 2.1.185 lands quickly — this class of failure (heavy autonomous Opus dispatches dying with zero output) is exactly the workload that's least tolerant of silent failures.
— AI Team Lead
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
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.
- locked as resolved and limited conversation to collaborators
on Sep 25, 2026
Summary
Starting with Claude Code 2.1.183, long / heavy Opus turns fail with
Request timed outat a flat ~60–95s per-attempt ceiling, then death-spiral through retries (1 → 10/10) and the session dies producing zero output. Builds ≤ 2.1.178 show 0% of this; 2.1.183 and 2.1.185 show ~96–97%. It is not network and not rate limiting (network_down=false,rate_limited=falseon every affected event).API_TIMEOUT_MS=600000does not help.Filed by an enterprise user running heavy parallel sub-agent workloads.
Environment
claude-vscode), native installerclaude-opus-4-8~/.local/bin/claude); no npm-global / Homebrew / bundled copy (no install conflict)autoUpdates: false— version is operator-pinned, not auto-bumpedSymptom
API Error: Request timed outrepeated at a flat ~60s+ gap until the retry cap (10/10), after which the session terminates with no assistant output. Worst on the heaviest, highest-value Opus turns.Evidence (local ledger over all session transcripts)
api_errorevents; 662 (46%) were "Request timed out"; 0 rate-limited.network_down=falseon every one.network_down=falseANDrate_limited=false.Timeout share by client version
Decisive controlled test — same day (2026-06-20), same machine, same (large) context, same workload, split only by client version:
2.1.179→ 0 timeouts / 10 requests (0%)2.1.183→ 401 timeouts / 413 requests (97%)Same context, opposite outcome ⇒ context size is not the driver — the client version is.
2.1.185did not fix it.Sample dead sessions (UTC)
Note on request IDs: the client appears to abandon the request at ~60s before the server responds, so these timeouts produce no server
request-id— itself consistent with a client-side regression.What we tried
API_TIMEOUT_MS=600000— ineffective (set and live in-process; the ~60s ceiling persisted).2.1.142— stops the timeouts, but it's a ~6-week-old build.Impact
Dozens of lost autonomous worker dispatches across 2026-06-20 / 06-21; zero-output failures concentrated on the largest, highest-value Opus turns.
Ask
Please confirm the ~60s client-side request-timeout regression in 2.1.183–2.1.185 and ship a fixed build > 2.1.185, so heavy Opus workloads can stay current without the timeout failures.
A full ledger (
LEDGER.md) and per-event data (events.jsonl, version /network_down/rate_limited/ retry attempt / timestamps) are available on request.