API Error: Stream idle timeout - partial response received

Getting same error also on macos, plan mode is not usable at all

Quick note it seem updating to version 2.1.112 solves the problem.

same issue is back today please help

API Error: Stream idle timeout - partial response received

same issue on windows 11 - running the latest version

I am hitting this issue on the claude desktop app (MacOS) and on my iphone app. This is frustrating. Cna't get anything done on the app using claude code on the app.

This has become a very consistent issue - regardless of model or version being used.

Anything that has to do with writing any sized file, times out or takes so long that you have literally no idea if claude is stuck or intending to proceed.

I've been given every single kind of response from Claude itself as to why it is happening. The conversation is too big. The context too large. It takes a lot of effort to write this 4kb file, your read/write speed is slow, start a new session, don't say please, try breaking it into chunks.

i mean, i literally asked it just to create 10, empty files, yesterday. that's it... 26mins total for it to create the first two, empty files. 6 new sessions just trying to get it to write the remaining 8 files. Not even fill it out, not writing any content to it. Just create the files.

then to make matters worse, i had to tell Claude "update the document 01 with _insert text here_" for 8kb of text.

it also cannot be the context - it'll come back to me within seconds and say "I have everything I need. Now I'll write the test file" and then just sit there for 10 minutes, time out twice, in a completely new session.

For the last 2-3 weeks this has gone on - first we were told that it's because we are under load and it's fair use blah blah blah. Then we're told a new model is coming out and everything will be good again.

paying for this is starting to appear as a waste, if we have to go through this constantly.

Please fix this. Stop blaming it on long sessions, large context etc.

+

Also experiencing this in both CLI and in CC remote session started from mobile app. Particularly frustrating in the mobile app -- the big value add of a remote session is I can prompt for something that will take awhile, lock my phone, then check in many minutes later and it's ready. That experience completely sucks if it stopped due to this error 2 minute into working. I lose confidence in doing any longer horizon (even 5-15 minute) prompts.

Still persisting as of today. No improvement across multiple models or browser environments.

At this point the stream timeout is making Claude Code Web practically unusable for longer tasks. The "continue" workaround only goes so far before the context degrades and the output suffers.

This thread has several duplicates now — clearly a widespread issue. Would really appreciate an official acknowledgment or status update from the Anthropic team. Is this being actively worked on? Is there a known fix in progress?

Korean user here. As a Claude Max subscriber using the service 80%+ of my
weekly work capacity, I've been experiencing a terrible situation over the
past few days.

After extensive diagnosis, I've confirmed that API server-side latency is
the primary root cause.

== Diagnostic Results ==

Environment:

• Claude Code v2.1.117 (Windows 10)
• Claude Max subscription
• Model: Sonnet 4.6 with /effort low (also tested Opus 4.6 / 4.7)
• Location: South Korea
• Corporate network (semiconductor industry, air-gapped environment)

Verified NOT the cause:

1. Network latency: curl to api.anthropic.com shows 0.47s total round-trip

• DNS: 0.114s / Connect: 0.198s / SSL: 0.256s / TTFB: 0.474s
• 10 sequential curl tests: all stable at 1.2–1.95s (including TLS)
• No rate limiting or proxy throttling detected

1. Local tooling: git status --short completes in <1s locally
2. Client version: Latest 2.1.117
3. Session context: /clear did not improve latency
4. Thinking budget: /effort low did not improve latency
5. Model: Same severe slowness across Opus 4.6, Opus 4.7, and Sonnet 4.6
6. MCP servers: Removed all 6 PostgreSQL MCP servers — issue persists
7. Initialization: "Subprocess initialization did not complete within 60000ms"

error observed intermittently

Observed behavior in Claude Code:

• Simple "git status --short" → "Cogitating/Sautéed for 2m 42s"
• Single turn thinking time: 80–160 seconds consistently
• Worst case observed: "Percolating... 23m 16s" (effectively frozen after

background task completion)

• Upload indicator ↑ 75 tokens taking 26+ seconds (should be milliseconds)

The decisive evidence: Claude.ai web chat on the same account, same model,
same network works at normal speed. Only the Claude Code API path is affected.

== My Question ==

