## 结论速览（自 README 迁入，2026-10-08）

- **缓存命中率：下降**（每轮注入约 300–500 token 未命中；压缩整体重置前缀）。但命中率是分母游戏，**必须看绝对成本**。
- **费用：两种计费口径都降**：按量付费（API）约 10–30%（命中近免费，收益来自避免超大上下文的天价 miss）；订阅套餐（Coding Plan）约 40–70%（命中仍计费 ⇒ 上下文是持续失血，压小直接换额度）。
- **压缩的摊销成本 ≈ 新增内容 × 未命中价，与阈值几乎无关**（摘要调用 ∝ 阈值、压缩间隔 ∝ 阈值，两者相消）⇒ 「压得勤更贵」是错的，全部收益来自上下文规模。
- **同一组阈值的钱效**：高缓存价档（1:4）约为 DeepSeek（1:50）的 3.8 倍。
- 变更记录（2026-10-07）：配置面从 10 个字段精简到 6 个；决策卡门槛并入智能压缩线（原 policyCardMinRatio 与 markerMinRatio 分离会在 [0.30,0.35) 形成「收不到卡 ⇒ 不知道要标记」的死区）。

# dsh-context-pilot 成本模型

> 本文原为 README §7，2026-10-07 拆出（README §4 保留结论摘要与推荐值）。
> 分析口径：**官方单价取证 + 本机实测校准**。
> 文中 `§N` 指的是**本文件**的小节（§1 官方单价 / §2 命中率影响 / §3 关键解析 / §4 阈值弹性 / §5 计算器）。

## 1 官方单价（均为官方文档原文，2026-10-06 取证）

全部为 **人民币 ¥/1M** 口径（DeepSeek 取自官方中文定价页的原生 ¥ 价，非汇率折算）：

| 口径 | 缓存命中 | 未命中 | 输出 | 命中:未命中 |
| --- | --- | --- | --- | --- |
| DeepSeek `deepseek-flash`（空闲时段） | **0.02** | **1** | 4 | **1:50** |
| DeepSeek `deepseek-v4-pro`（空闲时段） | 0.15 | 4.5 | 13.5 | 1:30 |
| GLM-5.3（积分，系数/10000） | **1.7** | **6.9** | 24 | **1:4.1** |
| GLM-5.3-Flash（含视觉 MCP） | 0.56 | 2.3 | 8 | 1:4.1 |

- DeepSeek：高峰价为非高峰 2 倍（高峰 = 周一至周五 01:00–04:00 / 06:00–10:00 UTC）。
- 智谱积分公式（官方原文）：`积分 =（输入 Token × Input 系数 + 缓存命中 Token × Cached Input 系数 + 输出 Token × Output 系数）/ 10000`；
  非高峰（周一至周五 14:00–18:00 UTC+8 之外）按 **50%** 抵扣。
- **智谱的积分确为缓存感知**（原以为可能是一揽子费用——实测公式明确分段），故「DeepSeek API / 智谱积分」两类付费确实只需一套模型。

## 2 插件如何影响缓存命中率（三个作用点）

1. **每轮注入**（实测：`m1-report.json` 中 `m2.lastText`）
   变体三种：用量行 167–169 字符（纯 ASCII）／+决策卡 528 字符／+一次性说明 813 字符；约 **300–500 token/轮**。
   **不破坏前缀**：注入是**追加**在本轮 user 消息之后的新消息，历史消息一字节不改；DeepSeek 的前缀缓存要求「完整匹配缓存前缀单元」，而上一轮的 `[…, 注入_N]` 已持久化为单元 ⇒ 下轮命中。注入只是往尾部加少量未命中 token。
2. **压缩（核心功能）**：把旧消息重写为摘要 ⇒ **前缀整体变化** ⇒ 该轮上下文全部转为未命中。这是任何压缩（含官方 80% 阈值）都无法避免的一次性代价。
3. **净效果 = 命中率下降**（例：原生 80% 阈值 ⇒ 平均 415K 上下文、命中率约 96.9%；插件早压至 150K ⇒ 平均 90K、命中率约 85.6%）。
   **但命中率是分母游戏**——上下文越小，固定新增内容的占比天然越高。**只看命中率会得出错误结论，必须看绝对成本。**

## 3 关键解析结论

**① 压缩的摊销成本 ≈ 新增内容 × 未命中单价，与阈值几乎无关。**
摘要调用要读完整上下文（∝ 阈值），但压缩间隔也 ∝ 阈值，两者相消：
DeepSeek `6767 × ¥1/1M ≈ ¥0.0068/段`；GLM-5.3 `6767 × 6.9/1e4 ≈ 4.7 积分/段`。
⇒ **「压得勤 ⇒ 摘要调用多 ⇒ 更贵」是错的**，摊销后近似持平。**全部收益来自上下文规模**。

**② 上下文规模对两家的杀伤力差 2 倍以上**（本机实测增速 6.8K token/段）：

| 上下文 | DS flash ¥/请求 | GLM-5.3 积分/请求 | 相对 90K：DS | 相对 90K：GLM |
| --- | --- | --- | --- | --- |
| 30K | 0.00108 | 8.6 | 0.86 | 0.46 |
| 90K | 0.00126 | 18.8 | 1.00 | 1.00 |
| 285K（本会话） | 0.00185 | 52.0 | **1.46** | **2.76** |
| 600K | 0.00279 | 105.5 | 2.21 | 5.61 |
| 850K | 0.00354 | 148.0 | 2.80 | 7.87 |

