二十一秒关掉十六张单，zstd 那行依赖还停在 v1.17.4
四仓今夜零新版本：十六张 CLIProxyAPI 缺陷单在二十一秒里被作者自己关成 not planned，其中一张是可以自己止血的 zstd 依赖；prompt block 让凭证逐个进冷却，cloaking 的日期钉在非原生客户端上每天午夜后失效。三件今晚就能落地的动作都写在文里。
这一小时四个仓库没有新版本，也没有新提交落到主干。真正的动作是一批撤单：北京 06:56:36 到 06:56:57，二十一秒里十六张单被关成 not planned，零评论、零解释。另有一张还开着，讲的是每天本地午夜后缓存会被整段重写。
一、二十一秒，十六张单
关单的是报障人自己。fredcamaral 在 10-17 到 10-25 之间陆续开出这十六张单，又在同一个半分钟里把它们全部关掉；他在仓库里的关联身份是 NONE，不是仓库成员。1
被关的是 #6696、#6702、#6713、#6948 到 #6958、#6964、#6965、#6966。其中前三张原本挂着 pending 标签，也一起关了；#6702 是唯一有评论的一张，两条。2
唯一没被关的是别人的单。#6963 由 aramalipoor 在北京 06:12 开出，仍 open、零评论。6
对运维的意思只有一句：这十六张不是修好关的，是关成 not planned 的。同一时段主干一个提交都没有。
二、撤掉的那叠里有一张漏洞，补丁没人接
但这个提交不在上游任何分支上。仓库的头只有
dev、main、legacy、feat/typesafe-triage、fix/claude-gemini-tool-result-errors 五条，没有一条指向它，也没有对应的 PR。10也就是说：修复存在，但没有任何人会把它带走。今晚要处理，只能自己做。
第一步，自己构建的：把那一行改到 v1.20.2 以上，
go mod tidy，重编。补丁本身就是这两处，不需要别的改动。第二步，用现成二进制的：在反向代理上拒掉
Content-Encoding 里带 zstd 的请求，代价是真用 zstd 的客户端会拿到 415。同时确认进程有自动重启——按报障人的分析，默认并发下 panic 落在解码器自己的 goroutine，gin 的 recover 接不住，进程会直接退出。该判断本刊未独立复现，但公告自己写明「任何解压不可信 zstd 输入的程序都能被它打崩」。7第三步，装了前端鉴权插件的：那条预鉴权解码只在这条路上存在。
decodeAuthBody 在第 35–68 行，调用点是第 237 行；不跑这类插件，这条路就不会被走到。11三、另一张今晚就能改配置：#6964
#6964 讲的是 Gemini 与 Vertex 的 prompt block。上游回
promptFeedback.blockReason、没有 candidates 时，执行器把这块当成一条普通错误抛出去：statusErr{code: 502}。六个站点里，流式那一处就在下面这张图里。312
CLIProxyAPI v8.0.42 的
internal/runtime/executor/gemini_executor.go 第 403–412 行：被上游拦下的 prompt，在这里只是一条普通 502，与凭证健康无关。它不是 request-scoped 错误，manager 于是把它当成凭证失败处理。后果两条：同一段被拦的 prompt 会在每张凭证上重试一遍（默认
max-retry-credentials: 0 就是全部），每试一次都重新计 prompt tokens；每张凭证被记一个 502，各自进入 60 秒瞬时冷却。3一个客户端触发安全拦截，可以让这个模型对所有人停一分钟，账单上还多出几次同样的输入。Vertex 的两条路（服务账号与 API key、非流式与流式）走的是同一套写法。13
判据在日志里：
auth cooldown: start ... status=502 reason="upstream blocked the prompt: SAFETY" in=1m0s。今晚的两个开关都在
routing 段：cooldown.transient-error-cooldown-seconds 改成 -1 关掉瞬时冷却（注释写明 0 = 保留 60 秒、-1 = 关闭），retry.max-retry-credentials 从 0 改成 1，把「每张都试」收窄。1415
CLIProxyAPI v8.0.42 的
config.example.yaml 第 198–222 行：三个开关的原文与默认值都在这一屏里，-1 的语义写在注释最后一行。代价说清楚：关掉瞬时冷却之后，真正的 502/503 也不再让凭证歇一分钟，会被继续打。上游本来就不稳的话，先收紧重试数，冷却留到确认是这条再关。
同一批里还有两张 duplex 重授权的单也一起关了：一张讲请求体被插件改过之后、后续轮次按上游模型而不是客户端别名重授权；一张讲重授权把身份写进可能被复用的 gin.Context。代码没动。16
四、还开着的那张：午夜一过，缓存整段重写
#6963 说的是 cloaking 的
currentDate 日期钉。钉子在，但键每次都不一样，所以钉不住。6机制是三处连起来的。未确认是原生 Claude Code 时，
ClaudeAgentSessionUUIDForRequest 先把 X-Claude-Code-Session-Id 从请求头里删掉。17
CLIProxyAPI v8.0.42 的
internal/runtime/executor/helps/claude_credential_identity.go 第 28–38 行：只有被确认的原生调用方，才会保留客户端带来的会话头。删掉之后，会话 ID 回落到
extractMessageHashIDs：取 system prompt 的前 100 个字符做键。18报障人给的三组数（
request-log: true，v8.0.42，本地午夜 22:00Z）：午夜前最后一调读到 518,284、422,080、390,601；午夜后第一次只读到 8,983、7,211，写 392,586、350,694、347,230。三次请求体只差计费头里的 cch。6对你的意义：cloaking 开着、客户端又不是原生 Claude Code，每天本地午夜后第一次调用就是「写满整段」的成本尖峰。按 token 转卖的话，这一下直接进成本。
能做的两条：可控的客户端别带那个计费头；或者对这类客户端关掉 cloaking（
upstream.claude.disable-claude-cloak-mode: true，代价是伪装没了）。session-date-pin-days 默认 7 天，它管的是钉多久，管不了键每次都变。20五、四仓版本：今夜没有下一版可等
| 仓库 | 当前版本 | 发布（北京） | 主干头 | 窗口内 |
|---|---|---|---|---|
| CLIProxyAPI | v8.0.42 21 | 10-24 22:21 | bc064340 | 16 张被关、4 张新开 |
| sub2api | v0.2.18 22 | 10-23 15:44 | 37067e8e（10-24 10:12） | 0 |
| codex-proxy | v2.1.20 23 | 10-23 03:56 | 0543eaa8（10-21 09:58） | 0 |
| codex2api | v3.1.1 24 | 10-17 05:42 | 1511374d（10-24 19:52） | 0 |
CLIProxyAPI 的 tag、
main、dev 与 HEAD 四个 ref 都还指着 bc0643405a1d，主干自北京 22:17 之后没动过。25 另外三仓窗口内既没有新版本也没有新提交。六、额度侧：两家追踪站对「最近一次重置」说法不同
codex-reset 的首页写得很直：今日 UTC 尚未重置，最近一次已验证全局重置是 10-22 17:10 UTC（北京 10-23 01:10），累计 57 次、10 次 banked、节奏约两天一次。26
opentherank 记的是另一条：最近一次「按预告落地，约太平洋时间 10:00（17:00 UTC），Tibo 未单独确认」，日期 10-23（北京 10-24 01:00），累计 66 次、中位 3 天、最长 68 天。27
差异的根源是口径，不是谁算错了：一家只登「已验证」，一家把按预告落地的也记进日历。所以别拿「最近一次重置」当自己账号窗口的起点——窗口锚在自己的第一个请求，答案在
/status 那一行。窗口内 Tibo 没有新的重置承诺。feed 的
newest_post_at 停在 22:44:22Z（北京 06:44），是一条闲聊回复；真正的 signal 仍是 10-22 06:55:54Z 那句「Lands tomorrow before 10am PST」，状态 pending。28社区这边四条，都只当信号看。r/ClaudeAI 有人拿 10 个账号测了 30 天每小时的消耗：Fable 5.1 在 5 小时与周额度上都是 Opus 5.5 的 5 倍，而 API 价目只有 205%；Sonnet 5.5 约 70% / 75%。单用户自测，样本是他自己的号。29
Google 官方开发者论坛的 Antigravity 分区里，有人问 T3 Code 这类第三方 ACP 客户端是否被 ToS 允许、担心封号；一楼、零回复，发帖人不是官方。32
三家状态页这一小时全绿。OpenAI 全绿，最近一次事件是 CIMD 连接问题，北京 10-24 07:43 结束；Anthropic 全绿，最近一次是 Fable 5/5.1 报错，北京 13:53 结束；Google Cloud 8 条，最新一条仍是 10-22 的 europe-west2 多产品故障。333435
今晚可以照着做的三步
- 先决定 zstd 这条怎么处理。 能重编就改
go.mod那一行重编；不能重编就在反代拒掉 zstd，并确认进程会自动拉起。装前端鉴权插件而用不上的，关掉。 - 再改冷却口径。
max-retry-credentials从 0 收到 1，transient-error-cooldown-seconds先留 0；日志里真的出现upstream blocked the prompt那一串，再改成 -1。 - 最后看 Claude 那条成本。 有非原生客户端在跑 cloaking 的，盯本地午夜后第一次调用的
cache_creation；能去掉计费头就去掉，去不掉就接受这个尖峰。
版本不用动。四个仓库今夜都没有下一版可等，主干也没有补丁。
References
- 1CLIProxyAPI #6955：已关成 not planned
github.com
- 2CLIProxyAPI #6702
github.com
- 3CLIProxyAPI #6964
github.com
- 4CLIProxyAPI #6965
github.com
- 5CLIProxyAPI #6966
github.com
- 6CLIProxyAPI #6963
github.com
- 7GHSA-fpmh-frq8-7rj8：zstd 两段帧 panic
github.com
- 8v8.0.42 的 go.mod 第 18 行
github.com
- 9main 的 go.mod 第 18 行
github.com
- 10
- 11pluginhost/adapters_auth.go 第 35–68 行
github.com
- 12gemini_executor.go 第 403–412 行
github.com
- 13gemini_vertex_executor.go 第 551–552 行
github.com
- 14config.example.yaml 第 198–222 行
github.com
- 15conductor_cooldown.go 第 109–124 行
github.com
- 16CLIProxyAPI #6952
github.com
- 17claude_credential_identity.go 第 28–38 行
github.com
- 18selector.go 第 1878–1897 行
github.com
- 19claude_executor_cloaking.go 第 150–166 行
github.com
- 20config.example.yaml 第 438–445 行
github.com
- 21Release v8.0.42
github.com
- 22Release 0.2.18
github.com
- 23Release v2.1.20
github.com
- 24Release v3.1.1
github.com
- 25CLIProxyAPI main 的提交记录
github.com
- 26codex-reset.com
codex-reset.com
- 27opentherank：Codex reset tracker
opentherank.com
- 28codex-reset 的 feed
codex-reset.com
- 29
- 30
- 31
- 32讨论区：T3 Code 是否被 Antigravity ToS 允许
discuss.ai.google.dev
- 33OpenAI Status
status.openai.com
- 34Claude Status
status.claude.com
- 35Google 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.