# 预算计算与开发起因

以下 K 表示 1,000 token，M 表示 1,000,000 token。输入估算、provider 实际 usage、输出上限和压缩阈值是不同量。

## 当时为什么需要它

早期实例会给每次请求保留最高 384,000 的输出额度。历史故障中，服务端报告的容量是 1,048,576，因此固定额度下输入最多约为：

```text
1,048,576 − 384,000 = 664,576
```

实际出现过 665,098 输入与 384,000 输出额度相加超限。后续又出现中断后校准丢失，真实输入约 692K 却被低估到约 440K，插件错误恢复 384K 输出的故障：

```text
692,255 + 384,000 = 1,076,255 > 1,048,576
```

因此插件包含两部分能力：根据剩余预算动态缩小输出；跨取消、失败和续聊保留有效的输入校准。真正压缩或输入结构改变后重新校准，避免一直沿用旧高水位。

这属于作者本地历史故障依据，不是当前所有服务端统一容量声明。发布包使用适配器声明与配置窗口的较小值；日常配置为 1,000,000，没有直接把历史服务端的 1,048,576 当作可用预算。

## 1M 窗口下的动态输出

本包参数：窗口上限 1,000,000，输出上限 384,000，安全余量 32,768。暂忽略其他更小的 agent 或适配器上限：

```text
输出上限 = max(1, min(384,000, 967,232 − 输入估算))
```

- 不计安全余量，完整 384K 输出的输入边界是 616,000。
- 按本包安全余量，收缩起点是 583,232。
- 输入估算达到 900,000 时，输出上限为 67,232。
- 616,000 到 900,000 的区间宽 284,000。
- 583,232 到 900,000 的区间宽 316,768；它比上一行多出的 32,768 是提前保留的安全空间，不能重复算成新增输入收益。

这些数字描述预算如何分配。具体会话是否走到这些位置，还取决于压缩策略、计数误差、新输入增量和实际模型限制。

## 为什么不能计算为 800K − 384K

800K 来自“1M 窗口的 80% 压缩阈值”，不是总上下文容量。输出额度从总容量中扣除，之后与比例阈值比较；不是再从 800K 中减去 384K。

本地安装的 `0.1.7-rc.2` 官方 basic 逻辑是：

```text
压缩阈值 = min(窗口 × thresholdRatio,
               窗口 − 当前输出预留 − headroomTokens)

默认示例 = min(1,000,000 × 0.8,
               1,000,000 − 384,000 − 65,536)
         = min(800,000, 550,464)
         = 550,464
```

因此，这组参数下提前生效的是约 550K 的预算保护，而不是 800K 比例线，更不是 416K。

## 本地约 900K 的组合方案

本地日常预设另外使用 `compaction-instant`，配置 `thresholdRatio: 0.9`。按 1M 的声明窗口，其压力目标约为 900K，由该压缩引擎处理历史。

```text
900,000 − 550,464 = 349,536
```

这约 349.5K 是“官方 basic 默认示例”与“本地组合方案”的理论压缩阈值差。Adaptive Max Tokens 提供逐渐收缩的输出预算，配套压缩引擎提供新的压力策略。只安装 Adaptive Max Tokens，不会替换官方压缩引擎，也不会自动把阈值改成 0.9。

保留官方 basic 时，它可能在约 550K 先触发，从而在本插件约 583K 的收缩起点之前已经压缩。不能仅靠安装此包或只把比例改成 0.9，就保证复现本地组合方案。

## 版本与证据边界

- 本地 `0.1.6-alpha.1` 的 basic 计算路径是窗口乘比例，没有上述 rc.2 的同一输出预算扣减公式；不要把 rc.2 的 550,464 数字套到所有版本。
- 较早记录曾使用 0.6、0.78 等比例和其他预算参数；它们是不同阶段的配置。当前发布参数见 README。
- 0.1.7 日常预设的历史记录包含 900K 人工压力边界检查和真实短请求；不等于已经完成实际在线 900K–1M 长会话测试。
- 原始会话、机器路径和完整日志不随本仓库分发。

参考：本地安装的 `@deepseek-ai/dsh-compaction-basic@0.1.7-rc.2` 的 `resolveCompactSpec` 与 `resolveConfig` 实现；核对时[上游主线源码](https://github.com/deepseek-ai/deepseek-harness/blob/master/packages/compaction/compaction-basic/src/config.ts)也使用此计算方式，上游后续可能变化。