Token 统计逻辑

当前公网主口径：10 台 core 主机

wehubghygongqiangongqian-minigongqian-airoracledgx1dgx2dustinstudiozichao-mini

低优先级 / opt-in only：redherring。历史 scope 会写入 JSONL，用于解释曲线口径变化。

独立工具统计：三种来源，三种单位

这里的工具区是独立账本，不进入 10 台 core 主机的主曲线。当前 snapshot：2026-09-01T20:00:38+08:00。

覆盖边界：Cursor 是 account-level；Kimi Work 与 WorkBuddy 是当前 Mac only。只有来源覆盖稳定、能证明不会与主曲线或彼此重复时，才升级为团队累计并 bump accounting version。

主机与机器人 / agent 映射

采集流程

1. 定时任务运行 wehub_token_dashboard_refresh.sh。
2. collect_token_snapshot.py 调用 MVP collector，按 pinned host list 逐台 SSH。
3. 远端只执行 metadata reporter：扫描 ~/.hermes* / Hermes profiles 的 state.db、~/.openclaw* roots 的 usage metadata、~/.codex/sessions 的 direct Codex token metadata。
4. Codex CLI token_count 是累计电表读数，不直接相加每个 rollout 的最终值。collector 以 filename 的 primary session id 保持身份边界，再按 parent fork 时刻做 exact suffix-prefix 匹配，减去 child JSONL 中继承/replay 的历史，只累计各 rollout 的日内正向增量。
5. 跨午夜的 rollout 继续扫描：以当天零点前的最后累计状态为 baseline，把目标日内每个正向 delta 归入当天。
6. 生成 snapshots.jsonl；不可达主机按 0 填充并记录 provenance，再由 append_latest_total.py 写入 total_series.jsonl。zero-filled 点允许出现下降，因为它代表当前可达主机之和。
7. plot_total_series.py 生成曲线 PNG，generate_dashboard_html.py 生成主页面，随后部署到公网 origin。

Gross 与 non-cached 口径

• Gross processed token：provider/runtime 报出的总 token，用来表达模型今天处理过多少上下文量。
• Cached input：input token 中命中 prompt cache 的部分；它通常已经包含在 input/total 里，不是额外重复相加。
• Non-cached approximation：当前公网页面使用 max(total - cache_read, 0) 观察本地非缓存压力；它不等于 ChatGPT Profile 的未公开公式。
• 这不是精确账单折算；不同 provider/model 对 cache 的价格折扣不同。若要看账单，应以供应商后台为准。

重要教训：长线程不要无限 fork / resume 继续跑；同时，监控不能把 child rollout 复制的父线程 token history 当成新消耗。新版 collector 已按 lineage exact replay + daily delta 计数。详见 Codex Direct 与缓存 Token。

Codex 日内增量怎么算

每个 rollout 的 token_count.total_token_usage 是累计电表，不是一次调用量。新版先剔除 child rollout 从 parent replay 的历史前缀，再按时间顺序计算：

本次增量 = 当前累计值 − 上一次累计值

当天 Codex gross = Σ 当天各 rollout 的有效正增量

零点前最后一个累计值只作为当天 baseline；同一个累计状态重复写入时增量为 0。计数器回退、父 rollout 缺失或 replay 无法证明时，本轮 fail closed，不把可疑值写入公开曲线。

为什么不一定等于 ChatGPT Profile

• 本页主数字是 10 台 core 主机上 Codex、Hermes、OpenClaw 的本地实时 gross；ChatGPT Profile是单个 ChatGPT 账号的服务端日 bucket。日期、账号和 runtime 范围不同，不能直接比较。
• Profile 当天 bucket 可能延迟出现；比较时必须使用同一个完整日期，不能拿今天尚未结束的实时值对昨天完整值。
• OpenAI 公开了 account/usage/read 的 daily bucket 字段，但没有公开 cached、tool continuation、compaction 等事件的完整纳入公式，因此本地不使用校准系数强行对齐。

2026-07-16 同日核验：OpenAI 官方 bucket 为 778,480,181；本地完成 fork replay 去重后的 Codex gross 为 846,288,870。多出的 67,808,689 几乎全部来自 reasoning_output_tokens = 0 的 continuation / internal 类 token 事件；只看有 reasoning output 的调用为 778,363,147，与官方相差 117,034（约 0.015%）。这说明日内增量与 fork 去重基本正确，剩余差异主要是统计口径，而不是把累计值再次相加。

上述 reasoning 条件只是一次对账诊断，不作为生产公式。公网继续诚实展示本地 gross，并明确它不等于 Profile 或账单。

容错与部署逻辑

• 单台机器不可达：贡献按 0 填充，记录到 zero_filled_hosts，并进入公开时间序列让曲线继续更新。
• accounting quality 或解析失败：记录到 snapshot errors；该 snapshot 保留作诊断，但不进入公开时间序列。
• 统计脚本整体崩溃：本轮 refresh 失败，不追加错误样本。
• 干净样本的 gross total 或 non-cached/effective total 如果低于上一条有效点：视为非单调坏点，跳过并写入 rejected log；zero-filled 样本例外，因为它明确表示缺失主机被置 0。
• 公网部署同时尝试 dgx2 和 dgx1；至少一个成功即可。
• HTTP 200 不够，refresh 还会检查页面 marker：必须包含 WeHub Token Monitor 和 total_tokens_over_time，不能出现已知错误 artifact marker。

最新采集状态

最新样本没有采集错误，也没有 zero-filled 主机。

zero-filled 主机会进入曲线并带有明确标记；accounting quality / parse error 不会进入公开时间序列。

哪些不在当前统计里

这个 dashboard 是“本机可观测 agent token 消耗”，不是 provider/account 账单总额。ChatGPT 网页/App、未接入本地 metadata 的独立 CLI/IDE agent、供应商后台计费口径，都不自动进入这里。CausaClaw / DiscoSeed 作为 wehub 宿主上的正式 root/profile 进入 wehub 主机总量，并在快照中按 by_agent 给出 canonical agent 归属。