[BUG] Auto-compact triggers consistently at ~367K tokens on Opus 4.7 [1m] in Claude Code 2.1.119 (regression of #52519?)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code 2.1.119 auto-compacts Opus 4.7 [1m] sessions at a hard threshold of **~367K tokens**, despite the model being configured with the 1M context window.

Per the v2.1.117 changelog, the threshold computation against a 200K window for Opus 4.7 was supposed to be fixed — but on a MAX plan with `"model": "opus[1m]"`, compaction now consistently fires around 36.7% of the advertised 1M window.

This is not a single-incident hiccup. In one working day (2026-04-27), auto-compact fired **4 times** at near-identical thresholds:

| Time (UTC) | Peak tokens before compact | After compact |
|------------|---------------------------:|--------------:|
| 15:41:55   | 366,432                    | 92,518        |
| 16:52:52   | 366,989                    | 102,144       |
| 17:53:47   | 360,677                    | 97,646        |
| 18:40:47   | 366,790                    | 105,886       |

Tokens = `input_tokens + cache_read_input_tokens + cache_creation_input_tokens`, extracted directly from the session JSONL in `~/.claude/projects/.../<session>.jsonl`. Cache reads exceed 200K (max observed: 359,497), which confirms the request is being routed to the 1M variant on the backend — but the local auto-compact threshold appears to be calculated against a different (smaller) window.

Distribution of token usage during the session (50k buckets):

50000- 99999 : 37
100000-149999 : 70
150000-199999 : 225
200000-249999 : 257
250000-299999 : 302
300000-349999 : 215
350000-399999 : 88 <- session never exceeds ~367K

The session never exceeded 367K. This is a hard ceiling, not a natural conversation end.

Related issues that suggest this bug class has recurred multiple times:
- #52519 — 2.1.117 fix for Opus 4.7 inflated `/context` percentages and early auto-compact
- #42375 — Auto-compaction at ~6% on Opus 4.6 (1M)
- #34158 — Context limit reached at ~200K despite 1M model
- #34363 — Autocompact buffer larger than 200K window
- #46372 — MAX stuck at 200K after model switch / cancelled compaction

What Should Happen?

With `"model": "opus[1m]"` (resolves to `claude-opus-4-7[1m]`) on a MAX plan, auto-compaction should trigger near the 1M boundary — i.e. ~835K tokens (83.5% of 1M), as documented for the 1M context window.

Specifically:
- The local auto-compact threshold should match the same window that is used for routing (the request is clearly routed as 1M because cache_read goes above 200K).
- A user with `"model": "opus[1m]"` should be able to use roughly 800K+ tokens before triggering auto-compaction.
- `effectiveWindow` reported internally should equal 1,000,000 for this configuration.

Error Messages/Logs

No explicit error message is shown — auto-compact just fires silently. There are no `autocompact:` log lines in `~/.claude/debug/` (directory exists but is empty), and no log lines in `~/.claude/telemetry/` mentioning `effectiveWindow` or `threshold`.

The only evidence is reconstructed from the session JSONL by extracting `message.usage` and detecting large drops in total token count (input + cache_read + cache_creation):


=== COMPACT EVENTS (drops > 50k tokens) ===
COMPACT: 366432 -> 92518   at 2026-04-27T15:41:55.346Z
COMPACT: 366989 -> 102144  at 2026-04-27T16:52:52.466Z
COMPACT: 360677 -> 97646   at 2026-04-27T17:53:47.153Z
COMPACT: 366790 -> 105886  at 2026-04-27T18:40:47.823Z


Suggestion: please log `effectiveWindow` and `threshold` somewhere user-accessible so users can self-diagnose this class of issue.

Steps to Reproduce

1. On macOS, install Claude Code 2.1.119 with a MAX plan (subscriptionType `"max"`).
2. In `~/.claude/settings.json` set:
   ```json
   {
     "model": "opus[1m]"
   }
   ```
3. Start a new session: `claude`
4. Run `/context` — confirm the denominator reads `1000k`.
5. Use the session normally — file reads via `Read`, subagents via `Task`, MCP calls (e.g. `memory`), etc. Allow the conversation to grow.
6. Watch the total token usage (input + cache_read + cache_creation) climb past 350K.
7. Observe that auto-compact fires consistently around **360–367K tokens**, well below the expected ~835K threshold for a 1M window.

To verify post-hoc, extract token timeline from the session JSONL:

```bash
SESSION=~/.claude/projects/-Users-<you>/<session-uuid>.jsonl

jq -r 'select(.message.usage) | "\(.timestamp)|\((.message.usage.input_tokens // 0) + (.message.usage.cache_read_input_tokens // 0) + (.message.usage.cache_creation_input_tokens // 0))"' "$SESSION" \
  | awk -F'|' 'NR>1 && prev > $2 + 50000 {print "COMPACT: " prev " -> " $2 " at " $1} {prev=$2}'

Expected: zero compact events until ~835K. Actual: multiple compact events at ~367K.

### Claude Model

Opus

### Is this a regression?

I don't know

### Last Working Version

Unknown — I noticed the issue today on 2.1.119. I do not have data points from earlier 2.1.x versions to confirm exactly when it started.

### Claude Code Version

2.1.119

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

```markdown
**Environment variables (none of these are set):**
- `CLAUDE_CODE_AUTO_COMPACT_WINDOW` — not set
- `DISABLE_AUTO_COMPACT` — not set
- `CLAUDE_AUTOCOMPACT_PCT_OVERRIDE` — not set
- `CLAUDE_CODE_BLOCKING_LIMIT_OVERRIDE` — not set
- `CLAUDE_CODE_DISABLE_1M_CONTEXT` — not set

**Relevant `~/.claude/settings.json` excerpt:**
```json
{
  "model": "opus[1m]",
  "effortLevel": "high",
  "remoteControlAtStartup": true,
  "permissions": {
    "additionalDirectories": [
      "/etc", "/usr/local", "/opt", "/Library", "/Applications", "/private/etc"
    ]
  },
  "hooks": {
    "PreToolUse": [
      // 8 PreToolUse hooks (Edit/Write protect, Bash secrets check, conventional commits, etc.)
    ]
  },
  "mcpServers": {
    "memory": { "autoApprove": true },
    "firebase": { "command": "npx", "args": ["-y", "firebase-tools@latest", "mcp", "--dir", "..."] }
  }
}

Possible root cause hypothesis:
The 1M-context detection works for the request routing path (cache_read goes above 200K, confirming 1M variant on the backend), but the auto-compact threshold is computed via a different code path that uses a stale or smaller window value. 367K corresponds to roughly 83.5% of an effective window of ~440K, suggesting some intermediate value rather than 200K or 1M.