bug(core): chat compression can exceed its target model context window #9455

What happened?

Both automatic reactive compression and manual /compress can submit a full-history summarization request that exceeds the compression model's own context window. If that request fails, the dedicated cold/slim fallback can also exceed the same window, leaving compression unable to recover an already oversized session.

The compressor currently performs a size guard when a separately configured compaction model differs from the main model. When the active/main model is also the compression model, that admission check is skipped. Cache-sharing admission can additionally use a retained provider token count rather than the actual current-route payload.

A dogfood session switching to an Anthropic model with a 1M prompt maximum produced the following sanitized sequence:

• a normal request exceeded the limit by about 101k;
• reactive compression's cold request still exceeded it by about 18k;
• manual /compress later attempted a cache-sharing request that exceeded the limit by about 102k, then a cold fallback that exceeded it by about 18k;
• a later reactive cold request exceeded the limit by about 76k.

These numbers are endpoint-reported request overages. They are not evidence that a local estimator undercounted by those exact amounts, because no same-main-model cold admission estimate ran. Separately, source inspection found that the local content estimator returns a thought part's text length before considering a co-located thoughtSignature; any future admission guard must count both fields rather than inheriting that omission.

What did you expect to happen?

Compression should not send a summarization request that is already known to exceed the selected model's context window.

Before either automatic compression or /compress sends a request, Qwen should account for the complete request and enough room for the summary, even when the compression model is the active chat model. If the full conversation still cannot fit, Qwen should reduce it in bounded stages while preserving complete tool interactions, the original user intent, and both the newest and oldest relevant context. If it cannot make safe progress, it should stop locally with a clear input-too-large error instead of sending a request expected to fail.

Conversations that already fit should continue to compress in one pass.

Client information

Login information

Observed with an Anthropic-compatible target model. The issue is in shared compression admission and recovery behavior.

Anything else we need to know?

Relationship to existing issue #2565

#2565 proposes pre-flight trimming for large tool results before normal Anthropic/OpenAI requests. This issue is related but not a duplicate: it covers the compression side-query itself exceeding the target window, including 1M-token models that #2565 explicitly excludes, and defines recovery when the full-history summarizer cannot fit.

Related work

• Discovered while validating PR feat(core): add OpenAI Responses API content generator #8169 and switching a retained session between wire types.
• Separate issues track route-scoped prompt/output token ownership and foreign thought-signature compatibility.
• No claim is made that foreign signatures caused the measured compression overage; that requires an identical-history wire/tokenizer A/B capture.