插件流式用量把缓存算了两遍、思考减了两遍；Codex 重置承诺到点未落地
CLIProxyAPI 的插件执行器在 interactions 流式输出下合并用量时，把缓存读算进两次输入、把思考从输出里再减一次，结果仍标 quality complete；本期给出偏差算例、代码位置、四步自查与今日处置，并报 Codex 重置承诺到点仍未落地的现状。
插件执行器合并流式用量时，把同一份数字算了两遍。缓存读先算进输入合计，随后又当作额外项加了一次；思考数则从本来就不含它的输出里再减一次。
CLIProxyAPI 最新发行版 v8.0.40 里，这段逻辑原样在跑，main 与 dev 的同名文件逐字节相同。报障单在北京 10-24 00:54 开出，到发稿仍零评论1。
真正受影响的只有一条路：插件执行器（第三方插件提供的执行器）走流式，且声明输出格式为 interactions 或 interactions-response。
请求本身照常跑通，错的是事后记下来的那笔账。
非流式不经过合并。claude、gemini、codex 三条流式路径各有各的计数口径，数字不变。
三个数被改成了什么样
报障人给的两份累计快照很干净：初始 100 输入 / 20 缓存读 / 0 输出，最终 100 / 20 / 30 输出 / 10 思考 / 总数 1401。
| 字段 | 只解析最终快照 | 合并两份快照之后 |
|---|---|---|
| 输入合计 | 100 | 120 |
| 未缓存输入 | 80 | 100 |
| 缓存读 | 20 | 20 |
| 输出合计 | 40 | 30 |
| 非思考输出 | 30 | 20 |
| 思考 | 10 | 10 |
| 总数 | 140 | 150 |
| quality | complete | complete |
净变化是输入多 20、输出少 10、总数多 10。20 正好是缓存读那一项，10 正好是思考那一项。
中转站拿这些数做成本核算和额度告警。输入偏高会让单请求看起来更贵，输出偏低会让思考型模型的用量看起来更省。
按 v8.0.40 的两个构造器重算一遍，读数与报障单一致。
错在两套计数口径被混用
interactions 的 usage 里，input_tokens 含缓存读，output_tokens 不含思考。解析函数把这两个值交给 NewSeparateReasoningTokenBreakdown2。
那个构造器的注释写明：它服务「缓存含在输入总量里、思考与普通输出分开」的协议3。
合并函数走的是另一套。MergeStreamUsageDetail 先用新快照覆盖旧快照，再把缓存读与缓存写加总成 cached，总数按 InputTokens + OutputTokens + cached 重算4。
最后它一律用 NewIndependentTokenBreakdown 重建 breakdown，而那个构造器服务「未缓存输入、缓存读、缓存写各自独立」的协议5。
于是含缓存的输入被当成未缓存值，又叠了一次缓存；已经不含思考的输出，又被减了一次思考。
调用链是这样走的：插件执行器逐行把数据交给 ObservePluginExecutorStreamUsage，interactions 分支进 ObserveMergedStreamUsage，再到 MergeStreamUsageDetail6。
claude 这条路没有中招。它的解析本来就用独立口径，input_tokens 与 cache 分开、output_tokens 含 thinking，与合并侧一致7。
gemini 与 codex 走 buffer.Observe，根本不过合并。
quality 为什么仍报 complete
合并结束会重算总数并重建 breakdown。校验只看 breakdown 内部是否自洽：120 加 30 等于 150，与写进去的总数一致。
两边的加法都没错，变的是这部分用量按哪种数法记。quality 与 Valid() 查的是自洽性，所以两个字段都放行。
今天先做这四步
- 列出装了哪些插件执行器，看各自声明的 output_formats 里有没有 interactions 或 interactions-response。
- 找一条这类流式请求，从响应里取两条带 usage 的累计快照。
- 只按最终快照重算，看输入合计与输出合计相加，是否回到总数那一档。
- 与用量接口里的记录比对，差额应落在缓存读（输入偏大）与思考（输出偏小）两项上。
处置：升级解决不了
v8.0.40 的 plugin_executor_usage.go 与 main、dev 三个 ref 逐字节相同。开放 PR 列表里最新编号 6924 是 auto mode 的测试补充，没有针对这处的修复8。
两条临时办法可以今天就做：这类插件执行器先停用流式；对账时用原始快照重算，别拿面板上的 token 数当结算依据。
若要动插件侧，把输出格式改成 claude 或 openai-response 也能绕开。这两条路的解析口径与合并侧一致，代价是插件要改一层翻译。
Codex 重置：到点未落地
@thsottiaux 在北京 10-23 12:47 写道：Landing tomorrow before 10am PST together with a small ship9。
10am PT 换算成北京 10-24 01:00，10 月太平洋时区仍是 PDT（UTC−7）；按字面 PST（UTC−8）读，则是北京 02:00。
截至北京 01:15，第一种读法已过点 15 分钟，第二种还差 45 分钟。
北京 01:15 查到的 codex-reset 首页仍写 not so far today (UTC)。最近一次已验证的全局重置是北京 10-23 01:10，累计 57 次全局重置、10 次 banked、节奏约每两天10。
radar 里那条预告还挂着，标着 no official reset signal。feed 里 10-23 的两条事件状态仍是 pending。
上一次同一措辞（10-22 06:55 UTC 那条）在 17:10 UTC 落地成已验证的全局重置，比当天的 10am PT 晚约十分钟。
另一家第三方记的是 65 次、中位间隔 3 天、最长 68 天。两家的计数口径不同，都只能当参考11。
判据：今天先别按预告排班。看
/status 的窗口是否真的归零，或 codex-reset 把事件从 pending 改成已验证。窗口内其余状态
sub2api #7797（缓冲截断那条）状态未变：open、mergeable clean、无评审、窗口内无新提交16。大单 #7704 仍 open。
上游全绿：status.openai.com 全组件 operational，无进行中事件；status.anthropic.com 全绿；GCP 最近一条仍是 10-22 的 europe-west2171819。
References
- 1CLIProxyAPI issue 6925
github.com
- 2usage_helpers.go 第 1294–1334 行
github.com
- 3usage/accounting.go
github.com
- 4plugin_executor_usage.go 第 163–207 行
github.com
- 5usage/accounting.go
github.com
- 6
- 7usage_helpers.go 第 1178–1250 行
github.com
- 8CLIProxyAPI 开放 PR 列表
github.com
- 9@thsottiaux 的推文
x.com
- 10codex-reset 首页
codex-reset.com
- 11opentherank 的 Codex 重置统计
opentherank.com
- 12CLIProxyAPI releases
github.com
- 13sub2api releases
github.com
- 14codex-proxy releases
github.com
- 15codex2api releases
github.com
- 16sub2api PR 7797
github.com
- 17OpenAI Status
status.openai.com
- 18Anthropic Status
status.anthropic.com
- 19Google Cloud Status
status.cloud.google.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.