Auto-compact fires at 150k on claude-opus-5[1m]; /context reports "Auto-compact window: 150k tokens" while another session on the same model id shows the full 1M

Summary

On a 1M-context model (claude-opus-5[1m]), some sessions run with a 150k auto-compact window instead of the model's 1M window. In those sessions /context itself says so — it prints Auto-compact window: 150k tokens directly under the claude-opus-5[1m] label — so the session is auto-compacted roughly 6× earlier than the advertised context window allows.

The decisive part: on the same machine and same CLI build, another session on the same model id reports the full 1M window. So this is not "the 1M variant never gets 1M" — it is per-session, and the two states are distinguishable in /context output.

Environment

• Claude Code 2.1.226 (confirmed latest via claude update — reproduces after updating)
• macOS (darwin 25.6.0), bash
• Multiple long-running sessions in parallel, same machine, same CLI build

Evidence

All rows below are transcribed from /context output actually read on screen, or from timestamped session events. Nothing here is inferred.

1. Affected session — 1M model, 150k window

Model label shown: claude-opus-5[1m]

108.3k/150k tokens (72%)
...
Autocompact buffer: 33k
Auto-compact window: 150k tokens

2. Control, same model id, same machine — full 1M window

Model label shown: claude-opus-5[1m] (identical to row 1)

340.5k/1m tokens (34%)

System prompt:   5.5k   (0.5%)
System tools:    14k    (1.4%)
Memory files:    16.7k  (1.7%)
Skills:          8.5k   (0.8%)
Messages:        295.9k (29.6%)
Compact buffer:  3k     (0.3%)
Free space:      656.5k (65.6%)

MCP tools · 415 tools · 0 tokens (loaded on demand)

Two differences worth noting between rows 1 and 2, since they look like the same setting rendered from different sources:

| | Affected (row 1) | Control (row 2) |
|---|---|---|
| denominator | 150k | 1m |
| buffer line | Autocompact buffer: 33k | Compact buffer: 3k |
| explicit window line | Auto-compact window: 150k tokens | absent |

3. Control, different model, same machine — full window

A session on Fable 5 on the same machine:

261.2k/1M
Free space: 693.7k (69.4%)

4. Event record — repeated premature compaction

One affected session was auto-compacted twice within one day (~09:4x, then again at ~12:0x when it hit the edge of its budget). Another affected session was auto-compacted shortly after a manual /clear, with almost no conversation accumulated.

Steps to reproduce

We can reproduce the state but have not isolated what puts a session into it:

1. Start several Claude Code sessions on the 1M-context Opus 5 variant on one machine.
2. Let them run long (heavy tool use, a few hundred k tokens of messages).
3. Run /context in each and compare the denominator and the buffer lines.
4. Some sessions report x/150k with Auto-compact window: 150k tokens; those auto-compact at ~150k. Others on the same model id report x/1m and do not.

What we ruled out: /clear is not the differentiator — one affected session was compacted right after a /clear, and the unaffected control session in row 2 was itself started by /clear that same day.

Still unknown: whether the affected sessions were resumed vs freshly started, how many times they had been compacted before, and the path taken to reach the 1M variant (started there vs switched into it). We're happy to collect these if it would help narrow it down.

Expected vs actual

• Expected: the auto-compact window is derived from the active model's context window, so a claude-opus-5[1m] session gets a ~1M window.
• Actual: some claude-opus-5[1m] sessions get a 150k window. /context reports the smaller window, so the value appears to come from a session-level source that can desync from the active model.

Why it matters

Compaction is lossy. Firing it ~6× earlier than the window allows costs real work — long agentic sessions lose mid-task state and re-derive it, and a /clear immediately followed by an auto-compact means the session starts already degraded. Because /context reports the reduced number as if it were normal, there is no signal that anything is wrong until compaction happens.

What would help

• Confirmation of where the auto-compact window is read from, and whether it can desync from the active model within a session.
• If a 150k window is expected under some condition (a plan tier, an overage/fallback mode, a resumed session carrying an older model's window), surfacing why in /context — rather than just showing a smaller denominator — would make this self-diagnosing instead of a multi-day investigation.

Secondary observation (lower confidence, separate from the above)

In one session, output injected into the transcript arrived several messages later than expected rather than at the point of injection. We are reporting this only as an observation — we do not have a reliable reproduction, and it may simply be message ordering rather than a defect. Please treat it as unverified; we did not want to report it as "output lost", which it is not.