Ultraplan: repeated 'Stream idle timeout' errors, approval UI never appears

I'm seeing the same issue repeatedly. Ultraplan is broken for me, every session terminates with this error at some point before I can get any result back.

API Error: Stream idle timeout - partial response received

<img width="649" height="178" alt="Image" src="https://github.com/user-attachments/assets/e91be665-f6e6-469b-8d1d-d21fe6853862" />

Same here. I've tried it four times, and I keep getting this same error.

<img width="493" height="112" alt="Image" src="https://github.com/user-attachments/assets/7d6e9388-f77a-4183-bdef-65104214197a" />

I'm also seeing the same issue. I keep getting the same message. When I ask for an update, the AI responds that it is writing the plan, but I soon get another identical error, and nothing seems to happen.

Same here., multiple time, various hours, still :

API Error: 500 {"type":"error","error":{"type":"api_error","message":"Internal server error"},"request_id":"req_011Ca21gxHBE43hgcxurAXoc"}

Authentication error · This may be a temporary network issue, please try again

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

<img width="724" height="277" alt="Image" src="https://github.com/user-attachments/assets/504cc8df-7231-4239-ad16-adc28ba5a469" />

I can replicate, can't get ultra plan to return whatever it planned back to the local terminal.

I have replicated this many times as well. Here is one such example.

<img width="802" height="236" alt="Image" src="https://github.com/user-attachments/assets/b9ed6efd-03ce-4c71-b247-38a7720376b1" />

any update on this ? We're paying way too much money to not be able to use this. Getting the same here:

<img width="878" height="352" alt="Image" src="https://github.com/user-attachments/assets/2ae890e1-1d75-43ef-85e3-79ef92342f8c" />

same

Running into this issue again and again

<img width="845" height="96" alt="Image" src="https://github.com/user-attachments/assets/f65ede73-59eb-4a00-b2f8-14fad30ce280" />

Same here, repeatedly getting this error. Ultraplan is great otherwise but this makes it near unusable

<img width="1303" height="203" alt="Image" src="https://github.com/user-attachments/assets/ab9c0983-bc13-42cc-912d-f8b321c3241c" />

A workaround is to ask Claude to write the plan in stages and to keep the request body small, but I'm almost certain this means the plan loses detail.

Also experiencing this issue here.

<img width="1446" height="844" alt="Image" src="https://github.com/user-attachments/assets/ebda13d3-555f-4f0c-8587-56c2b8f3d4b6" />

I understand that you want to start convincing users to use cloud agents by putting ultraplan in in claude.ai, but this is an unuseable feature that could certainly work locally.

Same exact issue, I'm glad I'm not the only one, but tbh it's incredibly frustrating to pay $200 a month for Claude. Lately it's been way more misses than hits, and it's incredibly disappointing.

<img width="1474" height="1298" alt="Image" src="https://github.com/user-attachments/assets/7bd0c012-6877-46ec-81d2-e1925c5a2c14" />

I have the exact same issue. Tried 10x times but same result.

Also facing the same issue. It has been a problem since the release of this feature...and it seems to get worse as time goes on...

Same today for me impossible to use /ultraplan

Great when it works but it is really broken, I get there errors constantly. Wasted about $15 at work without a plan to show for it. Don't charge us if the tool fails!

same issue here:

<img width="858" height="339" alt="Image" src="https://github.com/user-attachments/assets/a0975327-744e-466e-9b2e-ded060d74ba2" />

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.

same issue

<img width="808" height="536" alt="Image" src="https://github.com/user-attachments/assets/d284f7ca-e448-4376-8a7c-09e3ebcd2b4e" />

I waste time and my 5h window of tokens... I cannot find any file or result. Where are the artifacts stored?

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

Blessed be your soul CaptFaraday

Sometimes even with @CaptFaraday it seems to reset. Worst case I found having claude make small edits or make it do it section by section helps. It's kinda embarrassing that anthropic doesn't even seem to care about this issue. But to be honest ultra plan isn't even worth the trouble when it's working. It's just a buggy mess.

Blessed be your soul CaptFaraday

I was stressed! Haha

@CaptFaraday
That actually worked! thank you

Same issue here, getting random errors (sometimes a result) on Opus and Sonnet models. Stream idle timeout - partial response received.

has the fix been tested?