[BUG]  API Error: Stream idle timeout - partial response received - multiple time today

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/46955
2. https://github.com/anthropics/claude-code/issues/18028
3. https://github.com/anthropics/claude-code/issues/25979

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Just started happening for me today.

same
happened when used "ultraplan" and refined the plan a few times

it happens now also to me

happens on sonnet too

Same. Wasting my token usage 😞

me too, fuck

+1

+1

+1

same, whole day with claude code, burning tokens as crazy and time out

Luckily i got the 200€ plan coz god damn even with a 20x its eating 3% per time out
When i asked him mid session why is he showing the message "API Error: Stream idle timeout - partial response received"
he says :"This isn't a mistake in my code—it's a session timeout, Claude, because the response takes a very long time to generate (I'm rewriting several large files at the same time).
I'll proceed file by file to avoid timeouts. Let's begin."

Then proceed to eat 3% without working,

Edit: it started working again after asking him the question lmao

same, seeing this in my claude code (not cli, but just running with gh connector)

I hit this same issue across several Ultraplan sessions, when Claude was trying to push changes, it kept timing out and showing API Error: Stream idle timeout - partial response received in the response and just hanging.

I was able to get around the problem by telling Claude to try breaking the task up into smaller stages and it was then able to get everything pushed and I could continue on my local machine.

This happened to me a few hours ago and it took up all my 5 hour usage while I got no response.

+1
The same error. Max (20x). Opus model.

+1 Max (5x) Opus

Tried to update a GitHub issue with the desktop app.
+1 （Max (20x). Opus model）

<details><summary>Screenshot（Tried twice with the same prompt）</summary>
<p>

<img width="688" height="251" alt="Image" src="https://github.com/user-attachments/assets/9b202659-019a-4f40-a498-85ca6495e94e" />

</p>
</details>

Unable to start a new session. 5 attempts in 2 hours — same error, no success.

<img width="683" height="110" alt="Image" src="https://github.com/user-attachments/assets/733d26c9-58d8-4005-82e0-b74496c9f1a9" />

Seeing the same issue since yesterday.

Happens when trying to create a plan, or when approving a plan to move on to the implementation.

Asking to "Try again" works half the time.

<img width="688" height="134" alt="Image" src="https://github.com/user-attachments/assets/ffb9b2d8-0c34-40bc-8a6c-9ac15c576c10" />

+1 Max (5x) Opus

Seeing the same issue since yesterday. Happens when trying to create a plan, or when approving a plan to move on to the implementation. Asking to "Try again" works half the time.

"Try again" worked, but... the issue returned after 30 seconds.

<img width="726" height="77" alt="Image" src="https://github.com/user-attachments/assets/6344c28c-2072-4aca-9e6b-9130755434b7" />

UPD: And then it happened again.

<img width="719" height="165" alt="Image" src="https://github.com/user-attachments/assets/b5a51f79-8c95-4877-b610-81b3fe90d03f" />

Encountering the same.

Same happening with me

same here, had it since yesterday. already ate 29% of my weekly usage (Pro plan). Same issue happens in two different project branches.

ditto, wasting so much time and money

API Error: Stream idle timeout - partial response received

Got this error on the Claude code web via mobile app

Same issue here - Have had multiple freezes over the weekend where a tool call for a read would hang for 10+ minutes until I stopped it. Now this morning I get API Error: Stream idle timeout - partial response received on Claude.ai/code web sessions. I am on Max 5x using Sonnet. So it seems two issues 1) tool calls getting stuck indefinetly and 2) the API Errors. Maybe connected.

+1

<img width="465" height="61" alt="Image" src="https://github.com/user-attachments/assets/b57a5602-833e-4bd6-96dd-7aa162edd9f3" />

Opus 4.6 1M 5x Max Plan Since yesterday, like 5-6 times. So many wasted tokens ....
API Error: Stream idle timeout - partial response received

+1

me too using Opus

tambem estou com o mesmo problema desde ontem

+1

Same here, since 5h ago

Update: Fixed it on my end. The culprit is CLAUDE_ENABLE_STREAM_WATCHDOG=1 in ~/.claude/settings.json. It kills the stream after 90 seconds of no data — but with Opus and high effort thinking, the model can easily go silent for longer than that while reasoning.

Fix (CLI users): Either remove CLAUDE_ENABLE_STREAM_WATCHDOG from your settings, or increase the idle timeout by adding "CLAUDE_STREAM_IDLE_TIMEOUT_MS": "600000" to your env block.

Docs reference: https://code.claude.com/docs/en/env-vars

