[Bug] 长会话续用时额度消耗异常加速，任务因配额中断，等配额刷新后继续，输入“继续”指令后出现额度异常快速消耗

提交前确认 · Pre-submission checklist

• 我已搜索过现有 issue，确认这不是重复 / I searched existing issues and confirmed this isn't a duplicate.
• 我已阅读 CONTRIBUTING.md / I've read CONTRIBUTING.md.

问题类别 · Category

计费 / 配额 · Billing / Quota

涉及的 Agent 框架 · Agent framework

ZCode Agent（自研）

严重程度 · Severity

影响体验 · Major (功能可用但体验受损 / works but degraded)

复现频率 · Reproducibility

必现 · Always

问题描述 · Description

遇到的问题：我有一个持续三天、断续续用的任务会话。每次恢复会话并让它继续干活，很快就会提示 5 小时窗口额度耗尽；整个会话累计 input 消耗约 7580 万 token，而真正的工作产出（output）只有约 25 万（0.3%）。

接入方式：火山方舟 Coding Plan（ark.cn-beijing.volces.com），以自定义模型配置接入，模型 GLM-5.3；协议为 Anthropic 兼容格式，服务端正常返回 usage（含 cache_read_input_tokens 分项），因此可以逐笔核对。

调查过程：我核对了 ZCode 本机的请求数据库（model_usage 表，含每次调用的 token 明细）和请求日志，排除了后台任务偷跑的可能，并画出了单次请求 input 随时间的变化曲线，用新开窗口会话做对照。

初步找出的原因（三个机制叠加）：

1.auto-compact 全程未触发，且额度耗尽总是发生在压缩阈值之前。 上下文从 16,442 单调升至 362,844，三天内 auto-compact 一次都没有触发过；唯一一次下降来自我手动执行 /compact（第 372 次请求，362,844 -> 23,909），此时已按全价计费约 7,500 万 input。更关键的是：全会话 5 次额度耗尽（rate_limited）发生时的上下文水位为 21.3 万–36.1 万，全部低于压缩触发点--即在现有阈值设计下，额度总是先于自动压缩耗尽，auto-compact 对配额保护实际不起作用。
2.会话恢复全额继承，且缓存隔夜必过期。 四次恢复会话的首笔请求分别携带 21.3 万 / 26.3 万 / 31.8 万 / 36.3 万 input token；由于中断期间缓存已过期，这四笔的全价比例均为 95%–97%--每次“继续”都意味着先按全价重发一遍全部历史，才开始干活。
3.额度耗尽全部发生在上下文高位。 会话内共 5 次 rate_limited（5h 窗口耗尽），发生时的上下文水位为 21.3 万–36.1 万。最近一次耗尽前，1 分钟内连发 5 笔、每笔约 36 万 input。
对照组：同时段新开窗口 52 次请求合计约 314 万 input，均摊约 6 万/次；问题会话均摊约 17.5 万/次，差异完全来自上下文体量。压缩发生后（上下文回到 2.4 万起），单次消耗立即回落到正常水平--反证了前 371 次请求多付的部分就是上下文重发。

建议：① 恢复会话时先压缩再继承；② 自动压缩时机提前或阈值可配置；③ 界面显示当前上下文大小与每次发送的预计消耗，用量统计区分“全价输入/缓存命中”；④ 缓存重读按折扣权重计入窗口额度属火山方舟侧口径，建议协同确认。

复现步骤 · Steps to reproduce

1.以自定义模型（我用的火山方舟 coding plan）接入Zcode，任一会话连续使用数小时（大量文件读取、测试、工具调用），使上下文增长到 20 万 token 以上；
2.关闭客户端，隔天恢复该会话并输入“继续”，任其自主运行工具循环约 20 分钟；
3.观察 5 小时窗口额度被耗尽，token 统计达千万级；
4.全过程可用本机 model_usage 表的 input_tokens 字段逐笔观察单次请求消耗的增长。

期望表现 · Expected behavior

1.恢复会话时先压缩再继承，而非全额恢复历史上下文；
2.自动压缩的触发时机提前，或允许用户配置阈值（95% 对配额经济学而言太晚，与 #114 诉求一致）；
3.界面显示当前上下文大小与每次发送的预计消耗，用量统计中将“全价输入”与“缓存命中”分开展示，让用户能在额度烧穿前止损；

实际表现 · Actual behavior

恢复后的会话以约 24 万 token / 次的速率消耗额度，界面上没有任何上下文体积或单次成本的提示，用户只能通过“额度耗尽”发现问题。

ZCode 版本 · ZCode version

v3.7.7

设备 / 系统 / 浏览器 · Device / OS / Browser

Windows 11 x64（build 10.0.26200），ZCode 桌面版

截图 / 录屏 / 日志 · Screenshots / Recordings / Logs

[model-usage-export.csv](https://github.com/user-attachments/files/31270212/model-usage-export.csv) [request-log-sample.md](https://github.com/user-attachments/files/31270211/request-log-sample.md)

Start by reviewing the attached model-usage-export.csv, request-log-sample.md, and the model_usage table fields described in the report, then compare the behavior with issue #114. No source file, test, or entry point is identified, so the first task is to locate the session-resume, auto-compact, and usage-accounting implementations. Done requires a confirmed scope and reproducible test coverage for the agreed behavior.