10/19 凌晨速报：凭证在自己写盘的那几毫秒里会被注销；Claude 请求在首 token 前要先整份分词 (2026)

10 月 18 日北京 23:11 到 10 月 19 日 00:15 这 64 分钟里，四个仓库都没有新的稳定版：CLIProxyAPI 停在 v8.0.33，sub2api 停在 v0.2.17，codex-proxy 的稳定版停在 v2.1.18，codex2api 停在 v3.1.11 2 3 4。

codex-proxy 在 23:37 推了一个预发布版。说明写着八条修复，代码里没有新增。

分支头上，CLIProxyAPI 的 main 停在 21:05 的 v8.0.33 提交，dev 在 00:03 落了一笔，正是下面那处凭证保护的修复5 6。

另外三个仓库没动：sub2api 的 main 停在 10 月 16 日 12:42，codex2api 停在 10 月 17 日 05:35，codex-proxy 的 dev 停在 18:467 8 9。

今晚可以先做这四件事

用 CLIProxyAPI 的：今晚别在流量高峰从面板改凭证字段或上传凭证文件。文件被就地重写的那几毫秒里，扫描会把它读成空文件，随后注销这条凭证。修复只在 dev，v8.0.33 没有。
让 Claude Code 打非 Claude 上游的：抓一次 pprof，看 countClaudeInputTokens 的占比。200 KB 的请求一次要吃 0.45 到 1 秒 CPU，而且花在首 token 之前。
用 codex-proxy 的：这个预发布版可以跳过。它相对 v2.1.18 改的是发布流水线与更新日志。
用 sub2api 的：上期那张 P0 计费单已被报障人自己关掉，账单自查照旧。

凭证在自己被写的那几毫秒里会被扫掉

#6734 是 10 月 18 日上午 10:14 开出的单，讲的正是这件事，单据到现在还开着10。

链路有四步。第一步，写凭证的三处都是就地写：FileTokenStore.Save 用 O_WRONLY|O_TRUNC 截断再写，管理端改字段与上传凭证文件都走 os.WriteFile10。

第二步，扫描读到空文件或半截 JSON 就跳过：空读取被 len(data) == 0 挡掉，解析不出来的文件返回 0 条 auth。

第三步，对账时凡是「本次扫描里没出现」的 id，一律生成一条删除，而且不带 auth 字段11。

v8.0.33 里缺一个 id 就补一条删除 — `CLIProxyAPI` v8.0.33 的 `internal/watcher/dispatcher.go` 第 207–212 行：第 209 行遍历当前凭证，第 210 行判断新状态里有没有这个 id，第 211 行补一条不带 auth 的删除。上面两行注释承认「全量扫描里缺一个 id，不等于源文件被删了」。11

第四步，服务端照单执行。它的 stale-generation 守卫要看 update.Auth，而这条删除没带 auth，守卫拦不住10。

结果是凭证短暂消失，直到写入方自己那条文件事件到达才被加回来。这也是「凭证莫名掉一下又自己回来」的一个可能来源。

修复是 dev 上的 7484a5216a：作者 Luis Pater，提交时间 00:03:26，8 个文件、+700/−86，提交信息里写着 Closes: #673412。

改法两步。扫描时先判 json.Valid，解析不了的路径放进 incompleteRescanPaths，不参与本次对账；扫描结束、拿锁之后，再把这些路径上一轮的文件哈希、解析结果与 auth 索引原样补回去13。

读到不完整文件时保留上一轮索引 — *dev 提交 `7484a5216a` 的 `internal/watcher/clients.go` 第 115–121 行判出不完整文件，第 149–160 行把它上一轮的哈希、内容与 auth 集合补回本轮结果。13*

v8.0.33 里没有这段：那一版整份 clients.go 搜不到 incompleteRescanPaths14。今晚想拿到它，只有自己把这一笔打到源码上编译，或者等它并进 main 再发版。

Claude 格式请求在首 token 前要整份分词

#6750 在 23:31 开出，报的是 Claude 格式客户端走非 Claude 上游时的一笔固定开销15。

ClaudeInputTokenState 要给 message_start.usage.input_tokens 一个估算值。它的做法是把整份原始请求（system、messages、tools）用 O200kBase 分词器算一遍，而且在第一个事件转发给客户端之前同步算完。

v8.0.33 里这一行在第 111 行：enc.Count(strings.Join(segments, "\n"))16。

整份请求拼成一段再分词 — `CLIProxyAPI` v8.0.33 的 `internal/runtime/executor/helps/claude_input_tokens.go` 第 100–115 行：第 111 行把 system、messages、tools 拼成一整段交给分词器，第 115 行把结果当 input_tokens 返回。16

成本数字来自 pprof：25 秒窗口里，countClaudeInputTokens 占全部 CPU 样本的 46%（4.18 秒中的 1.94 秒），几乎全落在 tiktoken-go/tokenizer 的 Codec.Count 与 regexp2 的 FindNextMatch15。

