The model supports 1M context, but why does the tool only trigger context compression at 128K

[hardy922]

Description

The model supports 1M context, but why does the tool only trigger context compression at 128K

，Can it be set to support 1M context instead of frequently triggering compression

• OS: window
• codewhale version: v0.9.3
• Install method:
• codewhale doctor summary:
• Model/provider:
• Terminal app:
• Shell:

Logs, screenshots, or recordings

Maintainer diagnosis and v0.9.7 acceptance

This report is the canonical user-facing tracker for the residual unknown-model class previously described in #5244.

The observed route is a privately deployed custom model whose deployment advertises a 1M context window. Unknown ids currently fall back silently to the legacy 128K window, so auto-compaction can be internally consistent while still being wrong for the configured route.

• Unknown-model fallback is explicit in model-switch/status/compaction UI and diagnostics; it never looks like a verified 128K capability.
• The existing providers.<name>.context_window override is discoverable, validated, persisted, and shown as the active source.
• Provider/catalog model ids and their context windows are data, not scattered hard-coded branches.
• Switching models/providers re-resolves the window source and pressure thresholds immediately.
• Tests cover an unknown private id with a 1M override, a known 1M route, and an unknown route with no override.
• Rebuilt-binary follow-up confirms both the visible meter and compaction trigger use the same resolved window.

[github-actions]

Thanks @hardy922 for the report.

This issue is staying open for maintainer triage. CodeWhale gets better because people bring us real edge cases from real machines, providers, regions, and workflows.

If you can add a reproduction, logs, version output, screenshots, or the provider/model involved, that makes it much easier for us to verify and harvest the fix. Maintainers may comment /lgtmi to mark recurring issue reporters as approved so this intake note is skipped next time.

[Hmbown]

v0.9.6 candidate boundary update (not yet published), exact candidate 7b16ca61d7a951a17bfacf7f16f7029f08946b84:

Known resolved 1M routes were dogfooded on the exact installed artifact: Moonshot K3 and DeepSeek V4 Flash both displayed a 1M window and completed two consecutive manual compactions without the old shared 2,048-token summary cap.

That does not resolve this report's custom/unknown-model class. We did not prove an unknown private model id with a configured 1M override, nor the visible meter and automatic trigger on that route. Keep this issue open for v0.9.7 with its current acceptance criteria. The fix must come from one resolved route/window source, not DeepSeek/K3/model-name branches.