Auto-compaction fails and ends the session on third-party models after the new unknown-model window enforcement

What happened

After Claude Code auto-updated to a recent 2.1.2xx build, long sessions using a third-party (OpenAI/Anthropic-compatible) endpoint started terminating with:

⚠️ Auto-compaction could not recover this turn.

The same setups ran for weeks without a single failure before the update. We ship a tool that configures Claude Code against third-party endpoints for a few thousand users, and reports of "the session just dies after a while" all appeared within the same ~48h window — consistent with staggered auto-update rather than anything on our side.

What changed (evidence)

Comparing two Claude Code binaries on the same machine:

| string | 2.1.205 | 2.1.225 |
|---|---|---|
| CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT | 0 | 8 |
| is not a model this version of Claude Code recognizes | 0 | 2 |

So "unknown model window enforcement" is new. 2.1.223 already has it. The in-binary message confirms the intent:

"<model>" is not a model this version of Claude Code recognizes, so auto-compact will keep this session within 200000 tokens (the context window it assumes). … CLAUDE_CODE_DISABLE_UNKNOWN_MODEL_WINDOW_ENFORCEMENT=1 restores the previous wait-for-the-API behavior.

Important: this is not "the assumed window is too large"

Our first hypothesis was that the assumed 200k exceeded the model's real window, so the compaction request itself overflowed. We measured it, and that's not the case. A single request to the model with a deliberately oversized prompt:

"usage": { "prompt_tokens": 215084, "completion_tokens": 1, "total_tokens": 215085 }

HTTP 200. The real window is ≥215k — larger than the 200k Claude Code assumes. So compaction is not being pushed past the model's limit.

Our reading: before enforcement, compaction essentially never triggered for these users (Claude Code waited for the API, and the API never objected). Enforcement now does trigger it — and the compaction path itself fails on this model. The bug was always there; enforcement is what finally exercises it.

Possible cause (not proven)

The model in question returns an empty content with reasoning_content populated and finish_reason: "length" whenever the output budget is tight — observed directly in both probes above. If compaction requests a summary under a constrained output budget, an empty summary would plausibly produce "could not recover". We have not confirmed this is the actual mechanism.

What would help

1. Don't end the session when auto-compaction fails. Losing the whole conversation is a much worse outcome than not compacting. A fallback (retry with a larger output budget, or degrade to truncation) would turn a fatal error into a recoverable one.
2. Surface the real reason. The current message is indistinguishable from a network/quota problem to end users; ours reported it as "the AI just quits".
3. Consider making the enforcement opt-in, or defaulting unknown models to the previous wait-for-the-API behavior, until compaction is verified to work against non-first-party endpoints.

Environment

• Claude Code 2.1.223 (macOS 15.6.1, arm64) and 2.1.225 / 2.1.226 (Windows 11)
• Third-party Anthropic-compatible endpoint, non-claude-* model name
• Reproduces on long-running sessions and scheduled/headless runs (claude -p)