It appears Anthropic may be prioritizing web/desktop traffic over Claude Code
API traffic, possibly treating Claude Code users as the source of server load.
The web and desktop clients show zero degradation, while Claude Code is
effectively unusable.

Is Anthropic planning to deprioritize Claude Code users?

As a paying Max subscriber who depends on Claude Code for daily production
engineering work on enterprise platforms, this situation is severely impacting
our productivity. I've filed this report hoping for transparency on:

1. Is there a known Claude Code-specific API path degradation?
2. Are Max subscribers affected differently from API-key users?
3. What is the expected timeline for resolution?
4. Is there a recommended workaround for power users in the meantime?

The public status page shows "Operational," but the real-world experience
tells a very different story. I would appreciate an honest, clear response.

Thank you.

Same issue on windows 11 latest version of the Claude windows app. Multiple sessions and wont recover. Claude was able to write its own bug report:

Summary: API Error: Stream idle timeout - partial response received when Claude attempts a single large Write tool call.

Environment:

• Model: claude-opus-4-7
• Client: Claude Code CLI
• Working directory: /home/user/donna
• Session date: 2026-04-23

Repro steps:

1. Enter plan mode with a research-to-spec task.
2. Run a full 5-phase plan workflow culminating in a plan agent that produces a ~3,000-word spec containing code snippets, SQL migrations, YAML config, and file manifests.
3. Ask Claude to persist that spec to the plan file at /root/.claude/plans/<slug>.md via a single Write call.

Observed behavior:

• Claude announces the Write in text ("Writing the file now"), then the turn ends with no tool call visible in the transcript.
• Eventually the client surfaces API Error: Stream idle timeout - partial response received.
• Restarting the session and retrying reproduces the same failure against the same oversized Write payload.
• Smaller tool calls in the same session succeed.

Expected behavior:
Either the stream completes the large Write call, or the failure surfaces immediately rather than after a silent idle window, so the assistant can retry or chunk automatically.

Impact:

• User-visible "stuck" turns — Claude appears to confirm an action without executing it.
• Progress is lost because the partial-response doesn't contain the tool invocation, so no retry state survives.
• Plan-mode workflows are disproportionately affected because their terminal step is typically one large Write.

Suspected cause:

• Tool-call argument payload (the content field on Write) exceeds a streaming threshold.
• Model is generating tokens but the gap between tokens — or total elapsed time mid-arguments — trips the idle timeout.

Workarounds that would help in-product:

1. Detect large Write content in the client and split into an initial Write + sequential Edit appends.
2. Raise (or make configurable) the stream idle timeout for tool-call argument streaming specifically.
3. Surface the timeout with a structured retry affordance instead of dropping the turn silently.

Continously getting the same error...

If I tell Claude that there is a bug with the Writing tool call and to use it in smaller pieces, it looks like you can get around it or at least run longer before running into the error.

I can confirm this is happening a lot.

I'm already tired of this mistake

I'm also getting "API Error: Stream idle timeout - partial response received" since today. Claude Max Pro user.

Found a fix for the API Error: Stream idle timeout - partial response received error. Adding one line to a config file resolves it for me. Full details below.

The fix

