# 真实计费核对（真实 usage 口径，不是模拟）

> 2026-10-29 · goal 当前阶段 ①
> 复现：`node test/measure-billing.mjs <sessionDir>`（真实 usage）+ `node test/measure-ledger.mjs`（清单开销）
> 数据源：`<DSH_HOME>/sessions/**/session.v4.jsonl.zstd` 里每次请求的
> `assistant/message.data.usage = {inputTokens, outputTokens, totalTokens, cacheReadTokens}`

## 〇 · 结论先说（三条，都是数出来的）

1. **prompt 缓存吃掉 94~97% 的 prompt token** —— 「省 token」≠「省钱」：名义上省下的历史，
   绝大部分本来就是按缓存价计费的。任何只报 token 数的"节省"都高估了钱。
2. **这个插件曾经是上下文的最大浪费源**：死亡循环会话 `session-5acafe42` 里，
   热清单占了**全部 prompt 的 21.3%**（55.0M token），其中 **98.9% 是陈旧副本**（54.4M）——
   这正是 v1.5.0「就地替换 + 历史清理」修掉的东西。
3. **fold 在真实会话里几乎从未成功过**：`session-5acafe42` 3/226、`session-5787ac6b` 1/51。
   原因有两个：P0（worldHash 崩溃，v1.3.5 已修）+ **摘要模型 id 在 provider 里不存在**（本轮新发现，见第四节）。
   真 fold 的净收益（遮蔽 317,427 → checkpoint 6,909 token）**远远打不过**旧清单的 55M 浪费。

## 一 · 真实 prompt 规模与缓存命中率

| 会话 | 请求数 | prompt tokens | 未缓存 | 缓存命中 | 命中率 | 平均 prompt |
|---|---:|---:|---:|---:|---:|---:|
| `session-5acafe42`（死亡循环） | 653 | **258,330,390** | 14,145,049 | 244,185,341 | **94.5%** | 395,605 |
| `session-365cdcf6` | 130 | 25,522,386 | 1,620,306 | 23,902,080 | 93.7% | 196,326 |
| `session-5787ac6b` | 429 | 194,031,958 | 10,280,790 | 183,751,168 | 94.7% | 452,289 |
| `session-e16faf2b`（当前会话） | 348 | 93,691,039 | 2,781,471 | 90,909,568 | **97.0%** | 269,227 |

**读法**：一次 66 万 token 的上下文请求，真正按未缓存价计费的只有 ~5%（3 万左右），
其余 95% 是缓存读。所以「压缩省下 XX 万 token」在账单上要打折 —— 具体折扣取决于缓存价与原价之比
（本机网关的价目表不落盘，`magpie/usage.jsonl` 只记 `in/out/cache_read/cache_write`，无金额）。

## 二 · 热清单自己占了多少（这是 v1.4.0 / v1.5.0 修的东西）

| 会话 | 清单占 prompt | 其中**陈旧副本** | 说明 |
|---|---:|---:|---|
| `session-5acafe42` | **21.29%**（55.0M tok） | **54,413,450 tok（98.9%）** | 旧渲染器无预算（单条可达 28,800 tok）× 从不替换 ⇒ 44 条叠在 surface 上 |
| `session-365cdcf6` | 21.5%（5.4M） | 5,386,478 | 同上 |
| `session-5787ac6b` | 2.7%（5.2M） | 5,112,017 | 同上 |
| `session-e16faf2b`（v1.3.1 之后） | **0.2%**（127K） | 127,539 | 清单被 500 token 预算管住；P1-4 后陈旧副本不再增长 |

**这就是 v1.5.0 的直接收益**：把「清单越攒越多」变成「永远一条」。
在 `session-5acafe42` 这种会话里，等于把 **5,440 万 prompt token 的陈旧副本**从后续每一轮里拿掉。

## 三 · fold 的真实收支

| 会话 | fold 成功/失败 | 遮蔽 token | checkpoint token | 净省 token |
|---|---:|---:|---:|---:|
| `session-5acafe42` | **3 / 223** | 317,427 | 6,909 | **310,518** |
| `session-5787ac6b` | 1 / 50 | — | — | — |
| 当前会话（重启后） | **0 / 8** | — | — | — |

三件事很清楚：
1. 失败率高到 fold 基本等于不存在，所以「省 22.7%–43.3%」的模拟数字在实机上从来没发生过；
2. 成功的 3 次净省 31 万 token —— 相对于 2.58 亿 prompt 是 0.12%，可以忽略；
3. **当前会话（02:37 重启后）又出现 8 次失败**，原因是新的（见第四节）。

## 四 · 本轮发现的生产 bug：摘要模型 id 在 provider 里不存在

当前会话在 45 万 token 阈值的压力下连续 8 次尝试压缩，全部报同一个错：

```
pi-ai provider "magpie" has no configured model "ima/deepseek-v4.1-flash"
```

**根因**：插件自带的 `cordis.patch.yml` 和已安装的 `personal-assistant` preset 都把摘要模型写成
`magpie` + `ima/deepseek-v4.1-flash`，但 `profiles/desktop/cordis.patch.yml` 里 magpie provider 的
模型表只有 `group/deepseek-v4.1-flash1017` 和 `group/gokifu-compact` —— 那个 free 路由不在表里。
（`magpie/usage.jsonl` 里确实有 67 次 `ima/deepseek-v4.1-flash` 请求，但都是更早的配置；且它 `in/out/cache` 全为 0，
免费路由不报 usage，所以摘要成本本来也看不见。）

**修法（两层）**：
1. **引擎兜底（产品层）**：摘要模型不可用时**退回「当前路由的模型」重试一次**（`src/engine.mjs` 的 `summarize()`），
   只重试一次、同一个模型失败就照旧抛错。测试：harness 两条（退回成功 / 相同模型不重试）。
2. **配置修正**：插件自带 patch 与已安装 preset 都改成 `summarizationProvider: '' / summarizationModel: ''`
   （留空 = 跟随路由，任何 provider 都可用）。已改安装态，备份
   `cordis.patch.yml.bak-before-summarizer-fix-1793213214`。

## 五 · 复跑

```bash
cd D:/主工作区/projects/dsh-chess-context
node test/measure-billing.mjs "D:/DeepSeek Harness/home/sessions/--D-~4E3B~5DE5~4F5C~533A--/session-5acafe42-..."
node test/measure-billing.mjs --json out.json      # 扫全部会话
node test/run.mjs engine-harness                   # 摘要模型回落的两个用例
```

## 六 · 局限（不虚报）

1. `magpie/usage.jsonl` 没有金额字段 ⇒ 只能给「未缓存 / 缓存」两种 token，钱要按网关价目表折算。
2. ~~清单 token 是 `字符数 / 3` 的保守估算；真实分词会差 ±10%。~~
   ⇒ **2026-11-01（1.13.0）已换口径**：热清单改按字符类别加权 —— **CJK 1 token/字 + 其余 1/4 token/字**
   （锚点：2478 字符的真实热清单，旧口径 826（−8.8%）→ 新口径 933，网关实测 905，差 +3.1%）。
   **本文全文的「清单 token」数都是旧口径产物，与 1.13.0 之后的数字不可直接比。**
3. **没有并行对照组**：真 A/B（同任务官方模板 vs 插件）需要两条独立会话跑同一任务，本轮没做；
   这里的"节省"是同一会话内的收支拆解，不是对照实验。
4. 当前会话的放大结论（清单占 21% → 0.2%）横跨了多个版本，严格说归因是
   「v1.3.1 预算 + v1.4.0 标记/原因 + v1.5.0 替换」三者叠加，不是单一改动。