缓存明细只报了第一轮，差额不计费；监控亮红灯，业务其实一直通 (2026)

这一小时四个仓库都没发新版本。CLIProxyAPI 还是 10-29 08:27（北京）发的 v8.0.47，sub2api 停在 v0.2.19，另两仓不动。1 2 3 4

所以今天没有能升的版本。进来的两张新单也不报错，它们是本地读数和真实情况对不上。

一处少收钱，一处白报警。两张都在 sub2api，都对 v0.2.19 的现行代码，都没有补丁。

一、记账只记了第一轮，差额那一截没人付

单子描述的场景不复杂。原生 /v1/messages 流式请求里，上游会在一趟请求内跑多轮采样，典型的是 web_search、web_fetch、code_execution 这些服务端工具。5

按官方文档，message_delta 里的用量是累计值。6 累计量往上涨是正常的。

问题在明细。总量涨了，嵌套的 5m/1h 明细却还停在第一轮。

代码里两个更新条件不对称。聚合值只要大于 0 就覆盖，明细只在 delta 真带了 cache_creation 对象时才动。7

`message_delta` 分支：第 1249 行按 `v > 0` 覆盖聚合值，第 1257 行起只有 `cache_creation` 是对象时才动 5m/1h。合成的两帧事件里，第二帧没有这个对象，明细因此留在第一轮。7

计费端接不住这个缺口。归一化只在明细之和超过聚合时按比例缩小，明细偏小时原样放过。8

`computeCacheCreationCost` 先做归一化再只加明细（第 1784 行与第 1789–1790 行）。`normalizeCacheCreationBreakdown` 的早退条件在第 1807 行：明细小于聚合时直接返回原值，不补差。8

用单子里的合成数字走一遍。第 1 轮写 3000、全是 5m，第 2 轮累计到 11000、明细不动。

计费按 3000 算，剩下 8000 白送。

还有一种更糟的：第 1 轮根本没写缓存。这时两个明细都是 0，代码会走兜底，整批按 5m 单价计。9

如果那批其实是 1 小时缓存，就按 5m 收了。以 claude-opus-5-5 为例，5m 是 5e-6、1h 是 8e-6，每 token 少收 37.5%。10

透传路径是同一套写法，message_delta 那段读法一模一样。11 所以两种接入方式都中。

谁中：Anthropic API Key 账号，入站和上游都是 /v1/messages，客户端在用服务端工具。

报障方在生产上观测到约 0.4% 的流式请求命中，非流式一条都没有。5

这个 0.4% 是对方口径，本刊没法复核。但方向可信：只有流式、只有服务端工具，正好对得上 delta 合并这一处。

代价落在运营方身上。上游按真实用量扣你的钱，你按少掉的用量向用户收，差额自己吃。

今晚能做的三步

第一步，先量。 用量表里聚合与明细是并排存的，相减就知道有没有中。12

SELECT count(*) AS rows_hit,
       sum(cache_creation_tokens - cache_creation_5m_tokens - cache_creation_1h_tokens) AS gap_tokens
FROM usage_logs
WHERE created_at >= now() - interval '24 hours'
  AND cache_creation_tokens > cache_creation_5m_tokens + cache_creation_1h_tokens;

聚合值就是计费读的那个字段。13 相减得到的是没计费的 token 数，不是概率。

第二步，别去开 TTL 覆盖。 那个开关拿明细之和重新分档，把 5m 全归 1h 或者反过来。14

它不看聚合值与明细之间的缺口。打开之后，少收会变成按另一档少收，缺口一点没动。

第三步，补差按天算，别按请求算。 单请求差额小、条数多，逐条补不现实。按天的 gap_tokens 乘单价补，是一次账务动作。

补丁状态：没有。 单子是今天 15:56（北京）开的，零评论，没有配套 PR。

反方向那张单还开着。同一条 message_delta 在显式上报 input_tokens=0 时沿用 message_start 的值，输入与缓存读重复计费，那是多收。15 它的补丁 PR #8408 还在评审。16

改这段合并逻辑时，两侧要一起看。多收和少收是同一个判断的两头。

二、监控亮红灯，可业务一直是通的

第二张单更常见。渠道监控用 V1 主动探活，provider 选 grok，卡片一直红，报错是上游回 400「仅支持 responses」。17

同一个账号的业务请求是正常的。客户端打 sub2api 的 /v1/chat/completions，由它自己转给上游。

探针把协议写死了。grok 的路径常量就是 /v1/chat/completions。18

适配器表与 grok 的执行器：第 172 行把 grok 指向 `providerGrokChatAdapter`，第 219 行它由 `newOpenAICompatibleChatAdapter(providerGrokPath)` 生成，路径在编译期就定死。19

选路函数也只给 OpenAI 开 responses。其余 provider 一律回落到 chat，ok 照样为真。20

校验这层直接拒。api_mode=responses 只允许 provider 为空或 openai。21

*`validateAPIMode`：responses 分支只在 provider 为空或 openai 时返回 nil，grok 走到第 100 行就是 `ErrChannelMonitorInvalidAPIMode`。21*