Open ~/.claude/settings.json and add this to the "env" section (create the section if it doesn't exist):

"env": {
  "CLAUDE_STREAM_IDLE_TIMEOUT_MS": "1800000"
}

Then quit and restart Claude Code. That number is 30 minutes in milliseconds, replacing a hidden 90-second default that the client uses before assuming the connection has gone idle.

When I was hitting it

• Claude Code v2.1.119 on Windows
• Opus 4.7 (1M context), xhigh effort, thinking enabled
• Asked Claude to write a long spec or plan in one shot
• Claude would say something like "Writing the spec now" and then go quiet for ~90 seconds before the error popped up

What didn't work

• Turning off remote-control (remoteControlAtStartup: false) — same failure on local CLI
• Asking Claude to break the work into smaller chunks — didn't help reliably

How I tracked it down

The timing. Opened the session log and measured every timeout. They all fired between 90.0 and 91.7 seconds after the previous message — eight in a row. That's not random — it's a 90-second clock running out.

The binary. The claude.exe binary references CLAUDE_STREAM_IDLE_TIMEOUT_MS in two places. The one my stream hits defaults to 90 seconds with no minimum, so raising the env var directly raises the ceiling. The variable is real and load-bearing — it's just not in the official env-vars reference, so nobody knew it was the lever.

Confirmation it actually works

After setting the env var to 1,800,000 and restarting:

• A 737-line spec write that had failed twice in a row went through on the first try
• A follow-up 3,518-line plan write also wrote cleanly
• Same model, same context size, same prompt — only the env var changed

Suggestion for Anthropic

This variable is real and important but undocumented — please either add it to the env-vars reference page or raise the default. Opus 4.7 with thinking + large context easily goes silent for over 90 seconds while preparing a big tool call, and most users have no way to know what's wrong or how to fix it.

Cross-ref: #25979 (main tracking issue), #33949 (technical deep-dive).

Found a fix for the API Error: Stream idle timeout - partial response received error. Adding one line to a config file resolves it for me. Full details below. ## The fix Open ~/.claude/settings.json and add this to the "env" section (create the section if it doesn't exist): "env": { "CLAUDE_STREAM_IDLE_TIMEOUT_MS": "1800000" } Then quit and restart Claude Code. That number is 30 minutes in milliseconds, replacing a hidden 90-second default that the client uses before assuming the connection has gone idle. ## When I was hitting it Claude Code v2.1.119 on Windows Opus 4.7 (1M context), xhigh effort, thinking enabled Asked Claude to write a long spec or plan in one shot Claude would say something like "Writing the spec now" and then go quiet for ~90 seconds before the error popped up ## What didn't work Turning off remote-control (remoteControlAtStartup: false) — same failure on local CLI Asking Claude to break the work into smaller chunks — didn't help reliably ## How I tracked it down The timing. Opened the session log and measured every timeout. They all fired between 90.0 and 91.7 seconds after the previous message — eight in a row. That's not random — it's a 90-second clock running out. The binary. The claude.exe binary references CLAUDE_STREAM_IDLE_TIMEOUT_MS in two places. The one my stream hits defaults to 90 seconds with no minimum, so raising the env var directly raises the ceiling. The variable is real and load-bearing — it's just not in the official env-vars reference, so nobody knew it was the lever. ## Confirmation it actually works After setting the env var to 1,800,000 and restarting: A 737-line spec write that had failed twice in a row went through on the first try A follow-up 3,518-line plan write also wrote cleanly * Same model, same context size, same prompt — only the env var changed ## Suggestion for Anthropic This variable is real and important but undocumented — please either add it to the env-vars reference page or raise the default. Opus 4.7 with thinking + large context easily goes silent for over 90 seconds while preparing a big tool call, and most users have no way to know what's wrong or how to fix it. Cross-ref: #25979 (main tracking issue), #33949 (technical deep-dive).

This worsens it here, because now failed requests take 30 minutes to actually error, but the issue keeps happening.

> Found a fix for the API Error: Stream idle timeout - partial response received error. Adding one line to a config file resolves it for me. Full details below. > > ## The fix > Open ~/.claude/settings.json and add this to the "env" section (create the section if it doesn't exist): > > "env": { > "CLAUDE_STREAM_IDLE_TIMEOUT_MS": "1800000" > } > Then quit and restart Claude Code. That number is 30 minutes in milliseconds, replacing a hidden 90-second default that the client uses before assuming the connection has gone idle. > > ## When I was hitting it > Claude Code v2.1.119 on Windows > Opus 4.7 (1M context), xhigh effort, thinking enabled > Asked Claude to write a long spec or plan in one shot > Claude would say something like "Writing the spec now" and then go quiet for ~90 seconds before the error popped up > > ## What didn't work > Turning off remote-control (remoteControlAtStartup: false) — same failure on local CLI > Asking Claude to break the work into smaller chunks — didn't help reliably > > ## How I tracked it down > The timing. Opened the session log and measured every timeout. They all fired between 90.0 and 91.7 seconds after the previous message — eight in a row. That's not random — it's a 90-second clock running out. > > The binary. The claude.exe binary references CLAUDE_STREAM_IDLE_TIMEOUT_MS in two places. The one my stream hits defaults to 90 seconds with no minimum, so raising the env var directly raises the ceiling. The variable is real and load-bearing — it's just not in the official env-vars reference, so nobody knew it was the lever. > > ## Confirmation it actually works > After setting the env var to 1,800,000 and restarting: > > A 737-line spec write that had failed twice in a row went through on the first try > A follow-up 3,518-line plan write also wrote cleanly > * Same model, same context size, same prompt — only the env var changed > > ## Suggestion for Anthropic > This variable is real and important but undocumented — please either add it to the env-vars reference page or raise the default. Opus 4.7 with thinking + large context easily goes silent for over 90 seconds while preparing a big tool call, and most users have no way to know what's wrong or how to fix it. > > Cross-ref: #25979 (main tracking issue), #33949 (technical deep-dive). This worsens it here, because now failed requests take 30 minutes to actually error, but the issue keeps happening.

Have you tried adding this to your prompt?

There is a bug with the Writing tool call causing the API to time out. When using the writing tool, use it in smaller pieces.

Curious if it works for others.

> > Found a fix for the API Error: Stream idle timeout - partial response received error. Adding one line to a config file resolves it for me. Full details below. > > ## The fix > > Open ~/.claude/settings.json and add this to the "env" section (create the section if it doesn't exist): > > "env": { > > "CLAUDE_STREAM_IDLE_TIMEOUT_MS": "1800000" > > } > > Then quit and restart Claude Code. That number is 30 minutes in milliseconds, replacing a hidden 90-second default that the client uses before assuming the connection has gone idle. > > ## When I was hitting it > > > > Claude Code v2.1.119 on Windows > > Opus 4.7 (1M context), xhigh effort, thinking enabled > > Asked Claude to write a long spec or plan in one shot > > Claude would say something like "Writing the spec now" and then go quiet for ~90 seconds before the error popped up > > > > ## What didn't work > > > > Turning off remote-control (remoteControlAtStartup: false) — same failure on local CLI > > Asking Claude to break the work into smaller chunks — didn't help reliably > > > > ## How I tracked it down > > The timing. Opened the session log and measured every timeout. They all fired between 90.0 and 91.7 seconds after the previous message — eight in a row. That's not random — it's a 90-second clock running out. > > The binary. The claude.exe binary references CLAUDE_STREAM_IDLE_TIMEOUT_MS in two places. The one my stream hits defaults to 90 seconds with no minimum, so raising the env var directly raises the ceiling. The variable is real and load-bearing — it's just not in the official env-vars reference, so nobody knew it was the lever. > > ## Confirmation it actually works > > After setting the env var to 1,800,000 and restarting: > > > > A 737-line spec write that had failed twice in a row went through on the first try > > A follow-up 3,518-line plan write also wrote cleanly > > * Same model, same context size, same prompt — only the env var changed > > > > ## Suggestion for Anthropic > > This variable is real and important but undocumented — please either add it to the env-vars reference page or raise the default. Opus 4.7 with thinking + large context easily goes silent for over 90 seconds while preparing a big tool call, and most users have no way to know what's wrong or how to fix it. > > Cross-ref: #25979 (main tracking issue), #33949 (technical deep-dive). > > > This worsens it here, because now failed requests take 30 minutes to actually error, but the issue keeps happening. Have you tried adding this to your prompt? There is a bug with the Writing tool call causing the API to time out. When using the writing tool, use it in smaller pieces. Curious if it works for others.

I added this to my CLAUDE.md one hour ago:

If a subagent stalls for >90s with no tool output, abort it and re-dispatch with a smaller scope rather than waiting for the watchdog.

- **Max file size**: 600 LOC strict max (split files at ≤300 LOC; for files that legitimately need to exceed that, write them across multiple Edits rather than one Write) — split before reaching the limit

And also removed a thoroughness instruction.

The issues stopped. But it's too soon to tell if this is why or if it's just a coincidence.

Yes its happening after the recent UI update in Claude code. Especially when we try working on a monorepo or trying to work with more than one repo it fails to write to second repo or if it's large task it keep showing the error "API Error: Stream idle timeout - partial response received". Its been more than 2 weeks now we are stuck and not able to finish even a single task. its simply wasting tokens and showing limit hit. Anthropic should take responsibility and give a relaxed limit or double the limit as it did last month.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.