zh667/TokenLedger

README 摘要

TokenLedger 🚧 早期开发中 ：已作为 DSH 插件在真实 DSH 中跑通全链路；Web UI 页面尚未完成，也未发布 npm。 ⚠️ 非官方声明 ：TokenLedger 是独立的第三方社区项目，与 DeepSeek 无隶属、赞助或背书关系。「DeepSeek」及相关商标归其权利人所有。 统计 DeepSeek Harness 的 Token 消耗，并和 New API、Sub2API 中转站的实际扣费对账。 用量统计本身在 DSH 生态里已经有几十个实现。TokenLedger 存在的理由是它们都缺的那一半： 你的用量记录里没有「这笔钱花在哪个中转站」，所以永远对不上中转站的账单。 它解决什么问题 你在两个中转站买了 deepseek-v4 的额度。月底一个站说你花了 ¥47，另一个说 ¥89。你手里有 DSH 的会话日志，但日志里只有 provider 路由名和模型名，没有站点身份——你无法回答「这 ¥89 里有多少是我真的发出去的请求」。 TokenLedger 把 (中转站, Provider, 模型) 作为一等维度记录下来，再去读两个站自己的账单 API，把两边并排放，并 明确标注这次比对的证据等级 ： 等级 含义 request 有共享的请求标识，能一一对应 aggregate 按站点、模型、时间窗聚合比对 summary 站点只暴露累计额度/余额，无法细分 只有汇总数据时，界面不会假装是 request 级。估算费用、站点扣费、钱包余额、内部额度单位是四种不同的事实，永远不会被静默相加或换算。 现在能用的部分 三个别人会做错的地方 这三条都有测试覆盖（ test/usage.test.js ），也是照抄现成实现时最容易漏的： 1. 请求失败了照样扣费。 用量除了挂在 assistant/message 上，也会从 assistant/chunk 的 {type:'usage'} 流出。请求在报出 usage 之后失败，就永远等不到 assistant/message ——但供应商已经收钱了。只订阅 assistant/message 会系统性少算这部分，而这恰恰是账单看起来偏高时最需要解释的部分。 2. 同一个 (turn, step) 会被报告两次。 后来的样本是 替换 前一个，不是累加。而且替换时必须从 原先归属的那一天和那条路由 里减回去——跨天、跨增量折叠边界时尤其容易错。 3. 孤儿 usage chunk 不带任何身份。 assistant/message 在 message.source 里自带 provider 和 model，但 StreamChunk 的 usage 变体只有 {type:'usage', usage} 。所以失败请求的那条记录必须回退到最近一次 request/header 归因，且要认得 r…

分类