**结构占比（285K 上下文）**：DS「重读上下文」仅占单请求成本 **45%**；GLM 占 **91%**。
⇒ GLM 上上下文是**持续失血**，DeepSeek 上则相当便宜——这就是两家最优阈值不同的根因。

**③ 一次真实压缩的收益**（07:29 实测：285,059 → 23,659，省 261,400 token / -92%）：
- 此后**每个请求**省：DS `¥0.0052`；GLM-5.3 `44.4 积分`；GLM-Flash `14.6 积分`
- 按 R=5 请求/轮、约 39 轮回填到压缩前水平：累计省 DS `¥1.09`、GLM `8,665 积分`
  （**≈ Pro 套餐 12,000 积分/5h 的 72%** —— 一次压缩就换回大半个额度窗口）

**④ 还有一个放大因子（未计入上表）**：agentic 会话里**每轮用户输入触发多次 LLM 请求**（工具调用循环），每次都重读整个上下文。故实际收益需乘 R（本机估计 R≈5，视任务而定）。

## 4 阈值 → 成本弹性（实测校准）

| 阈值 | 平均上下文 | DS ¥/请求 | 相对 0.15 | GLM-5.3 积分/请求 | 相对 0.15 |
| --- | --- | --- | --- | --- | --- |
| 0.15 | 88K | 0.00126 | 1.00 | 18.4 | 1.00 |
| 0.20 | 113K | 0.00133 | 1.06 | 22.6 | 1.23 |
| 0.30 | 163K | 0.00148 | 1.18 | 31.1 | 1.69 |
| 0.50 | 263K | 0.00178 | 1.42 | 48.1 | 2.62 |
| 0.80 | 413K | 0.00223 | 1.78 | 73.6 | 4.00 |

（假设：压缩在阈值触发、压后回落至约 25K；平均上下文取两者中值。）
⇒ 阈值 0.15 → 0.30 时 **DS 仅涨 18%，GLM 涨 69%**。**同一组阈值，GLM 上的钱效约为 DS 的 3.8 倍。**

## 5 面板内置计算器（2026-10-06 新增，`client.js` PriceCalculator）

配置区**下方**新增「成本阈值计算器」——把手算变成随单价实时推导：

- **预设按钮**（官方单价一键填入）：DeepSeek flash/v4-pro、GLM-5.3/5.3-Flash、Kimi K3、千问 3.8-Max/3.8-Flash、阶跃 step-5（全 ¥ 口径，GLM 为积分）
- **三个输入**：缓存命中价、未命中价、输出价（手改即退出预设高亮）
- **诊断行**：命中:未命中比值、上下文项占单请求成本 %、估算单请求成本
- **推荐行**：`markerMinRatio`（智能压缩线）/ `criticalRatio`（强制压缩线）+ 判语
- **「一键填入并保存」按钮**：写入推荐字段（走与上方表单完全相同的 `persist → writeField` 路径，
  含命名空间 `set` + **回读校验**；未变化的字段自动跳过）。失败提示（未就绪/未持久化）与手工保存一致。

**推导模型**（与 §3 结构占比、README §4 推荐值同一套，锚点取**实测** ctxShare 而非理想值，故能复现下表）：

```
ctxShare       = (上下文 - 新增)·命中价 / [(上下文 - 新增)·命中价 + 新增·未命中价]     // 参考占用 35%，新增 6.8K
markerMinRatio = lerp(ctxShare, 0.50→0.93, 0.30→0.15)    夹逼 [0.12, 0.40]   // 智能压缩线
criticalRatio  = lerp(ctxShare, 0.50→0.93, 0.85→0.80)    夹逼 [0.75, 0.90]   // 强制压缩线
```

| 预设 | 比值 | ctxShare | 计算器输出（智能线 / 强制线） |
| --- | --- | --- | --- |
| DeepSeek flash | 1:50 | 50% | 0.30 / 0.85 |
| DeepSeek v4-pro | 1:30 | 63% | 0.26 / 0.84 |
| 阶跃 step-5 | 1:20 | 72% | 0.22 / 0.82 |
| 千问 3.8-Flash / Max | 1:8 | 84–86% | 0.17 / 0.81 |
| Kimi K3 | 1:4 | 93% | 0.15 / 0.80 |
| GLM-5.3 / 5.3-Flash | 1:4.1 | 92–93% | 0.15 / 0.80 |

**边界已校验**：`0`/负数/缺失 → 提示「请输入有效的正数价格」不写入；极端比值（1:1e6）夹逼到上下限；
推荐值恒落在 host `mergeConfig` 的范围守卫内（比率类 [0,1]）。计算器单元测试（判据从 client.js 抽取）覆盖
「未变跳过」⇒ 已应用时 `written=0`。

> 说明：上表「每请求成本」由**官方单价 + 本机实测注入量/增速**建模；R（每轮请求数）为估计值。
> **方向性结论（命中率降、绝对成本降、GLM 收益远大于 DS）对参数不敏感。**