[Bug] 上下文超过100%未触发自动压缩

[traderlife8]

问题触发操作: 从1M大上下文模型切换为200K小上下文的模型后,继续对话就卡死,上下文超过100%也未触发自动压缩上下文,模型切换回来1M的也无法继续正常对话, /compact 手工压缩上下文也失败

[liyangbing]

I checked the rc.2 source order. This looks like a model-capacity transition problem, not simply a missed 80% threshold.\n\nAt agent/pre-step, automatic compaction resolves its target from session.requestHeader(), which is the last durable request route. The current Agent route is resolved later in buildRequest(), where the new request/header and request/context are appended before the provider call. Therefore the first 1M→200K turn can be pressure-checked against the old 1M threshold, then sent against the new 200K capacity before another pre-step can compact it.\n\nSafest recovery:\n\n1. Stop retrying the over-budget turn.\n2. If the approved 1M route is still available, return to it only to run one evidence-preserving /compact after the Agent is idle.\n3. Confirm compaction succeeds and prompt + requested output fits below 200K with useful headroom.\n4. Then switch to the 200K model and send one small control prompt.\n5. If /compact also fails, create a new Session with a concise handoff instead of copying the transcript or editing Session JSONL.\n\nFor the report, the most useful evidence is the previous and pending provider/model/contextWindow, latest request/header and request/context, active maxTokens, /compact result, and whether the first smaller-route request reached the provider before any compaction event.\n\nI added the source timeline, downgrade procedure, and regression contract here: https://sandbaseai.github.io/deepseek-harness-handbook/context-window-overflow.html

[traderlife8]

同一个会话过程中, 根据任务需求每次对话都有可能切换不同的模型(支持的最大上下文也不相同), 建议每次发送对话后DSH首先检查上下文是否超过了当前模型的上下文自动压缩阈值, 如果超过就先压缩上下文再继续对话. 如果上下文超过了当前使用模型的最大上下文导致无法压缩, 则自动用上一次对话使用的模型进行压缩, 再重复该步骤检查直到上下文不超过当前模型的能力, 再继续对话. 我之前用的Qoder和CodeBuddy感觉就是这个压缩逻辑, 我写代码用GLM-5.2(1M), 总结md文档就手工切换到HY3(200K), 新对话发送后CodeBuddy检测到上下文超限就自动压缩, 直到上下文不超过HY3的能力才继续工作. 建议参考!