If Claude Code shows Stream idle timeout - partial response received, do not treat it like a generic Anthropic API error code. For most readers this is a stalled Claude Code stream, so the first useful move is to confirm the surface and version before you touch timeout settings.
If you are below Claude Code 2.1.105, update first. If you are already current, split the problem into a live status or login incident, a long write that stalled after partial progress, a route or auth mismatch, or a direct Anthropic API integration that needs streaming recovery instead of Claude Code-only settings.
Use the smallest branch-specific move next: wait through live incidents, retry smaller on the same route after heavy-output stalls, inspect /status and environment variables when the route might not be what you think, and switch direct API builds to Anthropic's streaming recovery playbook.
After that one move, rerun the same task on the same intended route. If the stall survives, stop widening the experiment and capture version, route, status timing, and any request_id before you escalate.
This page stays narrower than the 500, 529, usage-limit, and install guides because the reader job here is exact stalled-stream recovery, not a broad anthology of Claude or Anthropic timeout problems.
30-Second Route Board
Stream idle timeout - partial response received is a routing problem before it is a theory problem. The question is not "what can time out in general?" It is "which branch am I in right now, and what is the smallest correct move?" That distinction is the whole value of this page.
Anthropic's current API error documentation does not list this phrase as one of the standard API error families. Claude Code's own environment variable docs and changelog are more useful because they describe stalled-stream behavior, watchdog thresholds, and the 2.1.105 change that affects what "update first" means here.
| What you are seeing | Most likely owner | Safest first move | Verify on the same route | Escalate when |
|---|---|---|---|---|
| You are below Claude Code 2.1.105 | Older stalled-stream behavior before the current improvement | Update Claude Code before you change timeouts or routes | Rerun the same task on the updated version and same route | The current version still shows the same symptom |
| Claude Status or login surfaces are degraded right now | Anthropic-side service or auth incident | Stop changing local settings and wait through the incident window | Retry the same route after the incident clears | Status is green again and the same route still stalls |
| The failure came after visible partial progress in a long write or refined plan | Heavy-output stall or session-pressure branch | Retry smaller on the same route or start a fresh session | Confirm smaller same-route work completes | Smaller same-route retries still stall |
| The route or auth surface may not be the one you think | API-key override, proxy or provider route, or unexpected auth owner | Check /status, active auth, and environment variables before interpreting the symptom | Compare the same task on the intended route | The intended route still stalls with current evidence |
| You built the Anthropic API integration directly | Builder-side streaming interruption, not a Claude Code runtime branch | Use Anthropic streaming recovery, keep-alive, or batch controls | Resume or reissue on the same integration with preserved output | The same direct integration still fails after transport-level mitigation |
That table is the page. Everything else exists to help you choose the right row more confidently. The biggest mistake is skipping the branch step and applying a universal ritual: turning up timeouts, logging out, reinstalling, switching providers, or repeating the same oversized task without learning anything.
Update First If You Are Below 2.1.105
The version threshold matters because the Claude Code product behavior changed. The Claude Code changelog, checked on April 14, 2026, says version 2.1.105 aborts stalled API streams after five minutes of no data and retries in non-streaming mode. That makes "update first" a real troubleshooting branch, not trivia you can leave for later.
The environment variable docs reinforce the same point from a different angle. They expose a five-minute default for CLAUDE_STREAM_IDLE_TIMEOUT_MS, describe the byte watchdog for direct Anthropic connections, and document a separate stream watchdog toggle for Bedrock, Vertex, and Foundry routes. That is useful context, but it is not a reason to start hand-tuning timeouts on an older build before you have even tested the current behavior.
This is where a lot of advice goes wrong. Readers see a timeout string, assume a timeout knob must be the main answer, and start changing variables too early. That can work eventually and still be the wrong first move. If the product already changed its stalled-stream handling in the current version, you want to test that cheaper and cleaner explanation before you create a pile of local configuration changes you may have to undo later.
Updating is not a universal fix promise. It is an early filter. If you upgrade and the exact same task on the same route still stalls, move on. Do not turn 2.1.105 into folklore. Its value is that it changes the first test, not that it magically explains every future interruption.
If Claude Status or Login Incidents Are Active
Start with the live Claude Status page because it can save you from a lot of pointless local experimentation. If Claude Code, authentication, or related components are degraded when you check them, the smartest short-term move is usually to stop changing local settings and wait for recovery before you rerun the same path.
The same caution applies to login degradation. If the symptom appears while Claude is authenticating, reauthorizing, or trying to resume a session during a broader login problem, you are not in the same branch as a healthy-route heavy-output stall. A red status page changes the value of every local fix you were about to try. Reauthenticating, reinstalling, or changing timeout settings during a live incident mostly produces noise.
What matters in this branch is discipline. Note the time. Keep the exact error text. Preserve any request_id or session evidence you already have. Then rerun the same path after the incident clears. The same-route retry matters because it tells you whether the incident was the whole story or only the first visible symptom.
Do not let this branch become the whole article. A live incident is one real cause of stalled streams. It is not the only one. Once status is healthy again, the question changes from "is Anthropic degraded right now?" to "does this exact path still stall after the provider-side branch has cleared?"
If the Stall Happened During a Long Write, Refined Plan, or Heavy-Output Turn
Partial progress is a clue. If Claude produced some output, then stalled, then surfaced partial response received, you should treat that as a heavy-turn branch before you jump to auth, provider, or pricing explanations. It does not prove a universal root cause. It does tell you the cheapest next test is usually a smaller task on the same route.
That is consistent with the pattern in recent official anthropics/claude-code issue reports such as #47252 and #47385, where the exact symptom appeared after long or partially completed turns. Those issues are useful because they show the branch is real. They are not proof that every stalled stream comes from one bug. The page should use them as operational nuance, not as a total explanation.
The safest first move here is deliberately small. Ask for a smaller chunk. Narrow the task. If the session feels overloaded or confused, start a fresh session instead of hammering the exact same oversized turn again. What you should not do first is change three major variables at once. If you swap routes, auth, and task shape simultaneously, you lose the one clean signal you need: whether smaller same-route work succeeds.
This is also where the page earns its separation from the 500 and 529 siblings. Those pages are about exact error-code recovery. This one is about an interrupted stream that may have already produced useful content before it stalled. The recovery logic is different because the clue is different.
If the Route or Auth Surface Is Not What You Think
Claude Code troubleshooting gets messy when the tool is using a different contract than the one you think you are testing. That is why /status belongs so early in the process. It tells you which auth method is active. Anthropic's authentication docs also spell out an important surface rule: Claude Code on the web always uses subscription credentials, while local CLI sessions can be affected by API keys and related environment variables.
That difference matters because local timeout or route tweaks are not equally relevant everywhere. If ANTHROPIC_API_KEY is set in a local shell, Claude Code may be using that path instead of the subscription route you had in mind. If you are in a browser or remote web surface, local shell variables are not the first place to look. Misreading the surface is how readers end up applying technically correct advice to the wrong environment.
The environment variable docs are useful here too, mostly as a warning against random tuning. CLAUDE_STREAM_IDLE_TIMEOUT_MS, CLAUDE_ENABLE_BYTE_WATCHDOG, and CLAUDE_ENABLE_STREAM_WATCHDOG are route-sensitive knobs. They are not generic proof that you should start stretching idle windows. If you have not even confirmed which auth owner or provider route is active, changing them is just guesswork with more steps.
The right test is boring and that is why it works: inspect /status, confirm the auth method, check for route-changing environment variables, and rerun the same task on the intended route. If the symptom disappears after you correct the route, you learned something valuable. If the same intended route still stalls, you now have a better support case than "timeout happened and I changed some settings."
If You Actually Built the Anthropic API Integration Yourself
This page should let the wrong reader leave cleanly. If you are not using Claude Code as the main execution surface, and instead built the Anthropic Messages API integration yourself, stop copying Claude Code-only settings into that environment. The symptom may look similar, but the recovery playbook is different.
Anthropic's streaming documentation and API error docs are the right sources for this branch. They are where you should think about streaming interruption, reconnect logic, keep-alive behavior, and whether batch processing is a better fit than one long interactive stream. They are also where request-id handling and transport-level recovery make more sense than CLI route advice.
The practical rule is simple. If you built the integration, use builder-side recovery tools. Preserve the accumulated output you already received. Resume or reissue on the same integration with a cleaner transport strategy. Do not assume that Claude Code watchdog variables are the main answer just because the wording feels familiar.
That route-out is part of the page's value. It keeps direct API builders from wasting time inside the wrong product frame, and it keeps Claude Code end users from being dragged into SDK-level recovery theory they do not need.
Verify the Fix and Know When to Escalate
The quality of your verification matters more than the number of times you retry. A good verification step is narrow: rerun the same task on the same intended route after one branch-specific fix. A bad verification step changes version, auth, route, and task shape together and then tells you nothing when the result changes.
Before you escalate, capture the smallest useful evidence package from the same failing path:
- Claude Code version, including whether you already updated past 2.1.105
- the active auth method and route from
/status, plus any route-changing environment variables - what Claude Status showed at the time
- the exact error text and any
request_id - whether the failure followed partial progress in a long turn or happened before meaningful output
That bundle is short on purpose. A giant narrative of every idea you tried is less useful than one clear reproduction story. "Current version, green status, same route, smaller retry still stalls, request_id attached" is actionable. "It timed out a few times and I changed a lot of things" is not.
This is also the right place to route out to sibling pages when the branch changes. If the exact code is really 529, use the dedicated Claude Code overloaded error guide. If the actual problem is 500, use the Claude Code API error 500 guide. If the deeper complaint is fast consumption or shared-limit drain, switch to the Claude Code usage limits guide. If the real issue is still setup and prerequisites, the better page is the Claude Code install guide.
The escalation boundary is explicit: if the same route still stalls after the smallest correct branch-specific fix, stop improvising. At that point you are more likely to make the story noisier than to make the product healthier.
Frequently Asked Questions
Does updating to 2.1.105 fix every partial response received failure?
No. It changes the first move and is worth testing early, but it is not a universal promise. If the current version still stalls, move to the incident, heavy-turn, or route branches instead of repeating the version story.
Do local environment variables affect Claude Code on the web?
No. Anthropic's auth docs say Claude Code on the web always uses subscription credentials. Local shell variables matter for local CLI or other local routes, not for the web surface.
Is this the same as a 500, 529, or 504 page?
No. This page is intentionally narrower. It is about an exact stalled-stream symptom and the safest next move after that symptom appears. If the exact error family changes, switch pages early instead of forcing one guide to do every job.
When should direct API builders stop reading this page?
As soon as it is clear that Claude Code is not the main surface and the integration is your own. At that point, Anthropic's streaming and API error docs are the better playbook.
The Working Rule
Stream idle timeout - partial response received usually means "treat this as a stalled Claude Code stream first, not as a generic API-code family." Confirm the surface and version, choose one branch-specific move, verify it on the same route, and escalate with clean evidence if that route still stalls.