For me only happening now in the web version of Claude Code (https://claude.ai/code) not the CLI on my Mac.

Happened for me 12 hours ago, again 5 hours ago, seemed to be fixed but bug just appeared again

I got same error. Wasted my tokens.

This error forced me the figure out how to switch to CLI instead of web or desktop.

After increaseing the idle timeout by adding "CLAUDE_STREAM_IDLE_TIMEOUT_MS": "600000" to the env block as a user pointed out here, the issue was resolved for me.

Root cause and upstream fix proposal: anthropic-sdk-typescript#998.

Short version: Anthropic's API already sends ping events as a liveness signal every ~15–30s, but the SDK silently drops them (src/core/streaming.ts lines 78-80). Claude Code's watchdog therefore can't tell Opus extended thinking from a real hang — 90s of silent reasoning looks identical to a dead stream.

The v2.1.104 regression that's flooding this thread is downstream: before 2.1.104 the watchdog abort silently fell back to non-streaming (2× token cost but no visible error). In 2.1.104 the fallback was removed when partial data was received, so every false-positive watchdog fire now surfaces as partial response received with no recovery. @gabrimatic's workaround (raise CLAUDE_STREAM_IDLE_TIMEOUT_MS to 300-600s) helps but is a band-aid — it just moves the blind guess to a larger number.

Prior root-cause analysis of this family of bugs is in #33949 and #39755. SDK#998 extends it with a concrete fix path: forward pings, then semantic pings (status, queuePosition, thinkingDepth), then server-driven timeouts (nextPingWithinMs) so every client stops guessing.

Same Error since yesterday. Waste tokens and nothing happens in every new session :(

Same issue here for Claude Code Web.

+1 in web

+1 web

Happening on any model, claude code max plan CLI. Seems somehow related to size of file. Breaking reads and writes into chunks helped a bit. Otherwise does make it unusable.

they better give some credit for this

Same for me on the MacOS Claude desktop app

API Error: Stream idle timeout - partial response received

All of my session tokens spent on this.

Anthropic could you please respond, ETF?

+1 API Error: Stream idle timeout - partial response Received....

+1 API Error: Stream idle timeout - partial response received on multiple sessions.

This has been happening for the last 6 hours.

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

same API Error: Stream idle timeout - partial response received

+1
Same error on cli and on the site.
API Error: Stream idle timeout - partial response received

same cant even use it.

resolution for me was to check my integrations - applications and claude had permissions to approve. after that it could create new branches and actually submit things again.

Crazy Token-Verbrauch ohne Ende für nichts! Codex läuft normal und ist meiner Meinung nach auch nicht schlecht!

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

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

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

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

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

+1 Still an issue - Been experiencing this for several days - planning almost useless and waste of time/tokens... Only solution at the moment is to reduce input prompt size, breaking larger instructions for plans into sub sets in normal chat, feeding one by one.

+1 API Error: Stream idle timeout - partial response received. And tokens are consumed!

facing the issue right now

Same for me since saturday.

Same since yesterday morning.

API Error: Stream idle timeout - partial response received

Same error message.

+1 - unusable

+1 same issue

+1 Same issue, has anyone found an alternative to this?

Antrophic marked it as resolved. Does it work for you guys? On my side it dosent. Still: API ERROR: Stream idle timeout - partial response received

+1 issue persists for me as well

I had no trouble in terminal, but I'm getting it on Claude Code on the Web.

I have the same issue since this morning

+1 extremely annoying

+1 same for me, very annoying

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

+1 Getting this error for ultra-plan mode only.

+1

Have been constantly getting this for the past few days. Prompting claude to break down task into microsteps was working until the new desktop app update today literally can't get anything done!!

Started happening today after app update

I’ve also experienced this error multiple times over the last couple of hours on macOS using the Claude app (Max plan), mainly when writing .md files using Opus 1M.

For two days now, the "API Error: Stream idle timeout - partial response received" issue has prevented me from making any progress, and 35% of my weekly token allowance has been consumed with nothing to show for it. If I close the current session and start over, restoring the previous context will cost nearly 100% of my weekly token allowance.
Please fix this as soon as possible.
Thank you.

Still getting this. Only started happening yesterday. (iOS app or web browser, using Claude code's default workspace)

Platform: macOS, Claude Code desktop app and Claude mobile app
Model: Sonnet 4.6 (also tried Opus 4.6, same result)
Network: No VPN, no proxy, no corporate filtering
Started: ~2-3 days ago (previously worked fine on same setup)
Behaviour: Has gradually become worse. Now every attempt to use GitHub tools (push branch, create PR) fails immediately with API Error: Stream idle timeout - partial response received. Fails even when broken into single-step tasks ("Step 1 of 4 — pushing backlog.html to the branch" → immediate failure). /clear between attempts makes no difference. This has rendered Claude Code completely unusable for any workflow involving GitHub.
What changed: Was working reliably on this exact setup. No changes on my end. This is a sudden regression, not a network issue.

Just started for me two days ago, all projects are basically unusable and tokens are being wasted with every message as they're constantly failing with API errors

Claude code is completely useless for me, doesn't matter if its a new session, mobile or desktop, or what the current task is. I get the API Error: Stream idle timeout - partial response received error every single time.

Fixed it using a prompt like this, my guess is that Claude regressed with its capabilities to chunk work into small sections.

<execution_rules>
You MUST follow these rules for the ENTIRE duration of this task:
NEVER silently plan. Start writing code/output within 10 seconds of receiving this prompt.
Think out loud — narrate what you're about to do in 1 sentence, then immediately do it.
After completing each file edit or logical section, emit a progress line:
--- ✅ [N/TOTAL] [description] complete ---
Maximum 150 lines of code per tool call. If a file needs more, split across multiple sequential writes.
Process the task in the exact order listed. Do not reorder or parallelize.
If you need to read files, read them and immediately start the first edit — do not summarize what you read.
Never emit a planning block longer than 3 sentences without code following it.
</execution_rules>

--- TASK START ---
(Paste prompt here) <-<-
--- TASK END ---

<output_contract>
After EVERY discrete change (each file, each function, each logical section), print:
--- ✅ [step N] [what you just did] ---
When fully done, print:
--- 🏁 ALL STEPS COMPLETE ---
</output_contract>

I've found telling claude to break down the submission into smaller chunks has helped avoid this issue, but still faced it several times over different sessions in cloud claude code sessions.

Met same problem when using Claude Code (GitHub environment): API Error "Stream idle timeout - partial response received"

Totally agree with others here that are saying to provide new rules to Claude. I was able to have it write new efficiency rules into my Claude config and I'm back to working now. I'm wondering if they adjusted max context windows or something and it's impacting everyone now. Seems like Claude should setup some rulesets for itself by default to make sure stuff like this doesn't happen.

Also reproducing on iPad (Claude Code web, claude.com/code).

• Triggers during implementation write phase after plan approval
• Reproduced 5+ times across new sessions
• "continue" prompt does not recover
• anthropic status: green during the incidents

I've found a fix that's been working for me:

Set environment variable:

CLAUDE_STREAM_IDLE_TIMEOUT_MS=600000

I haven't had an issue with the API stream timeout since implementing.

I've found a fix that's been working for me: Set environment variable: `` CLAUDE_STREAM_IDLE_TIMEOUT_MS=600000 `` I haven't had an issue with the API stream timeout since implementing.

Where do you set the env variable on Claude Desktop Mac?

Facing the same problem, claude code is not operational for me

Fixed it using a prompt like this, my guess is that Claude regressed with its capabilities to chunk work into small sections. <execution_rules> You MUST follow these rules for the ENTIRE duration of this task: NEVER silently plan. Start writing code/output within 10 seconds of receiving this prompt. Think out loud — narrate what you're about to do in 1 sentence, then immediately do it. After completing each file edit or logical section, emit a progress line: --- ✅ [N/TOTAL] [description] complete --- Maximum 150 lines of code per tool call. If a file needs more, split across multiple sequential writes. Process the task in the exact order listed. Do not reorder or parallelize. If you need to read files, read them and immediately start the first edit — do not summarize what you read. Never emit a planning block longer than 3 sentences without code following it. </execution_rules> --- TASK START --- (Paste prompt here) <-<- --- TASK END --- <output_contract> After EVERY discrete change (each file, each function, each logical section), print: --- ✅ [step N] [what you just did] --- When fully done, print: --- 🏁 ALL STEPS COMPLETE --- </output_contract>

Nice one - this works on Claude desktop app. @anthropics @catherinewu @bcherny this workaround however impractical on mobile app.

I'm reading my last two failures with a single session in Claude Code/web scheduled tasks, and it almost looks like it's breaking when it should be pushing changes to Git.

Now I'll push the modified file to the branch. The file content is ready:
API Error: Stream idle timeout - partial response received

I echoed the file back to CC and it died at this point:

Now I'll push the file to the branch using the GitHub MCP tool:
API Error: Stream idle timeout - partial response received

I'm wondering if my problem is related to scheduled tasks.

Date observed: 19 April 2026 (Sunday), London / Europe-West.
Context: Background sub-agents launched via the Task tool from a parent Claude Code session. ~10 distinct sub-agent runs across 3 batches today, all using the same prompt template and target codebase.

Pattern:

• Sub-agent runs for 7–15 min, generates ~400–650 KB of JSONL transcript, then dies with API Error: Stream idle timeout - partial response received.
• The last entry in the JSONL is consistently an assistant text turn ending with the model declaring its next action (e.g. "now let me write the report sections"), with no subsequent tool_use block. The next API round-trip never starts (or never returns).
• Sub-agent JSONL stops growing 3–6 min before the timeout fires.
• Same prompts ran cleanly in parallel last night (18 April evening); started failing today.

What we tried:

• Parallel fan-out (4–7 sub-agents): ~50% failure rate.
• Sequential, one at a time: 1 of 2 attempts succeeded; the other died with the same error.
• Even sequential agents that had reached the partial-save discipline checkpoint (write a skeleton early, append per finding) died before the first Write call landed.

Status page reported all components operational throughout. Real-world degraded — API ingress healthy, long streams flaky.

Hypothesis: weekend deploy aftershocks (Anthropic had a chatbot/Code/API outage on 15 April; today is Sunday with reduced traffic / typical maintenance window). The 5-min idle-stream watchdog added in v2.1.105 didn't engage in any of our cases — agents went 15 min before erroring.

Cost: ~half a 5-hour usage window burned on retried sub-agents that died mid-turn.

+1 - had this issue on a long session the last two days. Timed out after 2 minutes on a long session every time, but worked in other sessions. Today, I found someone on reddit said that they could get around it by telling claude to "Try doing it in smaller steps, like in 5 chunks" that worked for me.

<img width="697" height="83" alt="Image" src="https://github.com/user-attachments/assets/e640808e-ab47-42f0-b24a-46a7bacc7407" />

Same here, Opus 4.7, Firefox on Claude.ai, on Max plan. This keeps happening, I can't complete a single session.

Same here. Using Claude Code in Claude Desktop on a Windows machine. Anytime it tries to do something usually bigger I always get: API Error: Stream idle timeout - partial response received , Turn Failed

API Error: Stream idle timeout - partial response received

Claude Code from a Mac.

Did a comprehensive agent test on some code bases to generate a "RESULTS.md and DOCTRINAL-REVIEW.md" referenced in the /ultraplan session.

[Ultra Plan Prompt]

Read <redacted>/verification/RESULTS.md and DOCTRINAL-REVIEW.md.
These are VALIDATED findings — verification tests exist at
<redacted>/verification/tests/.

Read <redacted>/<redacted>-AUDIT.md §8 as the provisional
remediation plan — treat it as a first draft. Produce a better,
validated, per-phase plan where each task:
  - References the verification test that defines "done"
  - Has explicit acceptance criteria beyond the test
  - Has a rollback procedure
  - Is scoped small enough to be a single PR

Explicitly resolve the open questions from §9 and §10.3, or flag
them as blockers on user input.

Constraints:
- Read-only analysis. No execution.
- Phase A items serial.
- Phase B items parallelizable where safe — flag dependencies.

RESULTS: Starts to analyze, after about 2-3 minutes it kicks out ""API Error: Stream idle timeout - partial response receive".

Saw this using claude code on mobile in a cloud sandbox. Fixed it by opening a new session. I was getting the error even when just sending "ping" so the issue wasn't that it was doing too much work.

Saw this multiple times in a session from Claude Code Web

Adding a new data point with live-capture evidence from a Mac user experiencing this consistently.

Environment

• Claude Code 2.1.116
• macOS Sequoia 15.6.1, Apple Silicon
• Home broadband → TP-Link TL-WA850RE extender → router
• No VPN, no corporate proxy, no custom DNS
• Typically 1–8 concurrent claude processes (2 actively streaming at any time)

Live capture of a hung session

• sample <pid> 5 shows main thread 90% in kevent64 (Bun runtime — Bun Pool 0-7, tokio-rt-worker)
• Single ESTABLISHED TCP to 160.79.104.10:443 (whois: Anthropic, PBC)
• __sendto caught twice during the 4.2s sample window → connection alive, only response direction silent
• Zero child subprocesses at the moment of the hang (rules out hooks as cause)
• nc -z <anthropic-ip> 443 succeeds immediately from the same Mac → server is reachable, only this specific stream is dead

JSONL-level evidence (from ~/.claude/projects/*.jsonl)

Three synthetic API Error: Stream idle timeout - partial response received entries in a single afternoon session, all gaps exactly 301–302s apart — confirming the 5-min idle abort is firing repeatedly, consistent with recurring server-side stalls.

Network-layer observation

Of 11 simultaneous Anthropic sockets from this Mac, 4 had zero bytes in either direction for 15+ seconds across multiple PIDs. 36% simultaneous stall rate points to shared infrastructure (CDN edge / load balancer / NAT path), not per-process bad luck.

Concurrency ruled out as root cause

2 of 4 stalls in my session log occurred with zero other Claude API activity. Each claude process is a separate Bun runtime with its own TCP connection — no shared HTTP agent or pool.

The 5-min floor is the practical blocker

CLAUDE_STREAM_IDLE_TIMEOUT_MS is clamped via Math.max(value, 300000). Setting it to e.g. 60000 has no effect. For users with flaky NAT / router setups, a sub-minute recovery would make the bug tolerable. Right now every single hang eats at least 5 min before the watchdog fires.

Contributing factor: macOS default keepidle=7200s (2 hrs)

macOS won't probe a silent socket for 2 hours; home routers drop NAT sessions after 5–10 min. The gap is where streams silently die. Not a Claude Code bug per se, but the no-sub-5-min-timeout policy turns this macOS default into hours-long hangs.

Asks

1. Remove the 300000 floor on CLAUDE_STREAM_IDLE_TIMEOUT_MS (or add a CLAUDE_STREAM_IDLE_TIMEOUT_MS_ALLOW_UNDER_300K=1 escape hatch) so users can set 60–90s.
2. Set setKeepAlive(true, 30000) on the Anthropic fetch agent so dead streams surface within 30s regardless of the SSE-layer watchdog.
3. Document CLAUDE_ENABLE_BYTE_WATCHDOG, CLAUDE_STREAM_IDLE_TIMEOUT_MS, API_TIMEOUT_MS, CLAUDE_CODE_DISABLE_NONSTREAMING_FALLBACK in the public settings.json schema (currently undocumented — see #47623).
4. Ensure the watchdog fires for Task-spawned sub-agents (#50802 still open; several of my hangs today were inside agent teams).

Happy to provide the full sample file or redacted JSONL snippets if useful for triage.

API Error: Stream idle timeout - partial response received also here, and also while it was working on a problem...

This needs asap fixed... its killing me so often right now.

Is anyone at Claude dealing with this?

Claude is wasting tokens, which we have a limited amount of, and with no result whatsoever.

This is unacceptable for a paid service.

Happens on Claude Code Web.

Completely unacceptable. Anthropic has really dropped the ball. For 200 dollars a month, no other service has the audacity to ignore such complaints

Also ran into this just now using Claude Code via the desktop UI on Mac. Session is in web/remote mode.

Last tool call before it should have started updating a md doc was reading said doc and getting this response:

"File unchanged since last read. The content from the earlier Read tool_result in this conversation is still current — refer to that instead of re-reading."

Sent a followup nudge to see that'd help and it did not.

Then I looked down at the model picker bellow chat input, it read <synthetic>? .... switched from that back to Opus 4.7, hit the "stop" button, and then CC just jumped right back in responding to the unanswered nudge, and explaining it's next steps, which I thanked it for ... which was immediately followed by two more of the errors back to back, but this time with a "x Turn failed Try sending again" addendum.

<img width="970" height="304" alt="Image" src="https://github.com/user-attachments/assets/5351a2ea-58be-4f7e-a6a3-2dbebb73359d" />

+1 - had this issue on a long session the last two days. Timed out after 2 minutes on a long session every time, but worked in other sessions. Today, I found someone on reddit said that they could get around it by telling claude to "Try doing it in smaller steps, like in 5 chunks" that worked for me.

This worked perfectly thank you!

since Anthropic released 4.7, the errors appeared. Before I didn't have a problem.

anyone found a solution for this?

+1 - had this issue on a long session the last two days. Timed out after 2 minutes on a long session every time, but worked in other sessions. Today, I found someone on reddit said that they could get around it by telling claude to "Try doing it in smaller steps, like in 5 chunks" that worked for me.

"Try doing it in smaller steps, like in 5 chunks" It works for me. Thank you very much! @jpdmdw

hi @ch4rli3kop, tried that but no luck.

+1

okay captured an actual screenshot of that weird <synthetic> model picker selection again (which both times coincided with the API error getting thrown).

<img width="1968" height="1106" alt="Image" src="https://github.com/user-attachments/assets/038f6638-ec33-42a0-8ec8-f108fb7498c4" />

Runtime is still Claude Code on the web, via desktop app on Mac. Environment includes a python venv installed, if that's relevant.

Additional context:

• this was within the same session, which I resumed this morning asking it to just ignore the markdown doc updates and share findings directly to the session -- which it handled without any issue, other tool calls and all
• But when I did eventually nudge it to update the doc, error thrown + <synthetic> model switch
• Stopped it running, switched model picker back to opus, and used the "Try doing it in smaller steps, like in 5 chunks", and that solved it for me as well

Somehow just by adding "Try doing it in smaller steps, like in 5 chunks" it literally started working again

Seeing this non-stop now, going to have to go back to local terminal

This has been happening so consistently over the last two days, that things have become unusable.

Just started happening to me yesterday but ONLY with Routines on cloud Opus 4.7. Seems in my case it happens when generating Notion reports towards the end of a routine.

Switching to Sonnet 4.6 allowed the routines to finish (this was acceptable considering the type of routine).

+1, since Anthropic released 4.7, this error appeared.

This kills the session as any further message get that error as a response. The alternative is either start that session again from scratch, or copy pasting the entire session to a new session. Both frustrating options.

This is genuinely unacceptable.

ditto when using ultraplan https://claude.ai/code/session_01XYzDRM8qaszXnUBDDT6t2b

This needs to be fixed. It's likely wasting customer tokens - and happens frequently on web ui.

Just getting this now too.

Same here. This has made ultra plan completely useless and just smokes through a significant proportion of tokens each time... :/

What a waste of tokens

This should be fixed

getting too here , how to report it to claude? for faster checking ?
API Error: Stream idle timeout - partial response received

more than 5 times burnt tokens .

From my observation, this bug always appears after claude tries to write a huge plan file, so the solution is just tell him to write the file chunk by chunk.

Here is a dirty solution, just copy and paste the following sentence to the chatbox.

Please DO NOT write the entire the plan file at once, use the Edit tool to append.

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.

+1

try to change prompt , now i get : WebSocket connection error
any ideas what we should do now ?
only shows in Claude code with low limits .
new session , just connected to a GitHub repo .
also Claude code incidents marked as solved .
https://status.claude.com/

<img width="488" height="191" alt="Image" src="https://github.com/user-attachments/assets/cc386b6a-04b6-488b-ab6b-275f15d21c53" />

Just started happening to me too. happend more than 4 times now. according to google we have to update this. happens only on the web ui

Absolute deal breaker for Claude code web sessions

Just implemented this into my CLAUDE.md files; it seems to also fix a bugged session if you paste in the block with a continue directive

## Stream Timeout Prevention

1. Do each numbered task ONE AT A TIME. Complete one task fully,
   confirm it worked, then move to the next.
2. Never write a file longer than ~150 lines in a single tool call.
   If a file will be longer, write it in multiple append/edit passes.
3. Start a fresh session if the conversation gets long (20+ tool calls).
   The error gets worse as the session grows.
4. Keep individual grep/search outputs short. Use flags like
   --include and -l (list files only) to limit output size.
5. If you do hit the timeout, retry the same step in a shorter form.
   Don't repeat the entire task from scratch.

continue

Source: https://dev.to/lavellehatcherjr/how-i-stopped-getting-stream-idle-timeout-errors-in-claude-code-hf9

Edit: I also notice that when the API error occurs, the model name changes to <synthetic>. I changed it back to opus 4.7 and sent the above message.

Just implemented this into my CLAUDE.md files; it seems to also fix a bugged session if you paste in the block with a continue directive `` ## Stream Timeout Prevention 1. Do each numbered task ONE AT A TIME. Complete one task fully, confirm it worked, then move to the next. 2. Never write a file longer than ~150 lines in a single tool call. If a file will be longer, write it in multiple append/edit passes. 3. Start a fresh session if the conversation gets long (20+ tool calls). The error gets worse as the session grows. 4. Keep individual grep/search outputs short. Use flags like --include and -l (list files only) to limit output size. 5. If you do hit the timeout, retry the same step in a shorter form. Don't repeat the entire task from scratch. continue ` **Source**: https://dev.to/lavellehatcherjr/how-i-stopped-getting-stream-idle-timeout-errors-in-claude-code-hf9 Edit: I also notice that when the API error occurs, the model name changes to <synthetic>`. I changed it back to opus 4.7 and sent the above message.

Thanks for sharing this! Tried it in my CLAUDE.md and it works great — no more stream timeouts. The tip about pasting the block with continue to recover a bugged session is especially useful. Appreciate it!

@47vigen It doesn't work forever, I'm still getting the occaisonal error later on and need to resend it the same message :/

I've exhausted all my tokens today but just keep hitting the same error - "API Error: Stream idle timeout - partial response received". I'm not even editing i'm just working on plan mode.

Is there a fix for this??

Here's what worked for me.

Root cause: The stream stalls when Claude generates or processes too much output at once. Long diffs, large file writes, and Opus 4.7's extended thinking are the biggest triggers.

---

Step 1 — Add to your global ~/.claude/CLAUDE.md:

## Stream Timeout Prevention

1. Do each numbered task ONE AT A TIME. Complete one task fully,
   confirm it worked, then move to the next.
2. Never write a file longer than ~150 lines in a single tool call.
   If a file will be longer, write it in multiple append/edit passes.
3. Start a fresh session if the conversation gets long (20+ tool calls).
   The error gets worse as the session grows.
4. Keep individual grep/search outputs short. Use flags like
   --include and -l (list files only) to limit output size.
5. If you do hit the timeout, retry the same step in a shorter form.
   Don't repeat the entire task from scratch.

## Committing Changes

- When committing, write the message from the user's description — do NOT run `git diff` or `git log` to read all changes first.
- Only run `git status` to see which files are staged, then commit with the message the user provided.
- This avoids large diff output that causes stream idle timeouts.
- After completing each discrete task or feature, commit immediately before moving to the next task. Keep commits small and frequent.

---

Step 2 — Add to your ~/.claude/settings.json:

{
  "env": {
    "CLAUDE_STREAM_IDLE_TIMEOUT_MS": "600000"
  }
}

This raises the client-side stream timeout to 10 minutes.

---

Notes:

• On Mac/Linux, ~ is your home directory. Verify with echo ~ in your terminal.
• Claude Code 2.1.105+ has a non-streaming fallback built in — update if you're behind that.
• Opus 4.7 is significantly more prone to this than Sonnet 4.6 due to extended thinking generating long pauses between tokens. Consider switching models if the issue persists.
• Restart Claude Code after changing settings.json for the env var to take effect.

Good luck — hope this helps others!

From my observation, this bug always appears after claude tries to write a huge plan file, so the solution is just tell him to write the file chunk by chunk. Here is a dirty solution, just copy and paste the following sentence to the chatbox. `` Please DO NOT write the entire the plan file at once, use the Edit tool to append. ``

Worked for me, THANK YOU.

I am getting this so much today

https://snipish.mfdi.me/s/eeTzZH7oza

+1

+1

+1

+1

+1

I have been logging this issue for over two weeks. Posting today's numbers because they have stopped looking like noise and started looking like a regime change on a paid Max plan.

For the 28 days from 14 March to 11 April: zero stream-idle-timeout errors across roughly 50,000 assistant turns in my logs. From 12 April to today (16 days): 285 stalls across 45,000 turns. Per-request stall rate jumped from 0% to 0.6%, with bad days hitting 1.5% to 2.7%.

Something changed.

Per-hour failure rate (UK / BST)

This is stalls divided by assistant turns logged in each hour, not absolute counts:

hour     turns   stalls    rate     bar
05:00      929       1    0.11%    ███
06:00    2,428      10    0.41%    ██████████████
07:00    4,482      18    0.40%    ██████████████
08:00    5,482      15    0.27%    █████████
09:00    6,723       6    0.09%    ███
10:00    7,096      11    0.16%    █████
11:00    5,274      14    0.27%    █████████
12:00    7,599      85    1.12%    ████████████████████████████████████████
13:00    6,262      30    0.48%    █████████████████
14:00    5,895       4    0.07%    ██
15:00    6,736       3    0.04%    █
16:00    5,901      10    0.17%    ██████
17:00    5,443      16    0.29%    ██████████
18:00    4,464       5    0.11%    ████
19:00    3,997      38    0.95%    █████████████████████████████████
20:00    3,374      11    0.33%    ███████████
21:00    4,597       3    0.07%    ██
22:00    1,283       5    0.39%    █████████████

The UK 11:00 to 12:00 jump is the cleanest signal in the dataset: per-request stall rate goes from 0.27% to 1.12%, a 4.1x increase in a single hour. UK 12:00 = US Eastern 07:00. This is not a usage artifact (the rate is normalized by request count) and not a behavioural artifact on my end. The 19:00 secondary peak (0.95%, lining up with US Pacific working hours) shows the same pattern. Off-peak hours sit in the 0.04% to 0.40% band.

Concurrency as the trigger, normalized

I noticed earlier in the period that Sundays felt smoother and tested it deliberately this past weekend by holding the day-of-week constant and turning up the concurrency knob:

| Date | Day | Concurrent terminals | Turns | Stalls | Rate |
|---|---|---|---|---|---|
| 2026-04-12 | Sun | 1 | 3,534 | 1 | 0.03% |
| 2026-04-19 | Sun | 1 | 2,736 | 8 | 0.29% |
| 2026-04-26 | Sun | 2-3 (deliberate) | 2,257 | 35 | 1.55% |

I made fewer requests on 26 April than on 19 April, yet stalls went up 4x. Per-request rate went from 0.03% to 1.55%, a 52x range across the test. Concurrency changes per-request failure probability, not just absolute volume.

During UK peak hours (12:00 onwards) I can essentially guarantee a stall on a single attempt by opening two or three terminals and running them in parallel. Mid-week it reproduces with a single terminal running ordinary work. Chunking into smaller requests modestly reduces the rate but does not eliminate stalls.

Methodology and caveats

I grepped my own Claude Code session logs at ~/.claude/projects/**/*.jsonl for the synthetic client error "Stream idle timeout". This is the error fired by Claude Code's own HTTP reader after the 5-minute CLAUDE_STREAM_IDLE_TIMEOUT_MS floor when the API stream stops sending bytes mid-response.

Caveats stated honestly:

• Cluster analysis: of 207 inter-stall gaps within the same session, 21% are under 30 seconds and likely represent retry clusters on the same logical request, 14% are ambiguous, 65% are over 5 minutes apart and represent independent failures. Roughly 1 in 5 of the 285 raw count is retry-inflated. Per-request rates hold their shape under that adjustment.
• Overnight zero: I am not active between roughly UK 23:00 and 05:00, so the histogram zero in those hours is partly an exposure artifact, not proof Anthropic's infrastructure is healthier overnight.
• Survivorship: any session that crashed before writing JSONL is missing entirely. 285 is therefore a lower bound.
• Version: Claude Code v2.1.107, macOS, no proxy, no VPN.

What this rules out

• Not local network: same router, same ISP, same TCP keepalive settings 24/7.
• Not local CPU pressure: stalls are 90%+ kevent64 per stack sample, no busy thread.
• Not hooks: A/B'd with hooks disabled, symptom persists.
• Not a 429 / rate-limit issue: no rate_limit_error payload, just silence on the SSE stream until the client times out.
• Not a usage volume artifact: rates are per-request, not per-hour-absolute.

What the available client-side env vars do not fix

CLAUDE_STREAM_IDLE_TIMEOUT_MS, CLAUDE_ENABLE_BYTE_WATCHDOG, and API_TIMEOUT_MS only cap the duration of each stall at the 5-minute hard floor (Math.max(parseInt(...) || 90000, 300000) in the binary). They do not prevent stalls. They do not restore the partial response. The non-streaming fallback retry helps recover some turns but does not address the root cause.

Asks

1. Sub-5-minute idle-timeout option in Claude Code (binary currently clamps to 300000ms minimum).
2. SSE-level keepalive / :ping from the server side so the client can distinguish "still working" from "dead stream."
3. Public acknowledgement of the correlation with peak load, and a status-page metric for stream stall rate.
4. A clear path for affected paid subscribers to recover lost time on Max plans. Email support has not been a working channel for this; a public acknowledgement of how to escalate would help.

Reproducible community datapoint

python3 -c '
import json, glob, os, datetime as dt
from collections import Counter
from zoneinfo import ZoneInfo
TZ = ZoneInfo("Europe/London")  # change to your timezone
stalls, turns = [], Counter()
for f in glob.glob(os.path.expanduser("~/.claude/projects/**/*.jsonl"), recursive=True):
    try:
        for line in open(f, errors="ignore"):
            try:
                d = json.loads(line)
                if not d.get("timestamp"): continue
                t = dt.datetime.fromisoformat(d["timestamp"].replace("Z","+00:00")).astimezone(TZ)
                if d.get("type") == "assistant":
                    turns[t.hour] += 1
                if "Stream idle timeout" in line:
                    stalls.append(t)
            except: pass
    except: pass
stalls_by_hour = Counter(s.hour for s in stalls)
print(f"Total: {len(stalls)} stalls, {sum(turns.values())} assistant turns")
for h in range(24):
    if turns[h]:
        rate = stalls_by_hour[h]/turns[h]*100
        print(f"  {h:02d}:00  turns={turns[h]:>5}  stalls={stalls_by_hour[h]:>3}  rate={rate:.2f}%")
'

Single-user data is anecdote. Ten users with rates is evidence.

Get this now nonstop, several times per hour, cutting of work flow middle of it... Extremely annoying and frustrating...
I'm on .119

I too am getting this consistently now. Temporary fix is asking claude to keep sending me updates as it's working, even for long-running tasks

I too am getting this consistently now. Temporary fix is asking claude to keep sending me updates as it's working, even for long-running tasks

This feels like a more stricter enforcement of their TTL, someone flipped a flag for harder enforcement...
And because they are incompetent as usual and set it to 5 minutes while their server takes over 5 minutes to serve active requests, leading to hitting the TTL on cache... So by the time the response is ready? The cache have died and hits that...

It wouldnt surprise me 1 millisecond if that is exactly what is happening.

I am also experiencing this, seemed to start around Opus 4.7 being released (but I can't pinpoint that exactly).

API Error: Stream idle timeout - partial response received

Claude Code CLI version: 2.1.121

Trying to get it to make changes to a markdown file, or code changes, anything really.

Notion MCP also gets stuck forever on any tool call (tried disabling, reconnecting, re-authenticating) - just seems broken. Have had it working prior.

Same error pops up on the web version of code. Had a thought. Maybe claude team can't ship a fix for this issue because they themselves encounter this issue when using claude to fix claude

Hi Anthropic team,

I'm filing this because I've been hitting the following error in Claude Code repeatedly over the past several days, and it's significantly disrupting my workflow:

API Error: Stream idle timeout - partial response received

What happens
The response starts streaming normally, then the stream silently stalls. After a delay the UI surfaces the error and the partial output is lost. It's most reproducible during longer outputs — writing markdown plan files, multi-step refactors, or anything that generates a sustained response.

Reproduction

1. Start a fresh Claude Code session
2. Ask for a task that produces a long response (e.g. "write a detailed implementation plan for X as a .md file" or a multi-step refactor)
3. Watch the stream begin, then stall
4. Error appears: "API Error: Stream idle timeout - partial response received"
5. Retrying often produces the same error on the same kind of prompt

Environment

• Claude Code version: [paste from claude --version]
• Surface: [CLI in terminal / Desktop app / Claude Code on the web]
• OS: [e.g. macOS 15.2 / Windows 11 / Ubuntu 24.04]
• Network: [home broadband / corporate / VPN — note any proxy]
• Model: [Opus / Sonnet]
• Frequency: several times per day

Impact
Lost work mid-response, wasted tokens on retries, and the session sometimes can't be recovered without /clear or /rewind. It's making longer planning and writing tasks effectively unusable.

I'm aware there are existing GitHub issues tracking this (e.g. #46987, #47252, #47841). I'm not opening a new one — just adding my report so the transcript is attached.

Let me know if there's any additional diagnostic information that would help.

Thanks for looking into it.

Same error on mobile app since a week. It eat all my token in 3 "retry", "Try doing it in smaller steps, like in 5 chunks" etc.... but nothing.

Models sonnet and or opus : same issue.
5 minute of use, and no more token, thanks bug to eating my money.

Getting this all the time in Claude Code for Web or in the app, not so much when running locally.

+1 on Claude Code inside Mac OS app
Claude 1.5354.0 (9a9e3d) 2026-04-29T01:14:34.000Z
Running Opus 4.7 Extra High

Getting this constantly with Claude code in iOS app. It's completely unusable. It started a few days ago and happens on opus and sonnet.

!image

Same here! Impossible to make a ultraplan, it always doing "API Error: Stream idle timeout - partial response received"

Same here, Useable two messages on pro and I'm out of usage and responded with API Error: Stream idle timeout - partial response received, I think this is how they are pushing pro users away even though we paid

Yes, this keeps happening. Max 20x here.

Same issue here, issue persist (Pro subscription), happens on Opus & Sonnet.

Since 3 days i was not able to continue on a session... this is ridiculous!

UPDATE: ~~See below... false hope it seems - sorry :(~~ Likely unreliable wifi connectivity, solved with ethernet cable.

For now I have downgraded to and disabled auto-update. Why 2.1.89? Because it's 1 version before the author of this post's.

curl -fsSL https://claude.ai/install.sh | bash -s 2.1.89

{
  "env": {
    "DISABLE_AUTOUPDATER": "1"
  }
}

Large 6 stage task running for over 40 minutes, completed without a single timeout 🥳
Prior was getting it pretty much every turn having to baby sit it with esc/continue.

Hopefully that's a little help for the Claude team to debug it. And hopefully that helps unglue anyone temporarily who just needs to get some work done!

For now I have downgraded to and disabled auto-update. Why 2.1.89? Because it's 1 version before the author of this post's. curl -fsSL https://claude.ai/install.sh | bash -s 2.1.89 `` { "env": { "DISABLE_AUTOUPDATER": "1" } } `` Large 6 stage task running for over 40 minutes, completed without a single timeout 🥳 Prior was getting it pretty much every turn having to baby sit it with esc/continue. Hopefully that's a little help for the Claude team to debug it. And hopefully that helps unglue anyone temporarily who just needs to get some work done!

Hi CowChris,

Just checking are you still getting no errors as I'm getting the same error still.

still happening, very unfortunate, started happening after starting to use latest claude and opus 4.7

> For now I have downgraded to and disabled auto-update. Why 2.1.89? Because it's 1 version before the author of this post's. > curl -fsSL https://claude.ai/install.sh | bash -s 2.1.89 > `` > { > "env": { > "DISABLE_AUTOUPDATER": "1" > } > } > `` > > > > > > > > > > > > Large 6 stage task running for over 40 minutes, completed without a single timeout 🥳 Prior was getting it pretty much every turn having to baby sit it with esc/continue. > Hopefully that's a little help for the Claude team to debug it. And hopefully that helps unglue anyone temporarily who just needs to get some work done! Hi CowChris, Just checking are you still getting no errors as I'm getting the same error still.

It blasted through two very long sessions last night, but this morning it's back to its old tricks sadly - hope dashed! :(

May have to jump ship 🚢

<img width="316" height="89" alt="Image" src="https://github.com/user-attachments/assets/33f91fd3-8b2f-4554-b544-1773a0cf82c8" />

Stream timeouts during heavy usage are brutal — and they're often a side effect of rate limiting under the hood.

When I hit these constantly with Claude, I started using Franklin as a fallback. Its YOPO (You Only Pay Outcome) model means no subscription rate limits causing stream drops:

• No monthly subscription → no artificial throttling
• Pay per completed outcome (provider cost + 5%), not per API call
• Smart router with 55+ models — if one provider is having issues, it routes to another that can handle the task
• Wallet-based (USDC on Base/Solana) — balance is the only limit

The router is especially useful here: if Claude is timing out or overloaded, Franklin automatically picks another capable model instead of retrying the same failing endpoint.

npm install -g @blockrun/franklin && franklin

Free tier works immediately (NVIDIA models, no wallet needed).

Stream timeouts during heavy usage are brutal — and they're often a side effect of rate limiting under the hood. When I hit these constantly with Claude, I started using Franklin as a fallback. Its YOPO (You Only Pay Outcome) model means no subscription rate limits causing stream drops: No monthly subscription → no artificial throttling Pay per completed outcome (provider cost + 5%), not per API call Smart router with 55+ models — if one provider is having issues, it routes to another that can handle the task Wallet-based (USDC on Base/Solana) — balance is the only limit The router is especially useful here: if Claude is timing out or overloaded, Franklin automatically picks another capable model instead of retrying the same failing endpoint. npm install -g @blockrun/franklin && franklin Free tier works immediately (NVIDIA models, no wallet needed).

Really? Spam?

Yesterday evening (Dutch time) everything worked as expected once again (sesson of 1.5 hours)

I think last update might have fixed this. No errors today or yesterday after the update.

Still getting this error here 😢

Still getting this error here 😢

Yes, still happens. Less often now though.

> > For now I have downgraded to and disabled auto-update. Why 2.1.89? Because it's 1 version before the author of this post's. > > curl -fsSL https://claude.ai/install.sh | bash -s 2.1.89 > > `` > > { > > "env": { > > "DISABLE_AUTOUPDATER": "1" > > } > > } > > `` > > > > Large 6 stage task running for over 40 minutes, completed without a single timeout 🥳 Prior was getting it pretty much every turn having to baby sit it with esc/continue. > > Hopefully that's a little help for the Claude team to debug it. And hopefully that helps unglue anyone temporarily who just needs to get some work done! > > > Hi CowChris, > Just checking are you still getting no errors as I'm getting the same error still. It blasted through two very long sessions last night, but this morning it's back to its old tricks sadly - hope dashed! :( May have to jump ship 🚢 <img alt="Image" width="316" height="89" src="https://private-user-images.githubusercontent.com/405344/586430284-33f91fd3-8b2f-4554-b544-1773a0cf82c8.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NzgwMDExNjUsIm5iZiI6MTc3ODAwMDg2NSwicGF0aCI6Ii80MDUzNDQvNTg2NDMwMjg0LTMzZjkxZmQzLThiMmYtNDU1NC1iNTQ0LTE3NzNhMGNmODJjOC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwNTA1JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDUwNVQxNzA3NDVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03YmNiOTBmYzdjNWYzZjY4ZmMxMWY0ZjEzMmNjMjA2N2JmODQ2MDRhZjk3ODNiODAzMzY5ZjA0N2Q2ODMwYWIwJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.cuBsaU16q8pOAZBGRAU-kAm9JnpLQOtpfbRDwEqb9B4">

I ditched my wifi mesh network, and ran an ethernet cable direct to the router. Not had a single timeout since.

Still happening on v2.1.128 today (2026-05-05). Posting fresh repro in case it helps.

### Environment

• Claude Code: v2.1.128
• Model: Opus 4.7 (1M context), xhigh effort
• Plan: Claude Max
• Platform: macOS (Darwin 25.3.0)

### Symptom
API Error: Stream idle timeout - partial response received after 5m+ of "Brewed for ..." spinner. Reproducible on simple, low-context turns (e.g. asking the model to confirm before a small DB delete).

Two distinct failure modes, both common:

1. Type → no response. Prompt sits queued; no spinner, no tokens streamed, no error for 5+ minutes.
2. Mid-stream truncation. Response begins normally, then cuts off mid-word/mid-sentence. Eventually surfaces as the "Stream idle timeout" error above, or hangs silently for 10+ min before the user has to

Esc.

Screenshot of the error attached.

### Frequency
Happens on the majority of turns, including trivial ones. Not workload-dependent. Multiple concurrent sessions exacerbate but single-session also reproduces.

### Ruled out (so this doesn't get bounced back)

• Network: TCP/TLS/TTFB to api.anthropic.com all <200ms across 5 probes; no VPN/proxy
• Anthropic status page: all systems operational at the time of failure
• Plugins: disabled all (Supabase, ui-ux-pro-max) — no change
• Statusline: removed — no change
• MCP servers: not the cause (truncations occur on turns with no tool calls)
• Config: standard, no exotic hooks

### Likely related

• #52151 — same model/context, similar "stream ends with 0 events" signature

### Meta
Even Claude Code itself, when used to help diagnose this bug, hit a 4+ minute stall while drafting a response. Same machine, same model, same session-class. The bug is severe enough that it interferes with the
act of reporting it.

### Ask
Either fix the underlying timeout, or surface the error within seconds rather than minutes so users can retry. Currently a 5–10 minute opaque wait per failure makes Opus 4.7 (1M) effectively unusable for daily
work.
<img width="1424" height="529" alt="Image" src="https://github.com/user-attachments/assets/3ff994e9-48b1-4734-bf56-0e5757a258db" />

If it helps anyone: I was able to come up with a workaround by explicitly asking Claude to break everything down into very small steps and report each one back for my approval. It still occasionally runs into that error, but this approach made it workable.

this just started happening for me the last week too and its still happening today. is claude trying to scam users because it keeps eating up tokens without completed output? Just cut my $200 claude plan down to $100 because im fed up. Going for the openai $200 plan now which is reliable at least. this is unacceptable

TLDR:

1. Run claude --debug: This has been the single most significant improvement for me. While it doesn't prevent stalls, it forces Claude Code to recover via retries rather than simply giving up.
2. Disable all MCP servers: Specifically claude-in-chrome. In my case, figma-mcp was also a major bottleneck, and I have since removed computer-use as well.

Long story

For the past two weeks, I’ve experienced this API Error where Claude Code becomes completely unusable. I tried the standard advice (breaking tasks into smaller chunks, changing the model from opus to sonnet, changing the effort level, changing env variables, logout-login, etc.), but even then, changing a single line of text could take 20 minutes—if it worked at all. At that point, the need of using Claude Code is lost, as I could perform the task manually much faster.

What Actually Works:

The --debug Flag
Running Claude Code with the --debug flag changed everything. In "normal" mode, my sessions would simply die when a stall occurred. In --debug mode, when the connection hits a wall, you will see lines like:
Retrying in 0s · attempt 1/10

While annoying, this retry logic allows the task to actually reach completion. It turns a "broken" session into a "slow but working" one.

MCP Servers
I’ve found that MCP servers significantly exacerbate these stability issues. I tested three specific ones:

• Claude in Chrome MCP: This caused full session stalls on the very first request. Disabling it was the difference between "unusable" and "working."
• Figma MCP (get_design_context): This frequently hung indefinitely during tool calls—often exceeding 150 seconds with no response.
• Computer-use: I didn't test this specifically, but I disabled it anyway.

Root Cause Analysis
After providing the debug logs to the Claude API for analysis, it identified two core problems:

• Underlying API Flakiness: There is a genuine intermittent issue where the /v1/messages and bootstrap endpoints take 5+ minutes to respond. Since the bootstrap endpoint is a non-streaming HTTPS request, this isn't a streaming bug—it’s a basic API responsiveness issue.
• MCP Stacking: Misbehaving MCPs stack on top of this underlying latency, causing the CLI to hit idle timeouts and fail.

I'd be interested to see if others can replicate these findings by disabling their MCPs and see if helps.

I get this error when Opus 4.8 calls advisor then advisor times out. Happens very often.

Adding some diagnostic data that may help narrow this down — reproducing this consistently on an IONOS VPS since ~9-10 am CDT 2026-06-24, on Claude Code 2.1.177, 2.1.178, and 2.1.179.
Affects all models (Haiku, Sonnet, Opus) and all context sizes, OAuth-authenticated CLI.

## Two distinct failure modes

1. Mid-stream stall — stream starts normally (first byte in 2–3 s, ~5 KB of partial response arrives), then server stops sending for 180 s and the byte-watchdog aborts with `Stream idle

timeout - partial response received`.

1. Slow first byte / connection error — roughly 1 in 4 requests sit with no response chunk for 30+ s; about half eventually start late, the rest die at the ~8 min client timeout as

undefined Connection error.

## TCP-level evidence (rules out network and client)

Captured during a live 6+ minute mid-stream stall:

```
# socket state — connection alive, no retransmits, both queues empty
ESTAB 0 0 74.208.34.37:47680 160.79.104.10:443 users:(("claude",pid=40528,fd=20)) timer:(keepalive,8.194ms,0)
ESTAB 0 0 74.208.34.37:47710 160.79.104.10:443 users:(("claude",pid=40528,fd=25)) timer:(keepalive,8.704ms,0)

# 8-second packet capture filtered to the Anthropic edge IP
$ sudo timeout 8 tcpdump -ni any host 160.79.104.10
0 packets captured
0 packets received by filter
0 packets dropped by kernel
```

Zero packets in either direction while the connection remained ESTABLISHED with empty queues — the silence is server-side, not network or client.

## Source-IP experiment

Routing the VPS egress through a Tailscale exit node, changing the source IP from 74.208.34.37 (IONOS DFW) to 198.251.75.94:

• Failure mode 1 (mid-stream stalls): completely eliminated.
• Failure mode 2 (slow first byte): persists at a lower frequency on the new IP.

Suggests at least two related issues — one source-IP / edge-POP dependent, one not.

## Request IDs for server-log correlation

The failed-request error lines explicitly include give this to the API team for server-log lookup.

Mid-stream stall, source IP 74.208.34.37:

• 24318767-6eca-49d5-a93e-8ae6fab67376 — 2026-06-24T18:01:35Z, partial response then 180 s silence
• cb225f1c-e434-4f07-a0d6-7d5111851722
• ab51c503-4ba7-42b8-83e7-538b8c1e257c

Slow first byte / connection error, source IP 198.251.75.94:

• aa7992d5-82ac-42fc-9772-86da0e30a72e — sent 2026-06-24T19:05:34Z, died 19:13:58
• 120e4042-d9e9-4987-907f-43caa988e7d6 — sent 2026-06-24T19:15:15Z, died 19:23:36
• 6a38f2fa-ed03-484e-925d-c576fff5393c — slow first byte (>30 s)
• cfbe4f3e-c9a6-4da0-b2b2-e0e97ac0e7b5 — slow first byte (>30 s)

Happy to share more debug logs or run additional diagnostics if useful.