[BUG] A 1,000,000-token window resolves to source "auto" on non-first-party providers, leaving the context cap unenforced

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?

Two window sources can produce an enforced cap. On a non-first-party provider with a 1M-window model, both are unavailable, so the window resolves with source auto — which makes the cap advisory and disables the pre-flight blocking check entirely.

1. The client-data source is gated on provider identity. It returns null unless the provider is first-party, before even consulting its cache. And the non-first-party bootstrap path never supplies the auto-compact-window data in the first place, so the cache is empty regardless.
2. The model-default fallback is guarded by window < 1e6. A window of exactly 1,000,000 is excluded from it.

Nothing else supplies a value, so the session runs with no enforced ceiling. The compaction trigger still fires at its threshold, but it's only evaluated at turn boundaries — and a single large tool result can add hundreds of thousands of tokens. With no pre-flight block, one such turn walks the session past the trigger and into the provider's real ceiling.

That state is unrecoverable in place: past the limit, only a precomputed summary can be applied (it's a local message-list swap needing no request), and none exists — because the precompute is started by the same trigger that never fired. The cold summarization fallback re-sends the over-limit history and fails identically, so /compact cannot recover either. Only /rewind or /clear works.

The contrast that isolates it

Same client, same machine, same model family — only the window differs:

| window | source | compact trigger | pre-flight block |
|---|---|---|---|
| 200,000 | model-default | 170,000 | 197,000 — enforced |
| 1,000,000 | auto | ~85% of window | none |

At 200,000 the session physically cannot exceed the ceiling. At exactly 1,000,000 there is no floor under it at all.

This is why the failure looks provider-specific: first-party never shows it, because the client-data source supplies an enforced window. A non-first-party provider on a 200K model never shows it, because model-default catches it. Only non-first-party and a 1M window hits it — and that combination is normal for anyone running a gateway or a cloud provider with a 1M model.

What Should Happen?

The model-default fallback should include a window of exactly 1e6 — the guard reads as an off-by-one in intent, since every window below 1M gets an enforced default and only 1M itself gets none. Alternatively, don't make cap enforcement contingent on provider identity at all: the client knows the window, so it can enforce it regardless of who serves the model.

Either way, no configuration should end up with a known window and no enforcement of it.

Error Messages/Logs

Steps to Reproduce

1. Point the client at any non-first-party provider (an LLM gateway, or a cloud provider directly).
2. Select a model whose window resolves to exactly 1,000,000 — e.g. an Opus [1m] variant.
3. Run /context. The window reads 1,000,000 and looks correct.
4. Grow the context past the compaction threshold in a single large turn (a big file read or tool output).
5. Observe: no pre-flight block, and the session continues past the threshold to the provider's real ceiling, where it strands. /compact does not recover it.

Contrast: repeat with a 200K model on the same setup. The trigger fires at 170,000 and requests are refused locally at 197,000 — the ceiling cannot be crossed.

Workaround, which also demonstrates the cause: setting CLAUDE_CODE_AUTO_COMPACT_WINDOW to any explicit value makes the source non-auto and re-arms the pre-flight block. Because the window resolves as min(modelWindow, configured), a value like 900000 targets only the 1M models and leaves smaller windows untouched.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.231 (Claude Code)

Platform

AWS Bedrock

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

A related diagnosability gap: the client already knows this state is unsafe. There is an internal notice explaining that the window is unenforced and naming CLAUDE_CODE_AUTO_COMPACT_WINDOW as the remedy, plus telemetry distinguishing "window source auto" from "window above boundary". Surfacing that notice at session start when the source resolves to auto would let users self-diagnose instead of discovering it as an unrecoverable session.