[BUG] No response from API error when Advisor is triggered

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68502
2. https://github.com/anthropics/claude-code/issues/61529
3. https://github.com/anthropics/claude-code/issues/65397

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

Seeing this a lot today on Opus on an Enterprise account. The 3 minute delay between actions are really speeding up my workflow.

I am seeing what appears to be the same or a closely related issue.

Observed behavior

Claude Code accepts the prompt and starts thinking, but the session later fails with either:

no response from API

or, in a later run:

API Error: Overloaded

This seems correlated with the advisor tool. In the same session, after disabling advisor with:

/advisor off

I was able to continue the session, which makes this look less like a basic login/authentication issue and more like an advisor-triggered API/tool-call failure.

Environment

• macOS / darwin-arm64
• Claude Code native 2.1.181
• Install method: native
• claude doctor showed the CLI itself running successfully
• Configured MCP servers reported by claude mcp remove were memory and slack
• claude doctor also showed a failed claude_design MCP/connector warning, but claude mcp remove claude_design reported no configured server with that name

Notes

• New sessions reproduced the issue.
• The prompt is accepted and thinking starts before the failure.
• Disabling advisor appears to mitigate it.
• I also saw API Error: Overloaded, so this may be related to advisor calls surfacing overload/upstream failures as a generic no response from API in the main session.

Expected behavior: if advisor fails, times out, or receives overload from upstream, Claude Code should either continue without advisor or report advisor as the failing component rather than ending the main interaction with a generic no response from API.

I'd like to confirm an unusual uptick in no response from API

same. experiencing this too

Same here. I'm on Claude code v2.1.181. Haven't tried a downgrade yet. A new version v2.1.183 just released which I haven't tried yet, although the release notes don't mention anything about fixing this.

reproduced on v2.1.183, using opus directly no adviser

The fact that Anthropic's status page doesn't even mention this, and that getting the support chatbot to escalate to a human means you can't expect a response for >3 months is exceptionally frustrating. Please any Anthropic staff reading this - escalate this issue.

The fact that Anthropic's status page doesn't even mention this, and that getting the support chatbot to escalate to a human means you can't expect a response for >3 months is exceptionally frustrating. Please any Anthropic staff reading this - escalate this issue.

A conspiratorial mind might think that fewer API responses and a slow support path might help Anthropic's compute demands.

Also facing the same issue.

Same issue, super annoying and forcing me to use the desktop app instead, it's unbearable

Does not happen in v2.1.179 after downgrading, although I am not sure if that is just because it's not being surfaced with a message. There are still periods where it's supposedly "thinking" for quite some time.

Would be cool if my vibe coding software wasn't vibe coded without testing so I could vibe code in peace

i change DO_NOT_TRACK from "1" to "0" then stop getting this error. probably worth try

Been getting this error all day to the point CC is useless. 'claude install stable' and this goes away.

This is really getting to the point that that CC is useless

I'm trying 2.1.185 now which addresses this: https://github.com/anthropics/claude-code/releases/tag/v2.1.185

I also had these environment flags on before:

        CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY = "1";
        CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC = "1";

I'm trying 2.1.185 now which addresses this: https://github.com/anthropics/claude-code/releases/tag/v2.1.185 I also had these environment flags on before: `` CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY = "1"; CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC = "1"; ``

These vars still block advisor usage. The fix seems to be just a simple text update in 2.1.185. It's still slow as before to me.

Also reproduced on 2.1.187 — the banner now shows as Waiting for API response... · check your network.

Running claude --debug makes the root cause clear. Per the Claude API Docs, while an advisor call is pending the stream sends a standard SSE keepalive ping roughly every 30 seconds. However, Claude Code flags the stream as idle at a ~15s threshold. Because the idle threshold is shorter than the keepalive interval, a perfectly normal advisor wait trips the stall warning and surfaces check your network to the user.

Reconstructing each chunk (= keepalive ping) arrival time from bytesTotal and lastChunkAgeMs in the debug log below:

• bytesTotal=2510 → last chunk ≈ 01:52:42.614 (advisor call start)
• bytesTotal=2546 (+36B) → last chunk ≈ 01:53:08.655 (+26.0s)
• bytesTotal=2582 (+36B) → last chunk ≈ 01:53:38.656 (+30.0s)

Each ping adds ~36 bytes, and the steady-state interval is exactly 30.0s, matching the documented keepalive cadence. Meanwhile stream_idle_partial fires whenever lastChunkAgeMs reaches ~15,000ms (15s) — i.e. at the midpoint of every 30s keepalive gap. So a single 90.7s advisor call produced 3 stall warnings.

Note the documented TUI banner threshold (20s as of v2.1.185+) is also shorter than the 30s keepalive, so it shares the same collision structure.