还有两处把口子堵死。更新监控时，非 openai 的 provider 会被强制回落 chat。22

前端更直接。api_mode 那段只在 provider 是 OpenAI 时渲染，选 grok 根本看不到这个开关。23

仓库里还有一条测试把这个行为钉住，方法名就叫「切到 grok 时拒绝 responses 模式」。24

所以这不是配置写错，是有意为之。

但同一个仓库对 grok 的用法是分裂的。账号检测里 grok 走的就是 responses。25

这就解释了业务通、监控红：监控层当它是只有 chat 的 provider，业务层知道它要 responses。

今晚怎么让它不红

别按红灯去停号。 这是这张单最实际的风险。红光来自探针协议，不是账号坏了。

停号、换号、清冷却都是白动作，还会把好号停掉、把正常流量挤到别的号上。

探针改个壳。 新建一条监控，provider 选 OpenAI，api_mode 选 responses，endpoint 与 key 填同一家，模型填同一个别名。

responses 那条适配器是通用的：路径写 /v1/responses，model 用你填的名字，鉴权是 Bearer。26

它跟 grok 没有关系。能不能通，取决于那家上游真的认 Responses 请求体。

代价是监控记录里 provider 显示 openai。名字不影响探活，只影响你自己看面板时的辨识。

别指望改完就有人修。 单是今天 16:40（北京）开的，零评论，没有配套 PR。

要去掉根因得动四处：路径常量、适配器表、校验、更新回落，外加前端那个 v-if。还要改掉那条钉住行为的测试。不是一行能改的事。

三、窗口其余

CLIProxyAPI PR #7102：维护者自提，4 文件 +77/−2，mergeable_state 为 clean，未合并。改动是 Home 模式下不注册 /v1/ws 那条 AI Studio 的 websocket 路由，同时把 Home 运行时的 websocket 鉴权从关改成开。27 跑 Home 模式又依赖本地 websocket 的，升级前先看这一条。

sub2api #8414：易支付回调二次确认让 BEpusdt 这类没有查单接口的网关不入账。28

这条本刊 10-18 午间那期按同一个函数、同一张 PR 写过，不再重复。新单只补了两条事实：v0.2.17、0.2.18、0.2.19 三版的 easypay.go 没有变化，回退 0.2.16 恢复入账。

四、版本与上游

四个仓库本窗口零发版。1 2 3 4

上游三个状态源都干净。OpenAI 全绿，Anthropic 全绿，Google Cloud 最近一条仍是 10-20 开的 Xs2XTHzAVC9YnafnPyzj，最后一条进展停在 10-27 23:13（北京）。29 30 31

额度侧今天 UTC 还没重置。最近一次已验证的全局重置是 10-28 14:35（北京），累计 61 次，手上 10 张 banked。32

社区侧本窗口没有额度或封号类新帖。OpenAI 开发者社区 Codex 分区最新一条是 14:18（北京）发的，落在线外。33

Reddit 上 r/ClaudeAI 与 r/OpenAI 窗口内各有几条新帖，都是套餐对比与模型体感，不是限额异常。34 35

References

1
CLIProxyAPI Releases
github.com
2
sub2api Releases
github.com
3
codex-proxy Releases
github.com
4
codex2api Releases
github.com
5
sub2api #8412
github.com
6
Anthropic 流式文档
platform.claude.com
7
gateway_upstream_response.go 第 1236–1272 行
github.com
8
billing_service.go 第 1779–1808 行
github.com
9
billing_service.go 第 1785–1787 行
github.com
10
billing_service.go 第 417–423 行
github.com
11
gateway_anthropic_passthrough.go 第 649–674 行
github.com
12
usage_log.go 第 150–156 行
github.com
13
gateway_usage_billing.go 第 1258–1267 行
github.com
14
gateway_upstream_response.go 第 1327–1335 行
github.com
15
sub2api #8407
github.com
16
sub2api PR #8408
github.com
17
sub2api #8413
github.com
18
channel_monitor_const.go 第 48–53 行
github.com
19
channel_monitor_checker.go 第 165–225 行
github.com
20
channel_monitor_checker.go 第 270–276 行
github.com
21
channel_monitor_validate.go 第 89–104 行
github.com
22
channel_monitor_service.go 第 981–988 行
github.com
23
MonitorFormDialog.vue 第 81 行
github.com
24
channel_monitor_service_grok_test.go 第 71–92 行
github.com
25
account_test_service.go 第 1042–1062 行
github.com
26
channel_monitor_checker.go 第 252–266 行
github.com
27
CLIProxyAPI PR #7102
github.com
28
sub2api #8414
github.com
29
OpenAI Status
status.openai.com
30
Claude Status
status.anthropic.com
31
Google Cloud Status
status.cloud.google.com
32
Codex Reset
codex-reset.com
33
OpenAI 开发者社区 Codex 分区
community.openai.com
34
r/ClaudeAI
reddit.com
35
r/OpenAI
reddit.com