[BUG] 2.1.183: pre-first-byte streaming aborts on custom ANTHROPIC_BASE_URL (proxy/gateway), large-context — regression from 2.1.179 (2.1.181 unaffected on the gateway)

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

On a custom ANTHROPIC_BASE_URL (a corporate LiteLLM proxy fronting Bedrock / the Anthropic API), large-context turns (≈150k–500k input tokens) intermittently fail before the first response byte starting with 2.1.181 (and 2.1.182 / 2.1.183). Users see an "API error / no response from API" pause and the client retries.

At the load balancer in front of the proxy, these failures show up as HTTP 460 (client closed the connection before the target responded; target_processing_time = -1) — i.e. the client is aborting before the first byte arrives, not the server erroring.

We isolated this fairly carefully and believe it is client-side:

• Backend is healthy. Independent streaming probes through the same proxy return the first SSE byte in 13–20 s even cache-cold at ~360k tokens; the upstream provider reports full rate-limit headroom (no throttling). So the gateway is delivering first byte well within any reasonable timeout.
• The aborts are concentrated on the largest-context users and only on clients pointed at a custom ANTHROPIC_BASE_URL — direct-API clients in the same org are unaffected.
• This started exactly when clients auto-updated into the 2.1.181→2.1.183 range (latest advanced to 2.1.183 on 2026-06-19, matching onset).

The 2.1.181 changelog includes: "Fixed prompt caching not reading on custom ANTHROPIC_BASE_URL … due to a per-request attestation token changing every turn." That code path only affects custom-base-URL clients, which matches exactly who is and isn't impacted here — so it seems like a strong candidate for where the regression was introduced.

What Should Happen?

The client should wait for the first byte up to its configured request/idle timeout and not abort large-context streaming requests prematurely on a custom ANTHROPIC_BASE_URL.

Error Messages/Logs

# client side: "API error" / "No response from API" pause + retry
# load balancer (in front of the proxy): HTTP 460, request_processing_time≈0.001, target_processing_time=-1
#   -> client closed the connection before the proxy sent any response byte

Steps to Reproduce

1. Point Claude Code at a custom ANTHROPIC_BASE_URL (e.g. a LiteLLM proxy) on 2.1.181–2.1.183.
2. Drive a session with a large accumulated context (~150k–500k input tokens), streaming.
3. Observe intermittent pre-first-byte aborts on the heavy turns (visible as HTTP 460 at the LB) that do not occur on 2.1.179.

Claude Model

Sonnet 4.6 and Opus 4.8 (via the proxy)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.179

Claude Code Version

2.1.181, 2.1.182, 2.1.183

Platform

Custom ANTHROPIC_BASE_URL (LiteLLM proxy → Bedrock / Anthropic API)

Operating System

Linux / WSL2

Additional Information

• Almost certainly the same regression as #69358 ("No Response From API 2.1.181, 2.1.183", last working 2.1.179) and #69660 (intermittent "No response from API", 2.1.183, started mid-session 2026-06-19). Filing separately because this report isolates the custom-ANTHROPIC_BASE_URL / proxy manifestation and ties it to the 2.1.181 attestation-token / prompt-cache change. Possibly related: #66095 and #64533 (slow / multi-minute first-byte).
• Workaround that fixes it for us: pin to 2.1.179 (npm install -g @anthropic-ai/claude-code@2.1.179, or native installer ... | bash -s 2.1.179) and set DISABLE_AUTOUPDATER=1 so the background updater doesn't re-bump past it.
• Happy to provide anonymized LB/timing captures if useful.