A stream idle timeout means the response stopped delivering data long enough for a timeout to interrupt it. Start with a smaller request, preserve completed work, and retry. Changing models or compacting the conversation has also helped some users.
The message API Error: Stream idle timeout - partial response received can appear after Claude has already produced part of an answer. Partial output deserves attention before another attempt, especially if files may have changed.
A clear recovery plan starts by separating an interrupted response from a request that never begins.
Key Takeaways
- Reduce large requests and ask Claude to complete one clear step at a time.
- Switching models, running
/compact, and extending a reported client timeout have helped individual users, but results vary. - Record the failure pattern and request ID; these timeouts and infrastructure proxy timeouts require different troubleshooting.
What a Claude Code stream idle timeout means
Users have reported the error in the CLI, desktop app, web interface, and mobile app. The wording describes an interrupted stream but doesn’t identify its cause.
The response starts, then stops
A GitHub bug report describes about 5 KB of partial response, followed by 180 seconds without server data. The client’s byte watchdog then aborts the stream.
That 180-second interval applies to the reported failure. It isn’t a universal timeout across every Claude application.
The reporter reproduced problems on versions 2.1.177, 2.1.178, and 2.1.179, using the OAuth CLI on a VPS. Haiku, Sonnet, and Opus were affected at every tested context size.
The first response takes too long
The same issue describes a separate slow-first-byte problem. About one in four requests waited 30 seconds or more for initial data.
Many failed at roughly eight minutes with undefined Connection error. This differs from receiving partial output and then losing the stream. Recording that distinction keeps troubleshooting focused.
Break large requests into manageable steps
A focused request gives Claude a clearer scope and makes interrupted work easier to recover. Reddit users reported improvements after separating large tasks and reducing the amount of work requested in each response.
Long reasoning and oversized requests are reported explanations, not established causes. Smaller tasks remain a practical workaround because they reduce the amount that must succeed in one attempt.
Ask for smaller file-writing chunks
Instead of requesting an entire multi-file change, ask Claude to complete one file or one defined portion first. Review the result before requesting the next portion.
One reported workaround was to write files over five attempts rather than one long response. The useful principle is manageable scope; five isn’t a required setting or guaranteed threshold.
Give each request a clear stopping point. Naming the file, intended change, and expected result supports more organized progress than repeatedly retrying the original instruction.
Separate analysis, edits, and review
Keep planning, implementation, and review as separate requests when a task repeatedly stalls. This makes it easier to identify where progress stops and which work remains unfinished.
Other Reddit users reported success asking Claude to use a subagent or complete the write through a small Python script under 200 lines.
These are individual workarounds. Before continuing, inspect the existing files and changes so the next attempt doesn’t repeat completed work or overwrite something useful.
Compact the conversation or change models
Session context and model selection are reasonable next adjustments when smaller requests still fail. Change one factor at a time so a successful attempt provides useful information.
Repeatedly changing the prompt, model, and connection together makes the outcome harder to interpret.
Use /compact or begin a fresh session
In the CLI, /compact reduces the conversation history carried forward. Reddit users reported that this helped some interrupted sessions continue.
Compaction doesn’t reduce the scope of the requested work. Pair it with a focused next step rather than repeating an oversized instruction unchanged.
Refreshing the application or starting a new session also helped some users. Preserve the current objective, completed changes, and remaining work before restarting, so recovery doesn’t depend on reconstructing the conversation.
Try Sonnet instead of Opus
Switching from Opus to Sonnet resolved the stream idle timeout for some Reddit users, but others continued experiencing it. The reports don’t establish that it works for most users.
Output quality may drop, depending on the task. Review generated changes with the same care after switching.
For a useful comparison, retry the same smaller request with the new model. A successful response shows that the attempt completed; it doesn’t establish why the earlier one failed.
Try the reported Claude Code timeout setting
One Reddit user reported success setting CLAUDE_STREAM_IDLE_TIMEOUT_MS to 600000 in the env block of ~/.claude/settings.json.
The file is under your home directory. The value is in milliseconds, so 600000 equals 10 minutes.
The setting is intended to increase the client’s tolerance for periods without incoming stream data. One user reported success, so don’t treat it as a dependable fix for every version or failure pattern.
To apply the reported configuration:
- Back up
~/.claude/settings.jsonbefore editing it. - Add
"CLAUDE_STREAM_IDLE_TIMEOUT_MS": "600000"inside the existing"env"object, preserving other entries. - Save valid JSON, restart the application, and retry a small request.
If the file contains no other settings, the configuration is {"env":{"CLAUDE_STREAM_IDLE_TIMEOUT_MS":"600000"}}. Don’t replace an existing configuration with that minimal object, because doing so would remove its other settings.
A longer timeout allows more waiting. It doesn’t make a stalled service generate data, and the report doesn’t establish that this variable addresses slow-first-byte failures.
Extending the waiting period changes when an attempt may be abandoned; it doesn’t demonstrate that the interrupted stream has recovered.
Assess network and service behavior separately
The error alone can’t distinguish a local connection problem, an issue along the network path, or silence at the remote service. Evidence about actual traffic is more useful than the timeout message by itself.
What the packet capture showed
During a stall lasting more than six minutes, the GitHub reporter captured eight seconds of traffic with tcpdump. The capture contained zero packets while the socket remained ESTABLISHED with empty queues.
The reporter interpreted this as evidence of server-side silence. It supports that interpretation for the observed interval, but doesn’t establish a cause for every user’s timeout.
An established socket confirms that the connection remained open. It doesn’t guarantee that response data is moving across it.
What changing the network route showed
The same reporter routed outgoing traffic through a Tailscale exit node, changing the source IP and connection path. Mid-stream stalls disappeared in that setup.
Slow-first-byte failures continued. That distinction matters: the network change helped one reported symptom without resolving the other.
For recurring failures, a comparison using another permitted connection can provide useful evidence. Keep the request and model consistent, and record whether the change affects initial response time, mid-stream interruptions, or neither.
Preserve a useful record for support
Good diagnostic information starts with the exact error, the application, and the point where progress stopped. For the CLI, include the version, model, approximate waiting time, and whether partial output arrived.
Also record what changed between attempts. Smaller requests, a fresh session, another model, or another connection are more informative when their outcomes are documented separately.
The GitHub report says failed-request error lines include a request ID and a message asking users to give it to the API team for server-log lookup. Preserve that identifier alongside the error timestamp.
Keep the report focused on reproducible behavior. Remove credentials and private project content before sharing logs; the request ID and observed timing are more useful than an unsupported conclusion about the cause.
Know when proxy timeout settings apply
Envoy, Istio, AWS Application Load Balancer, and MuleSoft use related timeout terminology. Their configuration values belong to infrastructure components, not the reported client watchdog.
Envoy timers measure different stages
Its documented defaults distinguish stream inactivity, connection inactivity, request completion, and upstream connection establishment.
| Envoy setting | Default | What it measures |
|---|---|---|
stream_idle_timeout | 5 minutes | Inactivity within an HTTP stream |
HTTP idle_timeout | 1 hour | Connection inactivity without active requests |
| Route timeout | 15 seconds | Time allowed for the upstream response |
Cluster connect_timeout | 5 seconds | Upstream connection establishment, including TLS when applicable |
These values aren’t interchangeable. Increasing a connection timer won’t necessarily address a route timeout or an inactive stream.
For idle closures, relevant stats include downstream_cx_idle_timeout and upstream_cx_idle_timeout. Their Prometheus names are envoy_http_downstream_cx_idle_timeout and envoy_cluster_upstream_cx_idle_timeout.
Load balancers, MuleSoft, and Istio need separate attention
AWS ALB defaults to a 60-second idle timeout. OneUptime suggests a higher application or gateway idle timeout, such as 65 seconds. That setting doesn’t extend the ALB’s own limit.
MuleSoft’s Stream Idle Timeout policy defaults to 300 seconds. Exceeding it returns HTTP 504 with Stream timeout, a different error from Claude’s partial-response message.
A ServerFault question about Istio 1.2.5 reported an ineffective TCP idle_timeout EnvoyFilter whose filter was absent from the configuration dump. An absent filter means the intended configuration wasn’t visible in that dump; the report doesn’t establish why it was missing.
Frequently Asked Questions
Does a partial-response error mean my files are unchanged?
The error doesn’t establish whether a file operation completed. Review the files and existing changes before asking Claude to continue.
Resume from the last confirmed result rather than automatically repeating the entire request. This keeps recovery organized and reduces duplicate work.
Can I use the timeout setting in the browser or mobile app?
The reported environment-variable workaround belongs in the local settings.json configuration. It isn’t a browser or mobile application setting.
For those interfaces, reported recovery options include refreshing, starting a new conversation, changing models where available, and reducing the scope of the request.
Restore Progress With Focused Requests
Recovering from a stream idle timeout starts with preserving completed work and choosing a smaller next step. Model changes, session resets, and timeout adjustments are reported options, not dependable repairs.
Keep mid-stream stalls separate from slow-first-byte failures. A clear record of timing, attempted changes, and request IDs makes continued troubleshooting more useful and helps you resume work without unnecessary repetition.