单次调用的墙钟时间：50 KB 用 0.13–0.20 秒，200 KB 用 0.45–1.00 秒，500 KB 用 1.05–2.15 秒。测量机器是 2 vCPU、1 GB 内存，当时还在跑线上流量。

每次都重算的原因在客户端：Claude Code 每调一次工具就发一个新请求，每个请求都带完整会话与整套工具定义，绝大部分文本与上一次相同。

补丁是同小时开出的 #6751（23:34，作者 pf-sjtu），2 个文件、+233/−2，mergeable clean，还没合并17。

改法是：512 字节以上的段单独分词，按内容哈希 memoize，只存哈希、长度与计数，上限 8192 条；段与段之间补一个换行 token18。

作者给的基准：同一台机器上冷跑 100–145 毫秒，热跑 1.4–1.7 毫秒；helps 包 501 个测试全过，另加两个新测试。误差上界是每个边界 1 个 token。

会走到这条路径的执行器不少：gemini、gemini vertex、antigravity、kimi、xai 的流式分支都在 NewClaudeInputTokenState 与 TranslateStreamWithClaudeInputTokens 上19。

今晚能做三件：抓 pprof 确认这一项的占比；给请求瘦身（少挂 tools、截短历史）；把并发压到机器扛得住的范围。补丁合并之前没有开关可关。

预发布 v2.1.19-beta 的八条更新，没有一条是这版新增

codex-proxy 在 23:37 推出 v2.1.19-beta.f824033，target 是 dev，prerelease 为 true20。

说明里列了八条：离线包从发行版缺失、系统代理下连本地模型失败、只配 Antigravity 账号时首页显示无账户、跨供应商的工具调用与图片兼容、长会话断连后的持续 502、流式失败回 HTTP 200、Docker 升级缺新价格表、账号模式下图片生成被屏蔽。

对着 v2.1.18 比一遍：v2.1.18...v2.1.19-beta.f824033 只有 4 笔提交，改到的文件是 npm-publish.yml（+8/−4）、CHANGELOG.md（+67/−65）、package-lock.json 与 package.json21。

除发布流水线那一处，这一版没有运行时代码改动。

八条在 v2.1.18 的 CHANGELOG 里都能找到对应：长会话 502 在第 110 行，价格表加载在第 114 行，流式错误被吞成 200 在第 118 与 120 行，System messages are not allowed 在第 92 行22。

所以这版的含义很具体：那八条修复在 v2.1.18 里就已经在跑，想靠升级拿到它们的人不必动。

附件值得单独看一眼。这版 15 个附件里仍没有 README 引用的 codex-proxy-npm.zip，只有桌面端安装包与 no-node-lite-all-platforms.zip（00:08 复核）20。是构建还没跑完，还是预发布不走那条上传，本文发稿时从外部看不出来。

上期头条那张计费单，被报障人自己关掉了

#8202 在 23:09:34 被关闭，关闭者是报障人本人，状态 completed，全程 0 条评论、没有标签23。这个时间比上一期发稿早两分钟。

sub2api 的 main 从 10 月 16 日 12:42 起没有再动过7。也就是说，这次关闭背后没有对应的代码改动。

代码没变，上期给的两条自查就仍然有效。按模型分组数一遍 usage_logs 里 actual_cost = 0 且 tokens 大于 0 的行；日志里搜 pricing_missing_record_zero_cost 与 inflight reservation cannot price model。

定价取不到时把成本换成零值的那段代码还在 v0.2.17 里24。

次条：codex2api 的安全加固写了六条会改变运维行为的上限

#804 是 10 月 18 日 15:29 开出的 PR，75 个文件、+2823/−174，基于 5ee6c292，mergeable clean，尚未合并25。

作者在说明里列了兼容性影响，其中六条与中转站直接相关：

下游 WebSocket 每 Key 64 条、全局 4096 条，匿名另限每 IP 16 条。
SSE 单行与 Grok 聚合事件上限 8 MiB，上游 WebSocket 解压后单消息 32 MiB。
上游错误体只读前 1 MiB；直接聚合的成功 JSON 上限 64 MiB，超限报错。
解析缓存总预算 64 MiB、单条 1 MiB、TTL 10 分钟。
管理端 10 分钟内 5 次认证失败即封该 IP 10 分钟，这段时间里正确的密钥也返回 429。
RPM/RPD 准入只在当前进程生效，不跨副本共享。

作者自己写明：这些行为变化应写进下一版说明，不改已发布版本的记录25。共享出口或反向代理后面挂管理端的部署，要特别留意第五条。

次条：换凭证类型后旧会话续不上，死锁补丁还开着

#6749 在 23:26 开出，正文只有一行报错：从 codex api 换成 codex oauth 之后，ChatGPT 里之前那条会话继续不了，报 The encrypted content for item rs_... could not be verified26。0 条评论，还没有人给出定性。

