是否能显示context使用百分比，以及自动compact conversation

[Vince0911]

RT，能像copilot订阅的原始模型一样，显示当前对话使用的context window百分比，并且提供自动compact conversation的功能（当context占用率达到一定比例上限的时候？）

[Vizards]

显示当前对话使用的 context window 百分比

• 如果想要像内置模型一样显示在右下角，由于 github copilot chat 的 API 限制，目前无法做到。详细说明请参考 Token count in context window UI always stays at 0/1M with DeepSeek V4 Pro Max #3 (comment)
• 如果接受在插件 StatusBar 展示，目前有 contributor 正在做这个工作 feat: add token usage tracker with cost breakdown and status bar display #21

自动 compact conversation 的功能

就目前我分析 github copilot chat 的源代码的结果来看，github copilot chat 自身对 BYOK 模型就有相当细致的自动上下文压缩的功能：

阈值	行为	阻塞？	消息是否变化	对缓存的影响
≥ 80%	启动后台 compaction：异步调 LLM 生成摘要，agent 主循环继续用完整历史	❌	❌ 不变	无影响
≥ 85%	主动 inline summarization：在 prompt 尾部塞一条指令要求模型输出 <summary> 标签	❌	✅ 尾部多一条 User 消息	前缀不变，尾部新增不影响缓存
≥ 95%	阻塞等待后台 compaction 完成 → 摘要替换历史 → 重新渲染 prompt → 发给模型	✅ 阻塞	✅ 历史被摘要替换	缓存全 miss
100% (BudgetExceededError)	同步前台 fallback：调 LLM 生成摘要 → 替换历史 → 重新渲染	✅ 阻塞	✅ 同上	缓存全 miss

主要有几个考虑：

• 由于 deepseek v4 特殊的上下文缓存逻辑，基于目前 github copilot chat 提供的上下文压缩方式，会导致一次性的大量 cache miss.
• 插件需要做一些工作，让 copilot chat 能够更准确地获取当前对话占用的 context window
• 相比较 copilot 内置的其他模型，当前 deepseek 1M 的上下文很难触发自动上下文压缩

你可以尽可能分享你关于自动上下文压缩的使用场景吗，以帮助我更好地设计手动/自动上下文压缩的交互，感谢

[jjijack]

我来分享一个场景吧，今天因为一个任务一直不是很满意，在同一个聊天里反复修改，最终达到上下文上限，cache rate暴跌，一下子吃掉了好多余额😢手动compact后恢复正常。

[13:39:28.101] [info] tokens: prompt=500923 completion=125 | cache: hit=500864 miss=59 rate=100% | chars/tok=2.48
[13:39:35.684] [info] tokens: prompt=501113 completion=113 | cache: hit=500992 miss=121 rate=100% | chars/tok=2.48
[13:39:49.356] [info] tokens: prompt=501688 completion=282 | cache: hit=501120 miss=568 rate=100% | chars/tok=2.48
[13:41:14.046] [info] tokens: prompt=502094 completion=235 | cache: hit=125312 miss=376782 rate=25% | chars/tok=2.48
[13:41:23.121] [info] tokens: prompt=502518 completion=121 | cache: hit=501888 miss=630 rate=100% | chars/tok=2.48
[13:41:29.384] [info] tokens: prompt=502691 completion=92 | cache: hit=502528 miss=163 rate=100% | chars/tok=2.48
[13:41:38.333] [info] tokens: prompt=503031 completion=141 | cache: hit=502656 miss=375 rate=100% | chars/tok=2.48
[13:43:03.022] [info] tokens: prompt=503158 completion=220 | cache: hit=196608 miss=306550 rate=39% | chars/tok=2.48
[13:44:49.329] [info] tokens: prompt=503720 completion=278 | cache: hit=125312 miss=378408 rate=25% | chars/tok=2.48
[13:45:14.190] [info] tokens: prompt=504112 completion=207 | cache: hit=212352 miss=291760 rate=42% | chars/tok=2.48
[13:45:31.261] [info] tokens: prompt=504472 completion=216 | cache: hit=212608 miss=291864 rate=42% | chars/tok=2.48
[13:46:49.969] [info] tokens: prompt=504681 completion=293 | cache: hit=213120 miss=291561 rate=42% | chars/tok=2.48
[13:53:10.476] [info] tokens: prompt=124737 completion=5420 | cache: hit=0 miss=124737 rate=0% | chars/tok=2.64
[14:04:01.977] [info] tokens: prompt=129654 completion=314 | cache: hit=19968 miss=109686 rate=15% | chars/tok=2.68
[14:04:06.519] [info] tokens: prompt=130008 completion=84 | cache: hit=129920 miss=88 rate=100% | chars/tok=2.71
[14:04:15.238] [info] tokens: prompt=130163 completion=204 | cache: hit=130048 miss=115 rate=100% | chars/tok=2.73

我感觉至少应该加入一个兜底，在即将达到上限时进行阻塞式的compact，避免因为超出缓存容量上限导致出现大量miss

[Vizards]

@jjijack 此问题可能并不是达到上下文上限导致。你可以在 #56 找到原因。
如果你认为你的情况不符合 #56，请在打开调试日志开关后，上传日志到 #25