[BUG] No Response From API 2.1.181, 2.1.183 (constantly)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/68739
2. https://github.com/anthropics/claude-code/issues/61473
3. https://github.com/anthropics/claude-code/issues/69336

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

Noticed the problem too. What is more interesting (though I am not sure if related) - 2.1.179 consumes significantly (2x) less tokens on same/similar tasks, maybe be because it Fixed mid-stream connection drops: partial responses are now preserved... and now we have a regression.

Found 3 possible duplicate issues: 1. [[BUG] Claude Code 2.1.170 — all sessions return no_response immediately on Windows 11, query iterator completes in 0s #68739](https://github.com/anthropics/claude-code/issues/68739) 2. [[BUG] Desktop app Code tab: session never returns first response on MacBook Pro M5 (unhealthy cycle 30s, no_response, no process crash) #61473](https://github.com/anthropics/claude-code/issues/61473) 3. [[BUG] API Error: Connection closed mid-response — occurs immediately in new context window #69336](https://github.com/anthropics/claude-code/issues/69336) 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

not a duplicate

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.

face the same in this version. more often in ultracode effort

Noticed the problem too. What is more interesting (though I am not sure if related) - 2.1.179 consumes _significantly_ (2x) less tokens on same/similar tasks, maybe be because it Fixed mid-stream connection drops: partial responses are now preserved... and now we have a regression.

Thank you for sharing this. I assume you did something like this:

Edit ~/.claude/settings.json to temporarily add

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

Then install 2.1.179

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

@chrisaustin-snyk Yes, I always had autoupdates disabled but blindly followed releases manually... until 2.1.181 hit me. I rolled back to 2.1.179 (the binary was still available) and everything is super-fine again (on my workflow, at least), so this is definitely a regression.

"Never change a running system" :)

Confirming this on macOS with plain Opus — no advisor involved. No response from API with retry timers, frequently, on any session. Still reproduces on 2.1.183. Downgrading to 2.1.179 (with DISABLE_AUTOUPDATER=1) resolves it completely, so this is a clear 2.1.181 regression.

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

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

I have tracking locked down, might be a useful clue. Idk if anyone ever looks at these issues though. We'll see.

+1 on this. Constantly over the last two days. Retries allow turns to proceed but lost of interruptions.

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

This work for me too.

Also affected on 2.1.183 (Linux, native install). Same intermittent No response from API with auto-retries throughout sessions.

Also affected on 2.1.183 (Linux, native install). Same intermittent No response from API with auto-retries throughout sessions.

I'm having the same blocker right now.
It doesn't depend on the version, my VS Code plugin is rather old - 2.1.170, and Claude Code in console has the version 2.0.61 (can't connect as well).
This error appeared today and now I can't do anything from my computer, while web version works fine.
...and there are no any issue mentions on the Claude status page, which is weird.

Is it being rate-limited, and even after downgrading it still is — just without the prompt showing up?

Is it being rate-limited, and even after downgrading it still is — just without the prompt showing up?

nah, it's just failing to connect to API sometimes. No problems on 2.1.179, so this seems new. Might be somehow related to setups where tracking/telemetry is disabled.

e.g., here is my settings file:

{
  "env": {
    "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1",
    "CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": "1",
    "DISABLE_ERROR_REPORTING": "1",
    "DISABLE_FEEDBACK_COMMAND": "1",
    "DISABLE_TELEMETRY": "1",
    "DISABLE_AUTOUPDATER": "1"
  },
  "enabledPlugins": {
    "pyright-lsp@claude-plugins-official": true
  },
  "feedbackSurveyRate": 0,
  "effortLevel": "xhigh",
  "autoUpdatesChannel": "latest",
  "autoMemoryEnabled": false,
  "skipWorkflowUsageWarning": true
}

Corroborating this from a different setup — same version window, same last-working version.

We see the same regression on clients pointed at a custom ANTHROPIC_BASE_URL (a LiteLLM proxy in front of Bedrock/Anthropic), specifically on large-context turns (~150k–500k input tokens). On 2.1.181–2.1.183 these abort intermittently; rolling back to 2.1.179 makes it go away — exactly as you found.