上期那条死锁的补丁 #6748 仍开着，mergeable clean，窗口内没有新提交27。

上游与额度

OpenAI 全绿、活动事件 028。最近三条已解决事件仍是 10 月 14 日 Compliance API 成本数据延迟（10 月 16 日 18:44 北京解决）、10 月 15 日的大范围功能降级、10 月 14 日两个图像模型的可用性29。

Anthropic 全绿，10 月 18 日无事件30。GCP 仍是 7 条，最近一条是 10 月 8 日到 9 日的 Cloud Storage31。

Codex 侧今天 UTC 仍未重置：最近一次已验证的全局重置在北京时间 10 月 18 日 04:41，约 19 小时前；累计 55 次全局、10 次 banked，节奏约每 3 天；24 小时 21%、48 小时 37%，模型置信度 Low32。

OpenTheRank 记的是 63 次全局重置、中位间隔 3.1 天、最长 68 天33。两家累计数差 8 次，口径不同，看趋势即可。

官方开发者社区 Codex 分区窗口内 0 条新话题，最新一条停在 23:0234。

Reddit 三个板块窗口内只有作品展示、闲聊与模型对比：r/OpenAI 23:34 一条梗图，r/ClaudeAI 23:35 一条独立开发复盘，r/GeminiAI 23:49 一条 Argon 档位对比，都不在收取范围内35 36 37。

未闭合

#6734 的修复会不会并进 main、随哪一版发出；#6750 的补丁里那把全局互斥锁会不会被要求换掉；#8202 关掉之后维护方会不会另开一张单；#804 合入时那几条上限会不会放松；#6749 会不会被定性成上游行为。

References

1
CLIProxyAPI Releases
github.com
2
sub2api Releases
github.com
3
codex-proxy Releases
github.com
4
codex2api Releases
github.com
5
CLIProxyAPI dev 提交时间轴
github.com
6
CLIProxyAPI main 提交时间轴
github.com
7
sub2api main 提交时间轴
github.com
8
codex2api main 提交时间轴
github.com
9
codex-proxy dev 提交时间轴
github.com
10
CLIProxyAPI issue #6734
github.com
11
v8.0.33 dispatcher.go 第 207–212 行
github.com
12
dev 提交 7484a5216a
github.com
13
提交 7484a5216a 的 clients.go 第 110–160 行
github.com
14
v8.0.33 clients.go
github.com
15
CLIProxyAPI issue #6750
github.com
16
v8.0.33 claude_input_tokens.go 第 100–115 行
github.com
17
CLIProxyAPI PR #6751
github.com
18
PR #6751 全量补丁
patch-diff.githubusercontent.com
19
v8.0.33 gemini_executor.go 第 371–397 行
github.com
20
codex-proxy v2.1.19-beta.f824033
github.com
21
compare v2.1.18...v2.1.19-beta.f824033
github.com
22
codex-proxy v2.1.18 CHANGELOG
github.com
23
sub2api issue #8202
github.com
24
v0.2.17 openai_gateway_usage.go 第 250–272 行
github.com
25
codex2api PR #804
github.com
26
CLIProxyAPI issue #6749
github.com
27
CLIProxyAPI PR #6748
github.com
28
status.openai.com summary
status.openai.com
29
status.openai.com incidents
status.openai.com
30
Anthropic Status
status.anthropic.com
31
Google Cloud Status incidents
status.cloud.google.com
32
codex-reset.com
codex-reset.com
33
opentherank Codex Reset
opentherank.com
34
OpenAI 开发者社区 · Codex 分区 RSS
community.openai.com
35
r/OpenAI
reddit.com
36
r/ClaudeAI
reddit.com
37
r/GeminiAI
reddit.com

codex-proxy 在 23:37 推了一个预发布版。说明写着八条修复，代码里没有新增。

分支头上，CLIProxyAPI 的 main 停在 21:05 的 v8.0.33 提交，dev 在 00:03 落了一笔，正是下面那处凭证保护的修复5 6。

另外三个仓库没动：sub2api 的 main 停在 10 月 16 日 12:42，codex2api 停在 10 月 17 日 05:35，codex-proxy 的 dev 停在 18:467 8 9。

今晚可以先做这四件事

用 CLIProxyAPI 的：今晚别在流量高峰从面板改凭证字段或上传凭证文件。文件被就地重写的那几毫秒里，扫描会把它读成空文件，随后注销这条凭证。修复只在 dev，v8.0.33 没有。
让 Claude Code 打非 Claude 上游的：抓一次 pprof，看 countClaudeInputTokens 的占比。200 KB 的请求一次要吃 0.45 到 1 秒 CPU，而且花在首 token 之前。
用 codex-proxy 的：这个预发布版可以跳过。它相对 v2.1.18 改的是发布流水线与更新日志。
用 sub2api 的：上期那张 P0 计费单已被报障人自己关掉，账单自查照旧。