Actual log

2026-06-24T01:52:42.615Z [DEBUG] [AdvisorTool] Advisor tool called
2026-06-24T01:52:57.631Z [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15017 bytesTotal=2510 idleDeadlineMs=180000
2026-06-24T01:53:23.660Z [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15005 bytesTotal=2546 idleDeadlineMs=180000
2026-06-24T01:53:53.665Z [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15009 bytesTotal=2582 idleDeadlineMs=180000
2026-06-24T01:54:13.336Z [WARN] Streaming stall detected: 90.7s gap between events (stall #1)
2026-06-24T01:54:13.338Z [DEBUG] [AdvisorTool] Advisor tool result received
2026-06-24T01:54:15.941Z [WARN] Streaming completed with 1 stall(s), total stall time: 90.7s

Expected behavior

The stall detector should treat the advisor server_tool_use pause as a normal wait, or raise the idle threshold above the keepalive interval (30s) while an advisor call is pending.

Environment

• Claude Code: 2.1.187
• Base / Advisor model: _Opus 4.8 / Opus 4.8_
• Platform: _Windows(vs code powershell)_

As @Gyupil added, bug is now presented in 2.1.187 as Waiting for API response ... retrying in <X>m <X> s... · check your network, even when my network connection is perfect.

However, I wanted to add another failure. Upon the retry timer hitting 0, the message still hangs for up to ~2 minutes with retrying in 0s listed. After that, the API request tends to go through and the Advisor tool completes as expected.

So not only does the Advisor request tend to hang, but the CLI action triggering another request after the timer expires is _also_ hanging for minutes at a time.

facing same issue in linux on claude version v2.1.187

Just started having the same issue this morning on v2.1.187. was receiving a few advisor overloaded responses yesterday but now it just hangs as has been described above.

<img width="413" height="104" alt="Image" src="https://github.com/user-attachments/assets/cb7c6cf6-9e41-4242-bf4e-f62c0386beda" />

New error I'm getting.

This is such an obvious problem, why hasn't it been fixed yet?! Versions after 2.1.179 have serious issues; the already slow Claude code becomes even slower!

Please any Anthropic staff reading this - escalate this issue. 🏎️

<img width="1730" height="156" alt="Image" src="https://github.com/user-attachments/assets/84395365-9202-4a11-8ad7-d38f933f66a7" />

The issue still exists in the latest version (2.1.195). It continues to waste our time and disrupt our workflow.

I believe a fix went out for this about a week ago, I'm no longer having the problem

facing the same behavior for about 2 weeks already on 2.1.195 version.

<img width="1000" alt="Image" src="https://github.com/user-attachments/assets/adaea07b-e20b-42de-99e6-bb196f4a006e" />

i have this error for quite some time too
<img width="779" height="95" alt="Image" src="https://github.com/user-attachments/assets/3a464f16-312d-4552-af42-1198d08f84c3" />

<img width="802" height="301" alt="Image" src="https://github.com/user-attachments/assets/731a02c8-bc97-4b9d-8938-cd31238da5ed" />

Still having this issue. Used to work perfectly until a week or two ago after they turned off Fable. No idea if that's related, but on Fable release, had no issues.

Even in the latest version, I'm still running into this issue. It seems all it actually triggers is a "network exception" display error.

still same error for me as well

I have the same issue. I like using the Advisor so I hope this can be fixed soon.

@Gyupil's breakdown above is right, and I can add two things that aren't in the thread yet: a workaround that's been holding up for me, and one setting that looks like it should help but doesn't.

To be clear on the failure mode: the advisor works when it's allowed to finish, but the trouble is that it often isn't. The check your network banner Gyupil traced to the ~15s stall threshold colliding with the 30s keepalive is the noisy version. The one that actually kills a call is the fatal byte-idle deadline in those same logs, idleDeadlineMs=180000 (3 minutes with no bytes on the stream): once an advisor call's stream stays silent that long it's aborted and retried even though it's still working server-side, so a slow call gets cut off before it can return. That deadline is the firstParty (direct Anthropic API) byte-idle default, clamped to [10000, 1800000] (10 s to 30 min), and it's identical across the builds I checked (2.1.195, 2.1.196, 2.1.197).

Workaround: raise the idle timeout to 30 minutes

Since that deadline is configurable, two env vars widen it so a slow advisor call runs to completion instead of getting cut off at 3 minutes. This is what I'm running:

CLAUDE_STREAM_IDLE_TIMEOUT_MS=1800000
API_TIMEOUT_MS=1800000

CLAUDE_STREAM_IDLE_TIMEOUT_MS raises the idle watchdog itself (30 minutes is the cap; larger values clamp), and API_TIMEOUT_MS raises the overall per-request ceiling to match, so the request isn't capped at the 10-minute default once the watchdog is lifted. They're read at launch, so a restart is needed; afterward the will retry countdown starts near 30 minutes instead of 3, which confirms it took effect.

Why it helps: any byte on the stream resets the idle timer, keepalive pings included, so the fatal deadline only fires after 3 full minutes with nothing arriving at all, which in turn means the documented 30s ping isn't always there. The retry timer hitting zero (reported above) is that case, and when it happens the abort kills an advisor call that's still alive. Moving the window out to 30 minutes gives that call room to finish instead. It doesn't disable the watchdog, so a genuinely dead stream still recovers, it just waits longer first. Two things it won't do: quiet the ~15s stall warnings, and fix the case some folks describe where the retry never fires after an abort.

CLAUDE_CODE_RETRY_WATCHDOG won't help here

Worth calling out since the v2.1.186 notes point unattended sessions at it: CLAUDE_CODE_RETRY_WATCHDOG does nothing for this one. It only changes how Anthropic-side overloads and rate limits get retried (529 / 429 / 5xx), which are matched by an API-error-with-status check. The idle abort raises a StreamIdleTimeoutError, which isn't an API error with a status, so none of the retry-watchdog branches fire.

On Gyupil's suggested fix (treat the advisor server_tool_use pause as a normal wait, or raise the threshold while a call is pending): the server_tool_use events are right there on the stream, so the client could scope the threshold to a pending advisor call. There's just no such branch in the idle resolver today; it would have to be added.

---
Disclosure: the binary analysis and this write-up were done by Claude Code (drafted with Claude Opus 4.8, final review with Claude Fable 5).

Still seeing this on 2.1.200

Still not fixed in the latest patch...

same issue

same issue here.

claude --version
2.1.193 (Claude Code)

same here on 2.1.193

@Gyupil's breakdown above is right, and I can add two things that aren't in the thread yet: a workaround that's been holding up for me, and one setting that looks like it should help but doesn't. To be clear on the failure mode: the advisor works when it's allowed to finish, but the trouble is that it often isn't. The check your network banner Gyupil traced to the ~15s stall threshold colliding with the 30s keepalive is the noisy version. The one that actually kills a call is the fatal byte-idle deadline in those same logs, idleDeadlineMs=180000 (3 minutes with no bytes on the stream): once an advisor call's stream stays silent that long it's aborted and retried even though it's still working server-side, so a slow call gets cut off before it can return. That deadline is the firstParty (direct Anthropic API) byte-idle default, clamped to [10000, 1800000] (10 s to 30 min), and it's identical across the builds I checked (2.1.195, 2.1.196, 2.1.197). ## Workaround: raise the idle timeout to 30 minutes Since that deadline is configurable, two env vars widen it so a slow advisor call runs to completion instead of getting cut off at 3 minutes. This is what I'm running: `` CLAUDE_STREAM_IDLE_TIMEOUT_MS=1800000 API_TIMEOUT_MS=1800000 ` CLAUDE_STREAM_IDLE_TIMEOUT_MS raises the idle watchdog itself (30 minutes is the cap; larger values clamp), and API_TIMEOUT_MS raises the overall per-request ceiling to match, so the request isn't capped at the 10-minute default once the watchdog is lifted. They're read at launch, so a restart is needed; afterward the will retry countdown starts near 30 minutes instead of 3, which confirms it took effect. Why it helps: any byte on the stream resets the idle timer, keepalive pings included, so the fatal deadline only fires after 3 full minutes with nothing arriving at all, which in turn means the documented 30s ping isn't always there. The retry timer hitting zero (reported above) is that case, and when it happens the abort kills an advisor call that's still alive. Moving the window out to 30 minutes gives that call room to finish instead. It doesn't disable the watchdog, so a genuinely dead stream still recovers, it just waits longer first. Two things it won't do: quiet the ~15s stall warnings, and fix the case some folks describe where the retry never fires after an abort. ## CLAUDE_CODE_RETRY_WATCHDOG won't help here Worth calling out since the v2.1.186 notes point unattended sessions at it: CLAUDE_CODE_RETRY_WATCHDOG does nothing for this one. It only changes how Anthropic-side overloads and rate limits get retried (529 / 429 / 5xx), which are matched by an API-error-with-status check. The idle abort raises a StreamIdleTimeoutError, which isn't an API error with a status, so none of the retry-watchdog branches fire. On Gyupil's suggested fix (treat the advisor server_tool_use pause as a normal wait, or raise the threshold while a call is pending): the server_tool_use` events are right there on the stream, so the client could scope the threshold to a pending advisor call. There's just no such branch in the idle resolver today; it would have to be added. Disclosure: the binary analysis and this write-up were done by Claude Code (drafted with Claude Opus 4.8, final review with Claude Fable 5).

what an impenetrable slop fest this comment is 🤦‍♂️

> @Gyupil's breakdown above is right, and I can add two things that aren't in the thread yet: a workaround that's been holding up for me, and one setting that looks like it should help but doesn't. > To be clear on the failure mode: the advisor works when it's allowed to finish, but the trouble is that it often isn't. The check your network banner Gyupil traced to the ~15s stall threshold colliding with the 30s keepalive is the noisy version. The one that actually kills a call is the fatal byte-idle deadline in those same logs, idleDeadlineMs=180000 (3 minutes with no bytes on the stream): once an advisor call's stream stays silent that long it's aborted and retried even though it's still working server-side, so a slow call gets cut off before it can return. That deadline is the firstParty (direct Anthropic API) byte-idle default, clamped to [10000, 1800000] (10 s to 30 min), and it's identical across the builds I checked (2.1.195, 2.1.196, 2.1.197). > ## Workaround: raise the idle timeout to 30 minutes > Since that deadline is configurable, two env vars widen it so a slow advisor call runs to completion instead of getting cut off at 3 minutes. This is what I'm running: > `` > CLAUDE_STREAM_IDLE_TIMEOUT_MS=1800000 > API_TIMEOUT_MS=1800000 > ` > > > > > > > > > > > > CLAUDE_STREAM_IDLE_TIMEOUT_MS raises the idle watchdog itself (30 minutes is the cap; larger values clamp), and API_TIMEOUT_MS raises the overall per-request ceiling to match, so the request isn't capped at the 10-minute default once the watchdog is lifted. They're read at launch, so a restart is needed; afterward the will retry countdown starts near 30 minutes instead of 3, which confirms it took effect. > Why it helps: any byte on the stream resets the idle timer, keepalive pings included, so the fatal deadline only fires after 3 full minutes with nothing arriving at all, which in turn means the documented 30s ping isn't always there. The retry timer hitting zero (reported above) is that case, and when it happens the abort kills an advisor call that's still alive. Moving the window out to 30 minutes gives that call room to finish instead. It doesn't disable the watchdog, so a genuinely dead stream still recovers, it just waits longer first. Two things it won't do: quiet the ~15s stall warnings, and fix the case some folks describe where the retry never fires after an abort. > ## CLAUDE_CODE_RETRY_WATCHDOG won't help here > Worth calling out since the v2.1.186 notes point unattended sessions at it: CLAUDE_CODE_RETRY_WATCHDOG does nothing for this one. It only changes how Anthropic-side overloads and rate limits get retried (529 / 429 / 5xx), which are matched by an API-error-with-status check. The idle abort raises a StreamIdleTimeoutError, which isn't an API error with a status, so none of the retry-watchdog branches fire. > On Gyupil's suggested fix (treat the advisor server_tool_use pause as a normal wait, or raise the threshold while a call is pending): the server_tool_use` events are right there on the stream, so the client could scope the threshold to a pending advisor call. There's just no such branch in the idle resolver today; it would have to be added. > Disclosure: the binary analysis and this write-up were done by Claude Code (drafted with Claude Opus 4.8, final review with Claude Fable 5). what an impenetrable slop fest this comment is 🤦‍♂️

@RogerLevy

1. I disclosed that I used AI to write that comment.
2. I iterated on that comment several times so it's not pure slop farted out from Claude.
3. I spent a few hours working through this with Claude, it's not one-shot slop.
4. I read the entire comment before posting it.
5. It's not even a long comment? It's a few minutes of reading...
6. The workaround I gave _actually works._

Just because AI was used to write something doesn't mean it was vibed without any human input... And doesn't mean it has no value. And this repo is for Claude Code, so don't act surprised when you see AI-generated content here. Especially when it was voluntarily disclosed that AI was used to write something.

The issue seems to persist in 2.1.201

Confirm it's still on v2.1.201

Still exists in 2.1.203
It's actually hilarious.

<img width="1576" height="157" alt="Image" src="https://github.com/user-attachments/assets/8e05cada-ae3e-4438-8b5c-ddc38f810acc" />

still exists :(

Still exists in 2.1.205.
First Advise attempt failing with Waiting for API response but second attempt usually works.

Still an issue in v2.1.206...

The advisor is still functional and you can fix it by elongating the 3 minute timeout to the maximum of 30 minutes following what I wrote in my comment: https://github.com/anthropics/claude-code/issues/69238#issuecomment-4859833268

Since advising attempts can often take more than 3 minutes, that's why you're seeing advising attempts fail because of this bug. But changing the timeout from 3 minutes to 30 minutes fixes that and then the advisor is literally functional like normal again.

The Waiting for API response message will still be there but it won't kill the advisor after 3 minutes anymore.

Still exists

still exists