1M-context session becomes unrecoverable: ECONNRESET on large uncached requests, and /compact fails with the same error

You've landed on the exact catch-22: the session is too big to compact via the API, but compaction requires sending the full context — so the one tool that should rescue you is itself what's failing.

The difference with cozempic (github.com/Ruya-AI/cozempic) is that it operates on the JSONL file on disk, not through an API request. The prune itself requires no network call — it reads the local file, strips the categories that make sessions balloon (accumulated tool outputs, redundant system-prompt injections, stale progress ticks, duplicate content from prior compaction cycles), writes a trimmed version, and that's it. Your ~520k token session should come down substantially — probably into the 150–250k range depending on what's in there, though the exact number depends on your session composition.

Workflow (with Claude stopped):

pip install cozempic
cozempic current --diagnose          # see the breakdown
cozempic treat current               # dry-run first
cozempic treat current --execute     # apply

What this doesn't fix: the cache TTL issue you described is real and Anthropic needs to address it. A pruned session will still go fully uncached after 5 minutes of inactivity, and the next request still has to re-ingest — it just has to re-ingest 150k tokens instead of 520k, which is a qualitatively different ask from the API and much less likely to hit the ECONNRESET threshold. The suggestion in your issue to warm the cache or warn on expiry is the right systemic fix; the pruning just gets you out of the hole this time.

Your suggestion to make /compact resilient for huge sessions (chunked/incremental) is worth following separately — that's a CC architectural issue that cozempic can't fix.

If you're still stuck mid-session and need to recover, I'd be interested to hear whether the file-side approach actually gets you unstuck.

Filed #79989 with new data that sharpens this: across five affected sessions in one night (232k / 261k / 328k / ~905k / ~905k tokens) plus your ~520k, every failure is >200k tokens and nothing ≤200k ever fails — the threshold looks like the standard/long-context boundary itself, hit on the first fully-uncached ingestion after prompt-cache expiry (which is why it strikes after idle periods). Also validated a recovery workaround 5×: generate the summary offline from the JSONL on disk, then mint a new session file containing only a synthetic isCompactSummary entry — resumes at ~7k tokens on the first attempt. Details + isolation experiments (incl. why transcript surgery and appended-boundary tricks don't work) in #79989.

Hi @Rterrell25, I came across this while looking into recovery from long AI sessions. When that 1M context session became unrecoverable and you had to abandon it, what did you actually have to reconstruct by hand in the new session? Did the repo and files give you most of the state back, or were important decisions and intent only present in the conversation? Roughly how long did recovery take?