[BUG] Every session >200k tokens (1M-context beta) becomes permanently unrecoverable once prompt cache goes cold: ECONNRESET on all requests incl. /compact — threshold data + isolation experiments + validated workaround

Preflight Checklist

• [x] I searched existing issues — this extends #74544 and #74758 with new threshold data, controlled isolation experiments, and a validated recovery workaround
• [x] Single bug report
• [x] Reproduced on the latest version (2.1.217)

Summary

Any session whose live context exceeds the 200k standard-context line (i.e. any session actually using the 1M-context beta) becomes permanently unrecoverable once its prompt cache goes cold: every request fails with API Error: Unable to connect to API (ECONNRESET) in an endless retry loop, and /compact fails with the identical error because compaction itself sends the same >200k-token request. We hit this on five sessions in one night (contexts 232k / 261k / 328k / ~905k / ~905k tokens), while every session ≤200k on the same machine, network, and account kept working flawlessly.

The failure threshold appears to be exactly the standard/long-context boundary, not an absolute size: across our five failures plus #74544's report (~520k), every observed failure is >200k and we have never observed a failure ≤200k. This suggests the reset happens on the long-context serving path specifically, when a large uncached request is re-ingested.

Environment

• Claude Code CLI 2.1.212–2.1.217 (failing sessions spanned several versions; a fresh 2.1.217 process resuming an affected session still fails → not client-version-specific)
• macOS (Darwin 25.3.0), Node-free install (native binary)
• Models: claude-opus-4-8[1m] and claude-fable-5[1m]
• No proxy, no ANTHROPIC_BASE_URL, no VPN on the API path (Tailscale present but no exit node)
• status.claude.com: incidents that day all marked resolved; failures persisted for 14+ hours regardless

Timeline / evidence

• All long-context sessions died in the same overnight window (first synthetic error entry 2026-07-21T08:27Z) after sitting idle past prompt-cache expiry — i.e. the first fully uncached re-ingestion of the large context is what fails. Transcript usage entries immediately before death show e.g. cache_read_input_tokens: 904751 on the last successful request.
• One session recovered to a ~13k context then regrew to ~232k within 2.5 hours and re-entered the failure state — errors began intermittently right as it crossed ~200k and became a permanent retry loop shortly after. Same night, same machine, sessions at ≤193k never errored once.
• Failures are consistent for a given session: 100% of attempts, interactive and -p, across many hours.

Ruled out

• Network: curl to api.anthropic.com/v1/messages answers in ~70ms and a 1.3MB upload completes cleanly during the failure window; fresh claude -p "ok" sessions work in the same directory at the same time.
• User/environment: affected sessions existed under two different OS users; both users' fresh sessions worked; both users' >200k sessions failed. No proxy env vars anywhere (verified via ps eww on the running processes).
• Client version: stuck sessions originally ran 2.1.212–215; killing them and resuming with 2.1.217 reproduced the failure immediately.

Isolation experiments (each on a copy; originals untouched)

1. Payload-reduction surgery is insufficient for text-heavy sessions: stripping oversized tool_results from a ~905k-token session removed only ~0.9MB of a 4.5MB live tail (1.8MB of it is assistant thinking blocks, which are signature-protected and can't be touched). Confirms #74758's byte findings don't generalize — token count over 200k alone reproduces it with zero images.
2. Appending a synthetic isCompactSummary entry to a full copy of the transcript does NOT fix resume — the replayed request still fails, i.e. resume does not (reliably) stop context reconstruction at the most recent compact-summary boundary when that boundary was written externally.
3. A session file containing ONLY the synthetic compact-summary entry resumes perfectly on the first attempt — and the model demonstrably has the summary in context (it answers content questions about it). Validated 5× across different sessions.

Impact

This has made Claude Code almost completely unusable for us for more than a day now — every established working session constantly fails to connect, on a plan costing hundreds of dollars a month. Since long-lived sessions are the whole point of paying for large-context tiers, the practical effect is a full outage of exactly the workflows that tier is sold for.

This is the worst failure mode a long-running session can have: the documented remedy (/compact) requires the exact request that is failing, retries re-pay the full uncached ingestion each attempt (minutes per cycle), and the user-visible behavior (Retrying… attempt N/10 forever) gives no hint that the session is unrecoverable or why. Users with 1M-beta sessions will hit this every time such a session idles past cache expiry.

Workaround (validated 5×, sharing for other affected users)

Offline compaction: (1) generate a summary of the dead session by reading its JSONL transcript from disk (no API call carries the big context); (2) write a new session file containing a single synthetic isCompactSummary user entry (same shape Claude Code writes after a real /compact: type:"user", isCompactSummary:true, isVisibleInTranscriptOnly:true, string content, fresh sessionId on the line); (3) claude --resume <new-id> — first request is ~7k tokens and succeeds. The original transcript is kept as an archive.

Suggested fixes

1. Edge/serving: fix whatever resets large uncached >200k-token ingestions (this also afflicts the raw API per #74544, so it may not be CLI-side at all — but the CLI can still mitigate).
2. /compact resilience: chunked/incremental summarization so compaction of an oversized session never depends on a single full-context request — that removes the catch-22 even if the transport issue recurs.
3. Retry UX: after N transport-level failures on a >200k request, surface an actionable message (e.g. "requests this large are currently failing; consider /compact from a smaller checkpoint") instead of an infinite generic retry loop.
4. Consider honoring an externally-appended isCompactSummary boundary on resume (experiment 2) — that would make disk-level recovery trivial without the summary-only-file trick.

Related issues

• #74544 (same catch-22, ~520k tokens, cold-cache correlation) — this report adds the 200k-boundary threshold data and controlled isolation experiments
• #74758 (payload-bytes trigger via base64 images at small token counts) — complementary: bytes and >200k tokens both reproduce it
• #74732, #75956 (likely same underlying issue)