claude-code - 💡(How to fix) Fix API Error: Stream idle timeout — disproportionately frequent in plan-mode, no automatic retry or workaround [2 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#53730Fetched 2026-04-28 06:48:34
View on GitHub
Comments
2
Participants
3
Timeline
7
Reactions
0
Author
Timeline (top)
labeled ×5commented ×2

Error Message

API Error: Stream idle timeout - partial response received

Fix Action

Fix / Workaround

I am aware multiple open issues exist for this error. I'm filing this specifically to add:

  1. Confirmed reproduction on web version (not just CLI/desktop).
  2. The plan-mode amplification — the error rate in plan-mode is meaningfully higher than in normal mode, suggesting the longer generation time / larger payloads in plan-mode push into the timeout window more consistently.
  3. The lack of automatic continuation and waiting for some kind of workarounds on the part of claude to solve the problem as the most unpleasant aspect, the error itself may be inevitable on a large scale, but failure without automatic repeated attempts to continue is the part that makes it a problem.

Code Example

API Error: Stream idle timeout - partial response received
RAW_BUFFERClick to expand / collapse

Environment

  • Client: Claude Code web version (claude.ai/code)
  • Mode when most affected: Plan mode (plan-mode)
  • Date range: ongoing, observed repeatedly in April 2026

What happens

When generating a response (especially in plan-mode with long multi-step reasoning), Claude Code throws:

API Error: Stream idle timeout - partial response received

The stream is simply cut mid-response and the full answer is never delivered.


Reproduction frequency

  • In plan-mode: triggered 5+ times consecutively in a single session without any change on my end.
  • Across the full session: 10–15+ occurrences — nearly back-to-back.
  • Outside plan-mode it still occurs, but less frequently.

Impact

  • In plan-mode, which is intentionally used for long, structured reasoning, the timeout makes the feature nearly unusable under current network / infrastructure conditions.
  • Users (myself included) have to prompt 5–15 times to complete a single plan-mode task that should take one response.

What I would expect

  • Best: plan-mode chunking — for very long plan-mode responses, split into smaller streamed chunks server-side before the idle timeout threshold is hit.

Notes

I am aware multiple open issues exist for this error. I'm filing this specifically to add:

  1. Confirmed reproduction on web version (not just CLI/desktop).
  2. The plan-mode amplification — the error rate in plan-mode is meaningfully higher than in normal mode, suggesting the longer generation time / larger payloads in plan-mode push into the timeout window more consistently.
  3. The lack of automatic continuation and waiting for some kind of workarounds on the part of claude to solve the problem as the most unpleasant aspect, the error itself may be inevitable on a large scale, but failure without automatic repeated attempts to continue is the part that makes it a problem.

extent analysis

TL;DR

Implementing plan-mode chunking, where long responses are split into smaller streamed chunks server-side, could mitigate the API Error: Stream idle timeout issue.

Guidance

  • Investigate the current server-side streaming configuration to identify the idle timeout threshold and consider adjusting it to accommodate longer plan-mode responses.
  • Explore implementing a retry mechanism on the client-side to automatically resend the request when a stream idle timeout error occurs, potentially with exponential backoff to avoid overwhelming the server.
  • Consider implementing plan-mode chunking as suggested, where the server splits long responses into smaller, manageable chunks, to prevent the idle timeout from being triggered.
  • Monitor the error frequency and reproduction steps to gather more data on the issue, which could help in fine-tuning the solution.

Example

No specific code example can be provided without knowing the exact implementation details, but a general approach might involve modifying the server-side response handling to include chunking, such as:

def stream_response(data):
    chunk_size = 1024  # Example chunk size
    for i in range(0, len(data), chunk_size):
        yield data[i:i + chunk_size]

Notes

The provided guidance assumes that the issue is primarily related to the length of the responses in plan-mode and the server's idle timeout configuration. Without access to the specific implementation details of Claude Code's server and client architecture, these suggestions are based on general principles of handling large responses and mitigating timeout errors.

Recommendation

Apply workaround: Implement plan-mode chunking or a client-side retry mechanism to mitigate the API Error: Stream idle timeout issue, as upgrading to a fixed version is not mentioned as an option in the provided context.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING