[Bug][Urgent] Claude Code API responses extremely slow with Claude 4.6 Sonnet/Opus (5+ minute latency)

Status Closed — not planned

Reported on v2.1.76

Maintainer reply None cached

Activity 13 comments · opened Mar 15, 2026 · closed May 28, 2026

Bug Description
Summary: Claude code is very very slow(practically unusable).
Another problem that comes with this is that when I launch claude from the terminal, there is a chance that it will take several minutes to open.

Detail: Since upgrading to Claude Max, Claude Code has become so slow that it’s practically unusable. For a simple prompt, there is a 20% probability, the API takes about 5 minutes to respond. I’ve also noticed that this is a hit-or-miss issue—it either responds very quickly or extremely slowly, with no middle ground(such as a 20–200-second response time.) This creates a problem: in the context of a complex task involving numerous API requests, if even one request gets stuck, my task cannot proceed. This means I can hardly get Claude Code to perform any tasks at all.

Environment Info

Platform: darwin
Terminal: tmux
Version: 2.1.76
Feedback ID: 24f29bc7-b6a1-44cf-bd2a-4ca8b4c3c586

Errors

[{"error":"Error\n    at QI (/$bunfs/root/src/entrypoints/cli.js:74:1144)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:79:10005)\n    at emit (node:events:92:22)\n    at endReadableNT (internal:streams/readable:861:50)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/src/entrypoints/cli.js:81:2149)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-15T11:56:20.412Z"},{"error":"Error\n    at QI (/$bunfs/root/src/entrypoints/cli.js:74:1144)\n    at <anonymous> (/$bunfs/root/src/entrypoints/cli.js:79:10005)\n    at emit (node:events:92:22)\n    at endReadableNT (internal:streams/readable:861:50)\n    at processTicksAndRejections (native:7:39)\n    at request (/$bunfs/root/src/entrypoints/cli.js:81:2149)\n    at processTicksAndRejections (native:7:39)","timestamp":"2026-03-15T12:03:01.109Z"}]

For example:
The first four "hello" requests returned at normal speed, but the last "hello" request took more than 5 minutes to return.
<img width="1544" height="1642" alt="Image" src="https://github.com/user-attachments/assets/555253a7-1626-4a87-a6e8-030af62b2066" />

View original on GitHub ↗

13 Comments

github-actions[bot] · 5 months ago

Found 3 possible duplicate issues:

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

tinyfeng · 5 months ago

In the example above, I tried a few more times, and the issue occurred again.

uckmhnds · 5 months ago

Both API and Claude Code is extremely slow. I was unable to work all day. Lost $$

leekingsman1-cmyk · 5 months ago

Here's the updated comment:

---

Bug report: Opus 4.6 hangs and times out on complex tasks in Claude Code VS Code Extension

Plan: Claude Pro
Claude Code Version: 2.1.76
OS: Windows
IDE: Visual Studio Code (VS Code Extension)

Issue: When using Opus 4.6 in the Claude Code VS Code Extension for complex tasks, the model does not respond at all — it just hangs indefinitely until a session timeout error is returned. There is no partial response or progress during the wait.

This only happens when attempting more complex tasks with Opus. Simpler tasks may behave differently.

This makes Opus effectively unusable for complex work in the VS Code extension on my setup. Happy to provide additional details if helpful.

---

jeannen · 5 months ago

Same issue here, every little action takes at least 30 second or so while it used to be almost instant before

leekingsman1-cmyk · 5 months ago

Its working on the desktop app though.

sefinek · 4 months ago

Lately, Claude Code has been getting slower and slower. It wasn't like this a few months ago

haiyan710 · 4 months ago

<img width="904" height="88" alt="Image" src="https://github.com/user-attachments/assets/666b5005-11e8-4065-a496-0a82549038d2" />
same here. my tokens for max subscription has been deducted for nothing.

sefinek · 4 months ago

I agree, @haiyan710. For some reason I hit the limit faster, even though the conversation wasn't even long

haiyan710 · 4 months ago

@sefinek I can't even get any files created or edited by claude code at all lol and my weekly limit has already been used up for more than 10%.

iveelane-fdatracker · 4 months ago

TL;DR

Claude Code CLI consistently fails with API Error: Unable to connect to API (ECONNRESET) against https://api.anthropic.com/v1/messages?beta=true after exhausting its 10-retry budget, specifically on long-running turns in sessions with large accumulated context. The errors are mid-stream resets, not connect-time failures — the server has already accepted the request and begun writing the response when the socket is RST'd. Retry-1 recovers ~64% of failures; retry-2 recovers only ~23%; retries 3–10 are effectively useless on the same turn. I have ~5 weeks of on-disk evidence across 11 projects and 17 sessions.

Full diagnostic report (41 KB, fully de-identified for public posting) is attached at the end of this issue.

Environment

| | |
|---|---|
| Claude Code versions seen in errors | 13 distinct, including current 2.1.114 |
| Model | claude-opus-4-7, including the 1M-context variant (claude-opus-4-7[1m]) in at least some of the affected sessions. Note: Claude Code's session jsonl records message.model as claude-opus-4-7 whether the 1M tier is active or not, so the log cannot distinguish 1M from standard context — this is itself worth fixing (see asks below). |
| OS | macOS 26.3, Apple Silicon iMac |
| Network | Comcast residential, no VPN, no proxy, no corporate filtering, no local packet-filter rules |
| ISP / path | Comcast CGNAT → Comcast iBone → Cloudflare peering → 160.79.104.10 |
| Connect-path health at rest | TCP 22–29 ms, TLS 1.3 51–64 ms, 100% handshake success across 11 probe rounds |

Reproduction pattern

Not a clean one-liner — this is a failure mode that emerges on large accumulated contexts:

Work a Claude Code session long enough that the on-disk .jsonl exceeds ~6 MB (roughly a multi-hour session with many tool calls).
Issue a prompt that requires a long generation or many tool-call round-trips in one turn.
Observe API Error: Unable to connect to API (ECONNRESET) after ~10–20 minutes of retrying.

In my data, sessions >= 6 MB account for 74.6% of size-attributable errors despite being only 1.8% of all sessions on disk.

Key evidence from the data

325 ECONNRESETs across 17 sessions / 11 projects, all against /v1/messages?beta=true.
Handshake is not the problem. 11 separate probe rounds showed 100% success with healthy timings. The resets happen after the request body has been accepted and the response has started streaming.
cf-ray, server: cloudflare, x-envoy-upstream-service-time all present on successful responses — the failing path is Cloudflare → Envoy → inference worker. The failure mode produces a raw TCP RST rather than a clean 5xx.
Retry decay curve: retry-1 success 63.6% → retry-2 22.5% → retry-3+ near zero. Classic "request can't fit in whatever budget is killing it" signature.
Longest failing turn: 20.7 minutes before the client gave up. Shape is well outside typical CDN/LB idle defaults.
The 1M-context Opus variant was in active use during at least some of the affected sessions (user testimony; unprovable from logs because Claude Code doesn't record the context tier — see ask #8). The 1M tier's larger payloads and potentially distinct backend routing may be a compounding factor or even the dominant failure surface.
Secondary signal (~22% of errors): co-time (per local hour) with net::ERR_INTERNET_DISCONNECTED events in the Claude desktop app's main.log. This rules out Wi-Fi link layer as the mechanism (confirmed by 72 h of debug-level log show --predicate 'subsystem == "com.apple.wifi"' with zero deauth / disassoc / roam / beacon-loss events) and points to CGNAT conntrack eviction or ISP-edge flaps on long-lived streams.

github-actions[bot] · 3 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.