Context window collapses from 1M to 200k after a compaction (Opus 4.8 [1m], Max plan, Windows, v2.1.215)

This is a known compaction regression - the 1M context window reverts to the 200k effective limit after the first compaction event and stays there for the rest of the session.

A few things worth confirming from your transcript data, since you already have the measurements:

1. Check whether CLAUDE_CODE_AUTO_COMPACT_WINDOW appears in the session environment at any point. There is an open report (#77312) where a prior Claude Code version was writing this env var as a session-local side effect and not clearing it on compact, so subsequent turns would pick up the old (smaller) value.

1. Check the context_window field in the session JSONL directly. On sessions hitting this bug, the field sometimes drops from 1048576 to 204800 after the compact event, which confirms it is the window config being mutated rather than just the display being wrong.

1. The flag autoCompactEnabled: false you mentioned is for the auto-compact trigger behavior, but it does not prevent the window size from being reconfigured by the compaction internals. So that setting does not protect against this.

The data you have (measured peak before compact vs. measured peak after, same session) is exactly what Anthropic needs to reproduce this. Worth adding the raw before/after context numbers directly to this issue if you have them handy from the JSONL.

This is a meaningful regression for anyone running long orchestration sessions on Max - losing 80% of effective context mid-session without a reliable way to restore it forces a full session restart, which is expensive when you have warmed prompt cache.

Follow-up with the requested checks, run against the raw session .jsonl files (Max plan, claude-opus-4-8[1m], Claude Code v2.1.215, Windows; autoCompactEnabled: false, no ANTHROPIC_BASE_URL).

1. CLAUDE_CODE_AUTO_COMPACT_WINDOW in the session environment

Not set. env in the live session returns nothing for it, and every textual occurrence in the transcript is prose (my own notes / pasted docs) referencing the variable name, not an actual assignment. So the side-effect described in #77312 (the env var being written session-locally and not cleared on compact) does not appear to be the trigger here — the variable is genuinely absent.

2. context_window field in the JSONL (1048576 → 204800)

I could not confirm this from disk: this build (2.1.215) does not persist a context_window field in the session .jsonl. The only occurrences of 1048576 / 204800 in the logs come from quoted text, not a JSON field. So on this version the window size isn't recorded on disk — only the per-turn token usage is. If newer builds do write that field, it would be a cleaner confirmation; here the evidence is the indirect measurement below.

Raw before/after numbers (measured, same session)

Live context per assistant turn = input_tokens + cache_read_input_tokens + cache_creation_input_tokens.

2026-07-18 (session A) — two automatic compactions:

• Peak live context before the 1st compaction: 521,392
• 1st compaction fired, context reset low, then climbed to a max of 177,603
• 2nd automatic compaction fired at 164,685 — a 1M window would not auto-compact at ~165k, which is the core signal.

2026-07-19 (session B) — one manual /compact:

• Peak live context before the compaction: 442,418
• After the compaction, context never again exceeded 141,594; /context then reported Auto-compact window: 200k tokens while the header still read Opus 4.8 (1M context).

Both sessions demonstrably held 400k+ before the compaction (impossible under a 200k window) and were limited to ~200k afterward. For contrast, non-compacted sessions on the same setup routinely hold 600k–800k, so the 1M window itself works — it is the compaction that collapses it.

_WORKAROUND:_ Apparently all you have to do is turn on /usage-credits then the (1M) context loads.

Prompt is too long — the same 1M → 200k collapse, but with ZERO compactions

What a user actually sees is the message Prompt is too long, and then the session is stuck. That is the
headline symptom, and it is worth stating plainly because nothing else on screen explains it: no warning, no
error dialog, no mention of a limit changing. The conversation simply stops accepting input.

Same reporter, same machine, same account as the original report. I am adding it here rather than opening a
new issue because the symptom and the workaround are identical to this one — but the trigger is not what we
both assumed, and that matters for whatever fix is planned.

Anthropic's confirmation on this issue was "1M reverts to 200k after the first compaction". This session
never compacted once, and the window still collapsed to 200k.

The measurement

Session log bda21019-4d96-4765-b38a-3eec57f909bf.jsonl (6.0 MB, 811 assistant turns carrying usage).
Live context computed exactly as asked previously:

input_tokens + cache_read_input_tokens + cache_creation_input_tokens

| | |
|---|---:|
| Compactions in this session | 0 — no isCompactSummary entry, no /compact command |
| Peak live context | 711,676 tokens @ 2026-08-04T06:04:44Z |
| ...as a share of 1M | 67.9% |
| ...as a share of 200k | 347.5% |
| Live context at the final turn | 689,046 @ 2026-08-04T07:47:18Z |

So for the whole session the 1M window was working correctly — a 200k window cannot accept a 689,046-token
request, and the client accepted hundreds of them.

Then, with no compaction anywhere in the session, the reported context limit became 200k. Because the
conversation already held ~689k, every further turn was impossible. Restarting into a fresh session restored
the full 1M window, which is the same workaround as before.

How it surfaced — and why it is easy to miss

All the work was on the desktop client (Windows). It did not print an error. It simply began reporting a
200k limit, and from that point the session could not accept another turn, because it already held ~689k.

The failure only became legible as text when the same session was viewed in the mobile app, which
rendered it as:

Prompt is too long

That is the whole user-facing signal. No warning that the window changed, no indication that anything had
been reduced — just a session that will not take input any more, and a three-word message if you happen to
open it on a phone. From a user's point of view the session is simply dead, with no way to tell why.

Screenshot available if useful. I am not attaching the .jsonl: session logs contain file contents and
command output, so the summary figures above are what I can share safely. Happy to extract any specific
field on request.

Two neighbouring sessions, same machine and account, same two days

Both also ran far past 200k with zero compactions, so the 1M entitlement itself is clearly healthy here:

| session | compactions | peak live context |
|---|---:|---:|
| a2cccaaf-4de4-4882-a75d-cd16f3b139e4 | 0 | 661,315 |
| 15974ee3-c477-4a4c-9942-56a5fda624d4 | 0 | 382,168 |

Why I think this is worth a second look

The working theory on this issue — including the pointer to #77312 — is that something at compaction time
mutates the window. This session gives a counter-example: no compaction, same collapse.

If the planned fix only clears state on compaction, this case will survive it.

Two things that might help narrow it, if useful:

• Is there any other code path (not compaction) that writes a session-local context-window value?
• Is the limit re-read per request, or cached for the session after some first event?

Happy to run any diagnostic on this machine — it reproduces often enough here to be worth catching properly.
If you would rather track the no-compaction trigger as its own issue, say so and I will open one and
cross-link it; I kept it here because the symptom and the workaround are identical to this report.

Environment

• Windows 11 Pro 10.0.22000
• Opus 5, 1M context, Max plan
• Reproduces intermittently; this is the first time I have captured the session log AND the on-screen failure

together.