A couple of extra data points in case they help narrow it:

• At the load balancer in front of the proxy, the failures are HTTP 460 (client closed the connection before any response byte; target_processing_time = -1) — i.e. the client is aborting before first byte, not the server erroring.
• The backend is healthy: independent streaming probes through the same proxy return first byte in 13–20s even cache-cold at ~360k tokens, with full upstream rate-limit headroom. So it's client-side.
• In our org it hits only clients on a custom ANTHROPIC_BASE_URL — direct-API users are unaffected. That lines up with the 2.1.181 changelog entry "Fixed prompt caching not reading on custom ANTHROPIC_BASE_URL … due to a per-request attestation token changing every turn", which is a code path that only affects custom-base-URL clients.

Filed #69759 with the gateway-specific detail. Workaround that's holding for us: pin to 2.1.179 + DISABLE_AUTOUPDATER=1 so the background updater doesn't re-bump past it.

Corroborating on a native install hitting the default Anthropic endpoint (no custom ANTHROPIC_BASE_URL).

Setup: Claude Code 2.1.183 (native installer), Linux, Opus 4.8 (1M context), default api.anthropic.com, telemetry disabled (DISABLE_TELEMETRY=1, DISABLE_ERROR_REPORTING=1). Onset ~June 18–20, matching this thread; auto-retry recovers but it's a constant interruption.

Most reports here with low-level detail (e.g. the HTTP 460 / pre-first-byte aborts) are on custom proxy / base-URL setups. This looks like a distinct flavor on the default endpoint: the request does get its first byte, then stalls mid-stream and later recovers. Captured with --debug-file:

[API REQUEST] /v1/messages source=repl_main_thread
Stream started - received first chunk
[API:timing] first byte after 2477ms
[WARN] [Stall] stream_idle_partial lastChunkAgeMs=14999 bytesTotal=649 idleDeadlineMs=180000
[WARN] [Stall] stream_idle_partial lastChunkAgeMs=30000 bytesTotal=649
[WARN] Streaming stall detected: 44.4s gap between events (stall #1)
[WARN] Streaming completed with 1 stall(s), total stall time: 44.4s

First byte at 2.5s (backend healthy), then a ~44s gap holding a 649-byte partial response, then it resumes and completes within the 180s idle deadline. This is consistent with the earlier observation in this thread that 2.1.179's "Fixed mid-stream connection drops: partial responses are now preserved" appears to have regressed — the stall sits mid-stream on a preserved partial.

On the telemetry-disabled correlation several have noted: I've re-enabled telemetry (unset DISABLE_TELEMETRY) to test it and will follow up here with whether that clears the stalls. If it doesn't, rolling back to 2.1.179 is the fix others in this thread have confirmed.

I have been seeing these No response from API messages nearly continuously for a few days now. I have not tried outside my home network yet, but a Claude Code instance I spun up to diagnose seemed to indicate it could not find any obvious network faults. All other network activity seems unimpaired. Both a macOS and Linux host on the same network are impacted, but they do use essentially identical Claude Code configurations. Switching to Sonnet rather than using Opus to not lead to any improvement. The issue does not have any correlation to the amount of context a session has consumed. Completely fresh sessions are impacted as well.

I did an experiment with Claude Desktop on macOS, and while I did not see it explicitly report a No response from APIit did make a comment to the effect that it was taking longer than expected.

Thanks for the all the reports! This was a display-only bug in the response message and did not affect your actual usage, billing, or request handling. Fixed in v2.1.185. Please run claude update. Closing, but reply with your version if you still see it on v2.1.185+ and we'll reopen.

@jsat-ant I still get this message (but less frequent) with version v2.1.185.

Same at .185. Not sure if true, but it feels more frequent than before. It also feels longer before it actually retries.

I am also still experiencing this pretty consistently when Advisor is being called. I'm on 2.1.186.

+1 still happening at v2.1.201