[Bug] Anthropic API Error: Stream idle timeout - partial response received

the same error: API Error: Stream idle timeout - partial response received

• Mac OS in Claude App at Code Tab, Max Plan

+1 API Error: Stream idle timeout - partial response received

I’ve experienced this error multiple times over the last couple of hours on macOS using the Claude app (Max plan).

• 1 getting _"API Error: Stream idle timeout - partial response received"_ 6 times in one plan session. Using Claude Code Desktop on Windows 11 machine.

An example output returned below:

**Yes, still working. The stream timed out after my last tool result. I have all three exploration agents' findings and have verified the critical files (vouchers schema, checkout route). I'm now ready to move into the Design phase.

Let me continue by launching the Plan agent to design the implementation.

API Error: Stream idle timeout - partial response received**

We are drowning in this error. No VPN. Latest Claude App in Code Web mode.

<img width="1415" height="1443" alt="Image" src="https://github.com/user-attachments/assets/cc117453-80bd-4aef-a44a-de99be715ae7" />

Same here, no VPN or anything: plain environment using Opus 4.7 (1m context).
Tried deleting the session and starting over: same result.

Happens for me during planning of a large task - though it fails after my initial prompt (just a single message from me, few minutes of work from agent, then failure).

Same failure mode:

• Multi-turn planning session on a non-trivial private repo with a

custom CLAUDE.md, context at roughly 33% of the window.

• Asked the assistant to rewrite a long markdown planning document

from scratch as a handoff for a new session.

• Model performed 1–2 exploratory tool calls (file read, scan),

then began the Write call.

• Stream terminated with `API Error: Stream idle timeout - partial

response received` before the write completed in the UI.

• Retried 4 times across 2 separate sessions on the same repository

over 2 consecutive days. All failed at roughly the same point.
Reducing the scope of the write did not help.

• Sessions remained alive, but the same turn could not be

completed — consistent with this being a keep-alive / heartbeat
gap between tool-result-accepted and the next assistant token,
not a model or tool-execution issue.

Workarounds suggested by support (manual chunking of the write,
raising CLAUDE_STREAM_IDLE_TIMEOUT_MS) do not apply to the Cloud
/ browser surface. Confirmation that a fix is in progress for this
specific surface would be appreciated.

API Error: Stream idle timeout - partial response received

Tried to restart Ultraplan in 3 different sessions, hit the error every time. On one session, I prompted to "Continue" a few times, only to be met with the error minutes after each "Continue".

womp womp.

I'm getting API Error: Stream idle timeout - partial response received constantly in the iOS app working on code in a GitHub repo. I can kick start the session again sometimes but it often grinds to a halt soon again. Wasted time and tokens, to the point where it gets unusable,

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).

The same issue

same issue here.

Never have this kind of error before claude 4.7 rolling out.

UPDATE: This was actually an issue on my end, not Claude Code. I have an automatic ISP failover system between two providers, and a bug in my routing webhook was flushing connection tracking (conntrack) every 5 minutes — which killed all active TCP streams including the API connection to Anthropic.

Maybe claude team can't ship a fix for this issue because they themselves encounter this issue when using claude to fix claude