第 35 卷

**峰谷是第四条、也是最大的杠杆**：长跑任务（批量重构、跑测试、agent 长任务）挪到谷时（北京晚上或早 8 点前），账单直接**减半**——100% 差价，比上面三条的幅度都大，

且与命中率是**乘法关系**（谷时把命中/未命中/输出三档一起减半，14.1），与三原则可叠加、不需要改任何配置。

14.4 成本模型：命中率如何决定账单

**成本模型速记**（第 6 章 6.6）：`总成本 ≈ 输出token×输出价 + 输入未命中×未命中价

• 输入命中×命中价`——Agent 工作负载输入占比高，**缓存命中率是成本的第一变量**。

用 14.1 谷时 Flash 输入价算一笔账（**10k 输入 token**，命中率对比）。算术示例（90% 命中）：`9,000 × $0.007/M + 1,000 × $0.22/M ≈ $0.000283`——先把命中/未命中拆开，

再分别乘各自单价：

命中率命中 token未命中 token输入成本相对成本（Flash 谷时）

放大到 1M 输入 token：90% 命中 ≈ **$0.0283**，10% 命中 ≈ **$0.199**，全价 $0.22 （谷时未命中）——**差近一个数量级**。

再放大到手册实测量级（5.1.1：50 步工具链、2.4M 输入 token）：97% 命中 ≈ **$0.032**，全价 ≈ **$0.53**，约 **16×**。这就是 5.1.1"成本远低于按未命中价计算的预

期"的数字来源（注：旧表下此倍数约 20×，新表因命中折扣收窄降到 16×，见 14.1）。

> 注：本表只算输入侧——输出侧见 14.1 价目表（输出 = 未命中 3 倍，且不享受缓存折扣）；

输出重的任务里缓存优化的收益会小于输入重任务（14.1 折扣率变化）。

> **前缀瘦身实测（#45，数据与脚本在 [sjh9714/dsh-lean](https://github.com/sjh9714/dshlean)）**：32 次配对运行，每次从任务干净副本开始、两边都跑任务自带的测试套件验交付物。

默认 `standard` preset 的前缀为 **8,246 个未命中 token**，其中约 **3,700** 个来自单智能体会话从不调用的工具（delegation 组、goal、jobs）——按现行峰谷表，这段前缀付这一次**占

整场账单的 46%**（6 请求任务、3 次运行平均；旧统一价表下为 52%）。推论：**"前缀瘦身"——少挂从不用的工具——是高价值优化方向**，原始 token 数已提交在仓库，可按新表精确

重算。

14.5 推理档位联动：low/high/max 成本矩阵

推理档位管"思考量"，与缓存是**两个正交杠杆**：档位影响 token 总量，缓存影响输入单价，两者相乘。思考 token 减少 → 总 token 下降（第 6 章 6.6），且随上下文重复的部分同样

吃缓存折扣（推断，待实测）。

档位思考 token 量相对成本适用场景（第 6成本策略章 6.2）

low最少最低简单/确定性轮批量任务的默认次：文件操作、档

批量、工具链中的廉价步

high中等中等日常 Agent 任质量与成本的默务（默认）认平衡

max最多最高复杂推理、长链单次复杂任务可规划、debug用，别开进批量

循环

**联动要点**：

• **长工具链任务（20-50 步）收益最大**：每步思考降档的累计效果显著（第 6 章 FAQ

Q2）——档位 × 命中率两个杠杆同时作用于每一步

• 简单轮次用 `low` 档质量几乎无差别；复杂推理用 `low` 可能漏关键步骤（第 6 章 FAQ

Q3）

• **叠加示例**（2.4M 输入量级任务，Flash 谷时价）：`low` + 97% 命中 ≈ $0.032 以下

（思考量更低，实际更少，推断，待实测）；`max` + 反复冷启动 ≈ $0.53 以上——** 同一任务，两个杠杆全开与全关差 16×+**

• 注：`low/high/max` 为本手册实测网关（pi-ai/opencode-go）档位；默认 deepseek-

official 适配器为 `off/high/max`（第 6 章 6.2 注释）

14.6 预算实战：案例 A 成本估算

以第 10 章**案例 A（数据质量分析，186 秒）**为样本做预算：工具链 `read → write(clean.py) → bash → write(visualize.py) → bash → read → 总结`，约 6-8 步。按

5.1.1 量级折算（50 步 ≈ 2.4M 输入 token），案例 A 输入量级约 **50 万 token（推断，待实测）**：

场景命中率输入成本（Flash 谷时，估算）

会话延续 + 前缀稳定（推97%≈ $0.0067 荐做法）

**步骤级拆解**（为什么会话延续省钱）——只有首轮是冷启动全价，后续每轮只有"本轮消息 + 工具结果"这一小段新增量未命中（推断，待实测）：

步骤内容输入 token（推命中状态

断，待实测）

总结

**结论**：一次 3 分钟的真实任务，输入侧成本不到 **1 美分**；同样的活，做法不同（会话延续 vs 反复冷启动）成本差 **约 16×**。输出侧（两个脚本 + 总结）量级远小于输入，总

成本仍为美分级（推断，待实测）。这就是"dsh 配 V4-Flash 成本约为 Claude 的 1/10~1/30"（第 1 章实测）在单任务维度的来源。

14.7 测量方法：让 token 消耗可见

**现状（有的）**：

• Web UI 底部会话统计行：`N 轮 · M 步 | LLM Xs · 工具调用 Ys | 首 token 平均 ...`（第 6

章 6.3）

• 每轮结束行：`10:14 · 用时 9分34秒 · 首 token 1.7秒 · 79 tok/s`

（[#735](https://github.com/deepseek-ai/deepseek-harness/discussions/735) 原帖截图）

• 会话总览有总 token 统计；统计行可见"缓存命中 %"（第 6 章 6.6）——**对话内口径*

*，多对话整体命中率会被其他低命中对话拉低（[#1234](https://github.com/deepse ek-ai/deepseek-harness/discussions/1234) 社区补充，见 14.2 口径注意）

**缺口（没有的）**：**每轮 token 数**。官方讨论区 [#735](https://github.com/deepseek-ai/deepseek-harness/discussions/735)（2026-

08-14 提出，标题「【友好显示】希望在每轮对话中加入本轮对话token消耗量」）正是这个需求——已在帖子中确认存在，官方尚未实现。

**另一个缺口（#735 评论区 Jianye）**：希望在每轮显示中带 **provider 与 model id 标识**（原帖截图里 `xtoken：gpt-5.6-sol` 这类"provider + modelid"信息用户希望界面直接

给出）——同一需求帖下的补充诉求。

**社区建议（已同步到 #735 评论区）**：每轮显示应拆成**两个数**——① 本轮总 token （粗看消耗）；② 本轮缓存命中/未命中 token（看成本优化空间）。只看总 token 会误判：

同样 10k token，命中率 90% 和 10% 成本差 7.0×（见 14.4）。

**过渡期工具**：社区 `dsh-plugin-cost-tracker`（第 9 章 9.5/9.6，实时 token 成本追踪，插件/MCP 形态）——实现层面走第 4 章的插件扩展点，在请求/会话事件上统计 usage（推

断，待实测）；或按会话日志/API usage 字段手工核算。第 11 章预测"缓存命中率工具化"是中期主线（11.2）——#735 落地后成本透明化闭环。

**更完整的社区实测工具：dsh-usage**（作者