woodfood111/dsh-token-live

dsh-token-live

Awesome DSH Plugin

在 DeepSeek Harness 输入框下方常驻一行实时读数：草稿有多大、这个会话花了多少、上下文用了多少。

dsh-token-live 输入框下方的读数行

显示什么

| 读数 | 来源 | 什么时候变 |
| --- | --- | --- |
| 草稿 ≈ N tok · M 字 | 会话作用域的 input 钩子（InputState.draft） | 每次按键 |
| 花费 ¥0.42 · ¥1.8/时 | tokenUsage 投影 × DeepSeek 官方价目表 | 每次请求结算 |
| 对照 v4-pro ¥3.81 | 同一批分桶 × 另一个模型的单价 | 每次请求结算 |
| 上下文 已用 / 窗口 + 进度条 | contextPressure 投影 | provider 上报用量 |
| 会话 N tok · 命中 X% | tokenUsage 投影 | 每次请求结算 |

插件只往输入框 dock（conversation.composer.dock）里加一个条目，不替换自带的统计胶囊。

别人没有的那个读数

同样的用量，换成另一个模型要花多少。

对照 那个胶囊，用完全相同的 token 分桶——同样的缓存命中、同样的未命中、同样的输出——
按另一个更贵模型的单价、同一个计费时段算一遍。悬停会列出价目表里每个模型在你这个会话上的花费，
并标出当前用的是哪个。

为什么它值得占一栏：其它花费插件回答的都是"我花了多少"，而这个问题已经有十几个不错的答案。
选模型是另一个问题——"同样的活，贵的路线要花我多少"——而这恰恰是价目表存在的意义。
本次会话 flash 花了 ¥1.44，同样的 token 在 v4-pro 上会是 ¥3.81；这才是切换之前值得知道的数字，
而且用浏览器里已有的数据就能算出来，零成本。

对 awesome-dsh-plugin 的 Usage & Billing 分类 197 条描述做过一次扫描（2026-09-12）：
零条提供当前会话的跨模型反事实。有几条对比调价前后的列表价，没有一条拿你的用量跨模型对比。

只有在两个模型都有定价时才渲染；未定价的模型不显示对照，而不是编一个。

会话那个大数字，tooltip 会解释

会话 30.7M tok 摆在 327K 的上下文旁边看着吓人。它不是三千多万 token 的内容——
它是同一个上下文在每一步被重新发了一遍。会话胶囊的 tooltip 会说明这一点：
把累计计费输入除以最近一次 provider 上报的提示词大小——"累计计费输入 ≈ 94 倍当前上下文"。
197 条里只有一条说了类似的话。

安装

dsh plugin --profile web add dsh-token-live

装完刷新页面。客户端 bundle 变化会自动重载；服务器端的插件行需要插件树重新组合，profile 的 patchReload: live 保存即生效，否则重启一次 dsh web。

草稿计数器才是重点

harness 的 token 数字都是"事后"的。有两件事它完全不提供：

- 输入框里现在有多少。 流式过程中客户端 PartialAccumulator.push() 对 usage 分片直接返回 false，所以过程中根本没有任何实时 token 数字到达界面。
- 这要花多少钱。 harness 里没有任何金额数据——dsh-token-meter 的 "pricing" 是图片 token 计价，与计费无关。

harness 自身固定按每 4 字符 1 token 估算（dsh-token-meter 的 CHARS_PER_TOKEN），对中文低估 2–3 倍。所以这里的草稿估算对密集文字单独加权：中日韩文字/假名/谚文/全角约 0.7 token/字，其余约 4 字符/token。

计价口径

官方价目，元每百万 token，按高峰时段列
（来源，2026-09-10 生效）：

| 模型 | 缓存命中输入 | 缓存未命中输入 | 输出 |
| --- | --- | --- | --- |
| deepseek-flash | 0.04 | 2 | 8 |
| deepseek-v4-pro | 0.30 | 9 | 27 |

空闲时段恰好是高峰的一半。 高峰为北京时间（UTC+8）周一至周五 09:00–12:00 与 14:00–18:00，其余空闲。时段由墙上时钟算出，与浏览器所在时区无关。

细节：

- 模型取自 modelSelection 投影的 lastUsed——真正产生这些用量的模型，不是 next。
- 缓存写入按未命中计价，因为前缀第一次发送本来就是未命中。
- 模型不在表里时显示 未定价，不猜数字。错的金额比没有金额更糟。
- 累计用量按当前时段统一计价，因此跨时段的长会话最多有 2× 误差（tooltip 里写明了）。
- ¥/时 是本页观察值（最多回看 15 分钟），刷新即清零。
- 价格会变。价目表是 lib/client.js 里的一个常量，旁边写着来源与生效日期。

设计：这个插件没有 host 半

全部逻辑都在一个浏览器 bundle 里。lib/index.js 是个空 Cordis 插件，存在的唯一理由是让 loader 那一行有东西可解析——它不注入任何服务、不持有状态、不注册路由、不写文件、不发网络请求。

由此得到一个值得明说的结果：这个插件永远不会读你的 API key。 它做不到，因为它没有 host 半可以去读，也没有地方可以送出去。它只读四样客户端可见的东西——三个投影加输入框草稿。

这是刻意的选择，不是为了极简而极简。在开发时所用的 harness 版本（0.1.5-rc.1）上，插件注册到 web server 的路由不在会话 cookie 的鉴权墙后面：裸请求 GET /dsh-market/installed 不带任何 cookie 就返回 200，而 / 与 /api/ 返回 401。所以一个在 host 端取余额、再用自己的路由吐出来的插件，等于把那个响应暴露给任何能访问该端口的本地进程——如果服务绑定范围被放宽，暴露面还会更大。没有 host 半，这一整类暴露就不存在。

如果你确实要账户余额，也接受"host 端持有你的密钥"，awesome-dsh-plugin 列表里有很多插件正是这么做的。这个插件刻意不做。

精度与限制

- 草稿是估算；花费、上下文、会话三项不是。
- 草稿估算对符号密集内容（代码、JSON）偏高，对散文最准。它是发送前的量级参考，不是计费值。
- provider 尚未为该会话上报用量前，上下文一项不显示。
- 不显示生成过程中的实时产出 token。 要诚实地做到这一点，需要改 dsh-client-ui-chat 里按设计丢弃 usage 分片的流式路径。

开发

npm test       # 离线测试：估算口径、价目表、时段判定、渲染、插槽注册
npm run check  # 发布守卫，npm publish 会自动跑

npm test 用桩 window.__ModuleLoader__ 与桩 react 直接跑真实的 lib/client.js，不需要浏览器、不需要装 DSH。它固定住：

- CJK 加权估算口径，包括它与 harness 自身口径的差异
- 价目表，以及时段边界的每一个点（08:59、09:00、11:59、12:00、13:00、14:00、18:00、周末）
- 反事实对照：选哪个模型作对照、别名先解析再选、未定价模型不渲染对照
- provider 还没上报过提示词大小时，重读倍数会被省略，而不是除以零
- 部分缓存命中永远不会被进位成 100%
- 未定价的模型会明说"未定价"，而不是编一个数字

浏览器 bundle 是按客户端模块格式（window.__ModuleLoader__.load）手写的，因此没有构建步骤：仓库里的 lib/client.js 就是发布出去、也是实际运行的那个文件。

许可证

MIT