[Bug] Claude Opus（Kiro Max 渠道）在 dsh 中每轮请求后上下文即超窗，压缩后无法恢复，会话完全不可用；同渠道 Claude CLI 正常

[fu827707013]

环境

• dsh：0.2.1-rc.2（Windows 11，web profile）
• 模型：claude-opus-5-5
• 渠道：Kiro Max（第三方 Anthropic 协议中转）
• 上下文管理：billion-context 0.1.204（第三方插件，非官方），配置 modelContextLimit=256000
• 对照：同一渠道、同一模型的 Claude CLI

现象

在 dsh 里用 claude-opus，每轮请求结束后上下文都会直接超窗。界面显示「上下文已用 100%，~300K / 290K」。

但界面分项加起来只有约 75K：系统提示词 ~7K，工具定义 ~37.4K，对话消息 ~30.4K。

触发压缩后，界面短暂降到 50% 以下，下一轮又回到 100% 以上。于是每一轮都在紧急压缩，每次耗时 30–80 秒，最后请求被中断（client aborted mid-stream）。claude-opus 在 dsh 里已经完全无法使用。

数据（同一会话，UTC 2026-10-23，取自会话日志里的上游原始 usage）

时间	实际发出的请求体	input	cache_read	cache_write	合计	output
18:01:15	349.3 KiB	1075	106451	1075	108601	220
18:01:27	360.5 KiB（只多了 11 KiB）	4	384282	5333	389619	532
18:02:20	压缩后 246.9 KiB	5	282613	4123	286741	1659
18:03:48	压缩后 261.4 KiB	5	295647	4225	299877	202
18:04:30	压缩后 238.4 KiB	—	264741	—	268444	—

要点：

1. 相邻两轮请求体几乎一样大（349 KiB 和 360 KiB），上游回报的输入却从 10.8 万跳到 39 万，增量几乎全在 cache_read_input_tokens。
2. 压缩生效后，请求体从约 360 KiB 降到约 240 KiB，本地估算的实际内容只有 6–7 万 token，上游仍持续报 27–30 万。插件为对齐上游学出的校准系数是 k̂=4.00。
3. output 只有几百 token，和最大输出设置（40000）无关。

和 Claude CLI 的对比（同渠道、同模型）

Claude CLI 也收到了同样的跳变。例如一次请求从 136834 跳到 224797，而新增内容只有约 3.7 万字符，增量同样在 cache_read 上。

不同的是，Claude CLI 会在后台把整段对话总结成摘要，然后从摘要重新开始。压缩后读数回到 10–12 万，用起来几乎没有感知。一个会话约 3 小时里自动压缩了 5 次左右，上下文从没卡死过。

dsh 这边，压缩只能折叠部分历史。上游持续虚报时，dsh 和插件都按上游 usage 判断是否超窗，所以会陷入「紧急压缩 → 仍超窗 → 再压缩」的死循环，会话没法继续。

期望

1. 当上游 usage 和实际请求体大小明显不一致时（比如 cache_read 远大于请求本身），dsh 能识别出来，或者允许按本地估算判断上下文占用，而不是直接把上游数字当成上下文大小。
2. 超窗时提供类似 Claude CLI 的整段摘要式自动压缩，作为兜底，保证会话能继续用，而不是反复做无效压缩。
3. 上下文面板的总数和分项差距很大（~300K 和 ~75K）时，给出提示，便于排查。

需要更多日志的话，我可以补充。

[zhangqinghe1984]

关于第 2 点：
Claude CLI 在这个渠道上能撑住，我理解主要是因为它把 claude-opus-5-5 当作 1M 窗口，阈值足够大。

根因是中转虚报了 usage（cache_read 约为真实值的 4 倍）。dsh 按上游数字判断占用，在当前窗口下压缩无论如何都降不到阈值以下。手动调大窗口，可以让阈值装得下这份虚报，压缩就能成功、不再反复循环。

1. 在 ~/.dsh/profiles/desktop/cordis.patch.yml（使用 dsh web 时是 ~/.dsh/profiles/web/cordis.patch.yml）里给 Opus 5.5 设置窗口：

• id: llm-pi-ai
  config:
  providers:
  <你的 Provider ID>:
  apiKeyEnv: <凭据变量>
  api: anthropic-messages
  baseURL: <中转地址>
  models:
  - id: claude-opus-5-5
  contextWindow: 1000000

2. billion-context 插件的 compress.modelContextLimit（当前是 256000）也要同步调大或去掉，否则插件自己还会继续触发「紧急压缩」。

注意：面板上的读数仍然是虚报的。如果 Kiro 后端的真实窗口小于 1M，就只能等后端报超窗错误后再恢复。最好解决办法也许是换一个如实回报 usage 的渠道。

[fu827707013]

好吧，这些参数，配置我都试过，对这种情况，没太大效果，我现在换到claude cli里面使用opus了，先这样吧
其他模型，我就继续在dsh中使用

[zhangqinghe1984]

～～