[BUG] Intermittent mid-stream SSE stall — Opus 4.7/4.8, Sonnet 4.6, pause token emission 40–600s mid-response, latency increasing (VS Code extension)

Preflight Checklist

I have searched existing issues and this hasn't been reported yet

This is a single bug report (please file separate reports for different bugs)

I am using the latest version of Claude Code

UPDATE — 2026-06-03: scope is account-wide, not a single experiment cohort

Following the original report (6 stalls, Opus only, 100% cc_version=2.1.160.e42), I captured 3 more stalls that supersede the single-cohort hypothesis. Stalls now span a second model family (Sonnet 4.6), a newer client build (2.1.161), and four distinct cc_version variants. The original request to be removed from the .e42 cohort is therefore moot — this is not experiment- or model-specific. Revised picture and consolidated evidence below.

Scope — NOT model- or experiment-specific

9 stalls in one morning across:

• 3 models, 2 families: claude-opus-4-8 (×4), claude-opus-4-7 (×3), claude-sonnet-4-6 (×2)
• 4 cc_version variants: 2.1.160.e42, 2.1.160.f36, 2.1.161.3c5, 2.1.161.b88
• 2 client builds: 2.1.160 AND 2.1.161 (extension auto-updated mid-window; stall persists)

⇒ points to account/region-level streaming-path degradation or throttling, not a single feature experiment or model.

Summary

Since ~2026-06-01 00:00 UTC, the Claude Code VS Code extension intermittently appears to hang: spinner spins, token counter frozen, near-zero burn. Forensic capture shows the request reaches the API and the model BEGINS streaming (normal ~2.2s first byte), then the SSE stream PAUSES mid-generation for 40s up to ~600s before resuming. The turn eventually completes. This is server-side: a mid-stream token-emission pause cannot be client-caused. Recovery latency is escalating over time.

Environment

• Claude Code VS Code extension; Windows 11; VS Code 1.122.1; Plan: Max.
• At onset the extension was 2.1.136, stable ~3 weeks. Nothing local changed at onset (no Windows/VS Code/extension update; reboot + extension updates all came afterward, as remediation).
• Max path dispatches first-party directly to api.anthropic.com.

Signature

• [API REQUEST] /v1/messages dispatched; OAuth fine.
• "Stream started - received first chunk", first byte ~2.2s (normal).
• Then NO further stream output for 40–600s mid-generation, no error.
• Stream resumes; turn completes. A single turn can stall more than once.

Captured evidence — 9 stalls, 2026-06-03 (UTC+10)

| time | request id | model | cc_version | stall | recovered after |
|------|-----------|-------|-----------|-------|-----------------|
| 09:22:07 | 1dd680fe… | opus-4-8 | 2.1.160.e42 | 42s | 70.1s |
| 09:36:05 | c76cb0ee… | opus-4-7 | 2.1.160.e42 | 40s | 68.7s |
| 09:37:48 | c76cb0ee (2nd stall, same turn) | opus-4-7 | 2.1.160.e42 | 42s | 46.9s |
| 09:41:33 | abaf8f10… | opus-4-8 | 2.1.160.e42 | 40s | recovered |
| 09:46:09 | 6263f825… | opus-4-8 | 2.1.160.e42 | 40s | recovered |
| 09:48:44 | 6263f825 (2nd stall, same turn) | opus-4-8 | 2.1.160.e42 | 42s | recovered |
| (am) | 2dd0d483… | opus-4-7 | 2.1.160.f36 | 40s | recovered |
| 10:59:02 | d3da8b44… | sonnet-4-6 | 2.1.161.b88 | 41s | 87.1s |
| 11:01:36 | 26016ea1… | sonnet-4-6 | 2.1.161.3c5 | 41s | 602.7s (~10 min) |

Recovery: n=9, min 46.9s, max 602.7s; 0 terminal (all eventually resumed). Recovery time is escalating through the day — the earliest captures resolved in ~47–70s, while the two most recent (late morning) took 87s and 603s.

Ruled out (client-side)

No ANTHROPIC_BASE_URL/proxy/auth override (api.anthropic.com ~70ms RTT); MCP servers removed — no effect; hooks complete in ~0.02s; no pending tool-permission gate; claude -p reproduces; persists across two client builds (2.1.160 and 2.1.161).

Impact

40s–10min of apparent dead-hang per stall, often multiple times per turn, across all models. Users reflexively restart and abandon turns that would have completed. Worsening over the course of the day.

Request

1. Is there an account/region-level streaming degradation, throttle, or backpressure affecting this account since ~2026-06-01 00:00 UTC? The pauses span all models (Opus 4.7/4.8, Sonnet 4.6) and multiple client builds — superseding the original single-cohort (.e42) hypothesis.
2. Why does the server pause mid-stream token emission for up to ~10 min with no error, rather than failing fast or completing?
3. Please check rollouts / capacity / routing events in the 2026-06-01 00:00 UTC window.

Capture method

Forensic watcher tailing the extension debug log, flagging any in-flight request with no stream output >40s and pairing each with its recovery. Raw JSON records available on request.

What Should Happen?

The turn should not hang and the task should complete