10/18 深夜速报：死锁那张补丁提交了还没并；sub2api 有人把两类计费漏洞连库表数字一起交上来
这一小时四仓都没有新版本：上一期那条会让整站冻住的死锁有了第一张还没合并的补丁，OpenAI→Claude 翻译每块重读整份请求被 pprof 量到 56% CPU，sub2api 上有人交了两类计费漏洞的库表证据。
10 月 18 日北京 22:10 到 23:15 这 65 分钟里，四个仓库都没有新版本：CLIProxyAPI 停在 v8.0.33，sub2api 停在 v0.2.17，codex-proxy 停在 v2.1.18，codex2api 停在 v3.1.11234。
事情不少。上一期那条会让整站冻住的死锁（
#6744）等来了第一张修复补丁；一起新报障把「OpenAI→Claude 翻译每块重读整份请求」的 CPU 开销量到了 pprof 上；sub2api 上有人交了一份带库表数字的两类计费漏洞报告。分支头上，CLIProxyAPI 的 main 停在 21:05 的 v8.0.33 提交，dev 在窗口内走了两笔，最后一笔是 23:00:3256。sub2api 的 main 停在 10 月 16 日 12:42，codex2api 停在 10 月 17 日 05:35，codex-proxy 的 dev 停在 18:46789。
今晚可以先做这四件事
- 装了「提供调度器能力」的插件、又跑在高峰流量上的：今晚别保存插件配置、别热加载插件目录。这是那处死锁唯一还开着的触发面，补丁到本文发稿时还没并进任何分支。
- 用 sub2api 的：查一遍零成本账单。
usage_logs里actual_cost = 0且 tokens 大于 0 的行，按模型分组数一遍。 - 让 Claude Code 打 OpenAI 兼容上游的：抓一次 pprof，看
gjson.parseSquash的占比。请求体几百 KB 时，首 token 会被这一行拖慢。 - 这三件都与你无关的部署，这一小时只需要知道一件事：没有版本要升。
整站冻死那张单等来了补丁，还没并
#6748 是上一期那条死锁的第一张修复补丁，创建于 23:04:17，落在本文窗口的末尾10。它对着 dev 开，4 个文件、+166/−18、1 提交，mergeable 是 clean，两条评论都来自仓库机器人。问题本身上一期讲过：选号时
Manager.mu 在外面、插件在里层被调用；保存插件配置时 Host.mu 在外面、RegisterExecutor 在里层被调用。两个方向撞上，就是 ABBA。补丁改了两处。第一处是
PluginSchedulerWantsAcrossPriorities：先在 m.mu.RLock() 下把 m.pluginScheduler 取出来，放了锁再调插件的 SchedulerWantsAcrossPriorities。原来那个带 Locked 后缀、握着锁调插件的函数被整个删掉；availableAuthsForSelector 多了一个 schedulerAcross bool 参数，由 pickNextLegacy 与 pickNextMixedLegacy 在取锁之前算好11。
CLIProxyAPI v8.0.33 的 internal/pluginhost/adapters_executors.go 第 176–198 行：第 186 行注册执行器、第 193 行注销执行器，第 195 行才 h.mu.Unlock()。补丁把这一行提到两个循环之前。12把锁提前放，最容易引入的新毛病是锁外读共享状态。这一段我核过：解锁之后，代码只用
registrations、staleProviders、nextModelClients 三个局部变量；ownsExecutor 只做类型断言与指针比较，不碰共享 map；模型注册本来就在锁外。这一处改得干净。作者在说明里写：两个新测试在旧代码上失败、在新代码上通过，
go test -race ./... 2290 项全过，gofmt 与 go build 都跑过，改动借了 AI 助手、由他本人复核。这几条是作者自述，本刊没有独立复跑10。风险面值得再确认一次：只有装了「提供调度器能力」的插件，
PluginSchedulerWantsAcrossPriorities 才会走进插件的代码。没有这类插件的部署，两处改动都碰不到它。补丁现在还开着，
#6744 也还开着13。今晚能做的只有规避：高峰时段别触发插件能力重载，或者临时停用带调度器的插件。想彻底解决，就得自己把这一笔打到源码上编译，或者等它并进 dev、再等下一个版本。OpenAI→Claude 的翻译每块重读一遍整份请求
第二件事在另一条路上。
#6746 报的是：Claude 格式的客户端走 OpenAI 兼容上游时，ConvertOpenAIResponseToClaude 对每一个流式分块都执行一次 gjson.GetBytes(originalRequestRawJSON, "stream")14。v8.0.33 里这一行在第 143 行。同一个函数上一段的
ToolNameMap 是每流只算一次的15。
CLIProxyAPI v8.0.33 的 internal/translator/openai/claude/openai_claude_response.go 第 136–152 行：第 143 行每次调用都从原始请求里取 stream，第 144 到 147 行据此分派。补丁要做的事，就是把这次取值挪成每流一次。15这一行为什么贵：Claude Code 的请求体带整套 tools 与历史，几百 KB 很常见，而
stream 这个键通常放在 JSON 末尾。gjson 要读到它，就得扫过整份 body，分块越多扫得越多。报障人在 2 vCPU、1 GB 内存的机器上抓了两次 12 到 14 秒的样本，
gjson.parseSquash 的 flat 占比分别是 56.5% 与 77.5%，进程 CPU 约 190%，当时只有几个会话在流式输出14。微基准是这条里最硬的数字：约 300 KB 的原始请求、
stream 放在最后一个键，每块从 104–110 微秒降到 5–6 微秒。端到端那张表要打折。报障人 22:46 自己贴了更正：初版「首 token 46 秒降到 24 秒」的测量客户端每个请求都新建 SSL context，约 0.8 秒 CPU 且被 GIL 串行，绝对值作废。他重测后给的是 8 并发、191 KB 请求体下首 token 从 13.4/20.0 秒降到 5.1/6.9 秒，聚合吞吐从 207/193 tok/s 升到 348/342 tok/s，每输出 token 的中转 CPU 从约 7.2 ms 降到约 2.3 ms；同一台机器还在跑线上流量，他让读者按参考值看14。
参考实现是
#6747：给 per-stream 参数加两个字段，streamResolved 与 streamRequested，第一块解析一次、之后复用；语义保持不变，缺 stream 或 stream: false 走非流式16。作者自己在说明里写清了：改动只碰
internal/translator/，仓库的 translator-path-guard 会把它拦下，按 AGENTS.md 要先开 issue，所以这张 PR 交给维护者裁量16。它短期内不会随版本发出来。今晚能做三件：抓 pprof 看
gjson.parseSquash 的占比；给请求瘦身（少挂 tools、截短历史）能直接压低每块的代价；或者把 Claude 格式的客户端直接指向原生 Anthropic 上游，绕开这层翻译。sub2api 的两类计费漏洞：一类在源码里核到了，一类核出来是另一个样子
#8202 也是这个窗口里开出的，22:59 创建，作者贴了库表数字与容器日志，声明 B 型已在本地复现，并按负责任披露的方式只给路径、不给脚本17。A 型：模型没配价格，请求照过、账照记 0。 这条在 v0.2.17 源码里能逐处对上。
预占阶段，价格算不出来就打一句
request admitted without reservation (fail-open, throttled log)，然后放行18。定价查不到时，底层返回的是 pricing not found19。结算阶段，
isUsagePricingUnavailableError 命中就打 warn 一句 openai_usage.pricing_missing_record_zero_cost，然后把 cost 换成一个零成本的结构体20。
sub2api v0.2.17 的 backend/internal/service/openai_gateway_usage.go 第 250–272 行：第 257 行只对「定价不可用」放行，别的错误照旧返回；第 268 行打 warn，第 269 行把成本换成零成本结构体。20代价落在账单上：tokens 照记，钱不记。报告人数的是
qwen3-235b-a22b-instruct 3769 条、deepseek-ai/DeepSeek-V3.2 388 条零成本记录，这两组数字来自他的实例，本刊没有独立复现17。今晚可以自查三件。第一，按模型分组数
usage_logs 里 actual_cost = 0 且 tokens 大于 0 的行。第二，日志里搜 pricing_missing_record_zero_cost 与 inflight reservation cannot price model 两个 key。第三，把用到的模型价补齐：pricing.override_file 是覆盖文件、优先级最高，pricing.fallback_file 只补目录里缺的模型，两个都按内容哈希在下一次检查时自动重载21。B 型：流式请求中途删 key，结算整笔跳过。 这条我在 v0.2.17 上核出来的样子与报告不同。
结算事务里，余额扣减排在最前面，扣完才处理 key 自身的额度与限速计数。
ErrAPIKeyNotFound 在那两处被显式放过，注释写的是「Key 已不存在时跳过其自身的额度/限速计数，其余结算项不受影响」22。
sub2api v0.2.17 的 backend/internal/repository/usage_billing_repo.go 第 186–206 行：第 186 行先落下新的余额，第 190 行的注释说明 key 不存在时只跳过 key 自身的计数，第 193 与 200 行把 ErrAPIKeyNotFound 排除在失败之外。22余额扣减本身允许透支：先按
balance >= $1 更新，没命中时去掉这个条件再更新一次，返回 sufficient = false，调用方把它记成 BalanceOverdrafted23。这解释了报告人看到的余额变成负数。结算整体失败时，代码把
usageLog.ActualCost 置 0，再 best-effort 落一条用量日志，然后把错误交回调用方；调用方只把它打成 openai.record_usage_failed2425。这条路径在库里留下的是一行 0 成本的记录。所以 B 型要成立，得先确定是哪条结算分支失败。报告人跑的是
latest 镜像，本刊核的是 v0.2.17 标签，两者可能不是同一份代码。要做自查，就把他那 763 条 API_KEY_NOT_FOUND 的时间窗取出来，对一遍同一时段 usage_logs 里的实际 cost：有行但钱是 0，和整行都没有，是两种不同的漏法，处置也不一样。报告人另外列的三条，我在代码里都找到了对应：余额能扣成负数、Redis 里的余额快照与数据库脱节、软删后的 key 在鉴权缓存失效前仍能调用。第一条是上面那个显式回退的结果，后两条属于对账与鉴权的时序问题。
次条：sub2api 开了「托管网页搜索账号」的路由
#8200 在 22:21 开出，15 个文件、+523/−5、1 提交、mergeable unstable，对着 main26。它做的事：
/v1/messages 上只带一个 web_search_20250305 工具的纯搜索轮次，改由一个能原生跑搜索的账号执行。账号打上 extra.web_search_capable 标记即可入选；全局配了 managed_account_id 时，那个账号优先。请求按原生 Anthropic 协议透传，web_search_tool_result 结构原样保留；用量按 server_tool_use(name=web_search) 计次，走既有的每次价格字段。对运维要看的是成本与额度：合入并启用后，纯搜索轮次不再消耗主池里那些账号的额度，改由被标记的账号单独承担，账单里会多出一档按次计费的搜索项。这条现在是 PR，未合并、未发版，今晚不用动配置。
已经进主干、还没发版的两笔
窗口内 dev 动了两笔，落在 22:37 到 23:00 之间，都关掉了一张早前报过的单。
c558d3203e 让 Gemini 清洗器先展开本地 $ref 再删定义容器，并且保住 default、example、examples、const、enum 里的字面量，关掉 #6732；那三处清洗问题本刊在 10 月 18 日午间那期登过27。两笔都只在 dev。v8.0.33 是 21:05 的提交，不含它们。
上游与额度
OpenAI 全绿、活动事件 029。最近三条已解决的是 10 月 14 日 Compliance API 成本数据延迟（10 月 16 日 18:44 北京解决）、10 月 15 日的大范围功能降级、10 月 14 日两个图像模型的可用性30。
Codex 侧今天 UTC 还没重置：最近一次已验证的全局重置在北京时间 10 月 18 日 04:41，约 18 小时前；累计 55 次全局、10 次 banked，节奏约每 3 天，当前没有官方重置信号33。
官方开发者社区 Codex 分区窗口内两条新话题：一条 23:02 的长任务不满，一条 22:15 的功能请求，讨论的都是使用体验34。
未闭合
#6744 会不会被这张补丁关掉、维护者会不会要作者改方向；#6746 里报障人提到的「其他 translator 也在每块读请求」有没有第二处同样的放大；#8202 的 B 型能不能被维护方复现出来；#8200 合入后搜索计次与主池额度怎么分摊；#6732、#6733 两笔随哪一版发出。References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI dev 提交时间轴
github.com
- 6CLIProxyAPI main 提交时间轴
github.com
- 7sub2api main 提交时间轴
github.com
- 8codex2api main 提交时间轴
github.com
- 9codex-proxy dev 提交时间轴
github.com
- 10CLIProxyAPI PR #6748
github.com
- 11PR #6748 全量补丁
patch-diff.githubusercontent.com
- 12
- 13CLIProxyAPI issue #6744
github.com
- 14CLIProxyAPI issue #6746
github.com
- 15
- 16CLIProxyAPI PR #6747
github.com
- 17sub2api issue #8202
github.com
- 18
- 19v0.2.17 billing_service.go 第 1605–1615 行
github.com
- 20
- 21
- 22
- 23
- 24
- 25
- 26sub2api PR #8200
github.com
- 27CLIProxyAPI dev 提交 c558d3203e
github.com
- 28CLIProxyAPI dev 提交 d69962e40c
github.com
- 29status.openai.com summary
status.openai.com
- 30status.openai.com incidents
status.openai.com
- 31Anthropic Status
status.anthropic.com
- 32Google Cloud Status incidents
status.cloud.google.com
- 33codex-reset.com
codex-reset.com
- 34OpenAI 开发者社区 · Codex 分区 RSS
community.openai.com
- 35r/OpenAI
reddit.com
- 36r/GeminiAI
reddit.com
- 37r/ClaudeAI
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.