吊销的 key 还能跑完这个会话：CLIProxyAPI 只在握手验一次，修复在 dev、没进 v8.0.38
CLIProxyAPI 的 /v1/responses WebSocket 只在握手验一次 key，吊销或超额之后已开连接照跑，修复只在 dev、没进 v8.0.38；这篇给出今晚的处置顺序，并附 codex2api「额度 50% 仍 429」的判定钥匙。
CLIProxyAPI 的 Responses WebSocket，只在连接建立那一刻验一次 key。升级完成之后，每一轮
response.create 都直接执行，没有人再问一次鉴权。1这一条对卖 key 的站是硬伤。客户额度跑完、或者被你吊销的那张 key，只要那根 socket 还没断，就能继续跑到客户端自己退出。Codex 客户端的习惯是一根 socket 挂几个小时。
这条洞在 10 月 21 日 12:02 UTC（北京 20:02）被报上来。同一天 19:41 UTC（北京 10-22 03:41），它在 dev 分支上被修掉，报障单打了 Fixed 标签。12
v8.0.38 里没有这笔。发行版是 15:11 UTC 发的，比修复早四小时半。3
也就是说，今天跑 v8.0.38 的站，还在这个洞里。dev 分支的 HEAD 就是这笔提交，主干没动。
现在没有可升的版本。四仓窗口内都没有发新版，CLIProxyAPI 最新仍是 v8.0.38。
洞漏在哪一行
对这两条路由，发行版里唯一会问鉴权的地方，是挂在路由组上的那个中间件。它对每个 HTTP 请求问一次，WebSocket 升级也算一次。4
升级之后，这条路由就交给 WebSocket 处理器了，中间件不再参与。
两处都只靠握手那一次检查。发行版的 WebSocket 处理器里，
AccessManager 与 Authenticate 两个词一次都没出现。dev 分支补的是一个新函数，叫
authenticateResponsesWebsocketTurn。6它做的事不复杂。先把升级请求克隆一份，改成 POST，把本轮的 payload 当请求体。
接着删掉
Upgrade、Connection、Content-Length、Sec-Websocket-* 这些握手头，再重跑一次 Authenticate。请求体里缺
model 时，它会把这一轮解析出来的模型名补进去。这样 provider 在每一轮都看得到模型，可以做按模型计费或限流。拒绝的处置也定了：回一条 WebSocket 的 error 事件，带拒绝的状态码与文案，socket 保持打开，下一轮再查一次。
sdk/api/handlers/openai/openai_responses_websocket.go 第 269–311 行，dev 分支，截于 2026-10-22 08:23（北京时间）。调用点在两处。第一处在每一轮 payload 处理之前，
updateRequestContext 传 true。7第二处把同一个函数塞进执行器的 context，供上游 WebSocket 双工模式回调。8
response.steer 那条还多一步：它会把这一轮绑定的模型写回鉴权请求体，避免 provider 按客户端临时改的模型名放行。插件那一侧也补了一刀
同一个提交还改了插件 ABI，这一条对做插件的人比上一段更重要。
以前插件想拒绝一个请求，只能把
Authenticated 置成 false。这条路会变成 NotHandled，对外显示 401 Missing API key，而且后面的 provider 还能把它放行。10两个字段都留空时，行为与现在完全一致。已有插件不用改。
internal/pluginhost/adapters_auth.go 第 137–160 行，dev 分支。第 145–149 行是新增的分支。这两件事得一起看。就算插件写了「拒绝并说明原因」，v8.0.38 也不读这两个字段，它照样变成 401 Missing API key。
今晚怎么处置
先确认你有没有在用这条路。翻一下访问日志，找
GET /v1/responses 或 GET /backend-api/codex/responses 返回 101 的记录。有 101，就说明有客户端在用 WebSocket。要立刻让吊销生效，只有一条路：断连接。重启进程，或者在反代层掐掉已建立的连接。改 key、删 key、把额度调成 0，管的都是下一次握手。
短期挡住它，靠边缘。反代层不回
Upgrade 头，请求就退回普通 HTTP，而 HTTP 每一轮都验一次。别去动
websockets 那个字段。它是凭证级的开关，管的是 CPA 到上游那一段，不是客户端到 CPA 这一段；服务端没有键能关掉下游这条入口。12代价是：只走 WebSocket 的 Codex 客户端会直接不可用。要不要这么做，取决于你现在卖的是不是按时长计费的套餐。
| 位置 | v8.0.38 | dev 分支 | 现在能做什么 |
|---|---|---|---|
GET /v1/responses 升级后 | 只在握手验一次 4 | 每轮 response.create 前重验 7 | 断连接或挡掉升级 |
GET /backend-api/codex/responses 升级后 | 同上 13 | 同上 | 同上 |
上游双工的 response.steer / append | 不校验 | 三种帧都过 authorizePayload 9 | 同上 |
| 插件拒绝 | 只能变成 401 Missing API key 10 | 可带状态码与文案 11 | 等发版后改插件 |
按影响面排个序：按时长或按次数卖 key、又靠插件判额度或封禁的站，损失最大。只做透传、key 由外层网关管的站，损失小一些，但外层网关的吊销一样管不到已经建好的连接。
形态分级：三种「修好了但还用不上」
窗口里三张单的处境各不相同，混在一起会误判。
已经在 dev、没进版本。 就是上面这条 #6843。修复提交在 19:41 UTC，报障单在 00:04 UTC（北京 08:04）被打了 Fixed 标签，单子本身还开着。1
它得等下一次发版。目前四仓里没有新版本，CLIProxyAPI 仍停在 v8.0.38。14
已通过人审、还没合并。
#6818 在 22:31 UTC（北京 06:31）拿到一个 APPROVED，评审人是 BichengWang，合并状态 clean，两个文件、+196/−35。15它修的是另一件事。
response.failed 之后，转发器只认 response.completed、response.done、response.incomplete 三个终局事件。response.failed 不在名单里。干净断流因此落进「流在完成前断了」那一支，回 408 并关掉 socket。15如果你有客户端在上下文超限之后掉线、并且要靠同一根连接接着发，这一条就是针对它的。它还没合。
评审往返中。
#6853 改的是文件快照覆盖运行时状态：一次读到旧快照再应用，会把 Unavailable、Quota、NextRetryAfter 一起盖掉，冷却就丢了。它自称是 #6844 的第 1、2 项。16两张的最后一条评审都停在 bot 的 COMMENTED，没有批准。
第二条线：codex2api 的 7d 冷却粘住
窗口内 codex2api 只有一条动静：一张 10 月 21 日 08:17 UTC（北京 16:17）开的报障，昨晚被人回了一句。
单子的正文写得比回复扎实得多，值得单独说。18
报障人的环境是单号池：一个 Pro OAuth 账号，Linux Docker，PostgreSQL 加 Redis。他的账上写着周额度已用 50%、健康度 100%，账号状态却是「限流 | 7d」，倒计时约 142 小时。18
/responses 确实回 429，不是界面显示错了。他从后台点了一次「重置账号状态」，再刷一次用量，请求立刻恢复，没重启容器，也没等到周窗口重置。他自己写得很克制：这是发生过一次、没有稳定复现，手里也没有故障瞬间的库快照，所以不能确认根因。下面三条是我按 v3.1.1 的源码核出来的机制，不是他的结论。
FreshDispatchUsageLimited 有两条判据，后一条与用量百分比无关。前一条看用量窗口是否已满；后一条只看本地状态还停在冷却里、且冷却原因属于用量类。19这就是「额度条没满、却还被判限流」能成立的地方。后端把它当 429 的依据，正是这个函数。19
auth/store.go 第 2013–2030 行，codex2api v3.1.1。第 2029 行是那条与用量百分比无关的判据。第二条：清理函数不告诉你它到底清没清干净。
ClearUsageLimitCooldownSince 先清内存，再发一条带条件的 SQL，条件是「原因与截止时间都对得上」。20函数最后无条件
return true，只在 SQL 报错时打一行日志，没命中行数时不吭声。调用它的地方照样会打出「wham 显示限流窗口已重置，自动解除限流冷却」。第三条：库里的旧冷却会被搬回内存。调度器的 outbox 消费走
applyPersistentAccountSnapshot。
auth/scheduler_outbox_consumer.go 第 524–544 行，codex2api v3.1.1。三条串起来是一条可能的路径，不是已证实的因果：内存清了、库里那条因条件没匹配而留着，下一次快照回填又把它搬回来。我核不到故障瞬间的数据，这一步只能由报障人自己验。
怎么认出这是本地判的，不是上游拒的
有一条现成的钥匙：看响应文案。
本地判出来的 429，走的是
SendAPIKeyLimitError，正文是中文那句「Codex 账号用量窗口已达上限」。23瞬时那一类会换成「Codex 账号瞬时限流中，请 N 秒后重试」，同时带一个
Retry-After 头。真正的上游 429 会带上游自己的 JSON，一般是
usage_limit_reached 那套字段。报障人踩的坑正好在这：他查了最近 12 小时的
usage_logs，一条 status_code=429 都没有，而容器日志里 429 一条不少。光看用量面板会漏判。要止血，顺序是这样：先确认 429 的正文是哪一句；是本地那句，就去后台重置该账号状态。
代价要说清：这一步也把「上游确实拒过我」这条证据一起清了。如果上游真的在限流，下一个请求会再撞一次，重新进冷却，损失一个请求的时间。
改积分开关也会尝试释放冷却，而且会当场告诉你结果。
判据窄到容易被忽略：冷却原因要在用量类名单里，并且冷却截止时间与
Reset7dAt 的差值小于 2 秒。27漂移超过两秒就返回 false，而且不打日志。
报障人给的两个时间差得远：冷却截止是 10 月 27 日 14:32:11，恢复后读到的周窗口重置是 10 月 28 日 09:45:37，中间差近 19 小时。按这条判据，开关认不出这是一次本地用量窗口判罚，所以那一改不会释放任何东西。18
他的日志正好是这个形状：15:10:25.544 改积分设置返回 200，15:10:25.849 的下一个请求就是 429，中间隔 305 毫秒。
顺序就成了：先看
cooldown_released，是 false 就直接重置账号状态。别指望改开关。第三条线：上游额度为什么突然见底
如果你昨晚发现号池在几十分钟里被吃光，窗口内两条上游报障对得上。
一条说 Plus 的 5 小时额度在 11 分钟里从 100% 掉到 0，期间只做两个普通开发任务，Codex 自动派了三个子代理（两个 Sol High、一个 Luna Low）。28
另一条说 Astra Medium 在 30 分钟里烧光全部 token，环境是 CLI 0.163.0。29
两条都是用户自述，都还开着，唯一的回复是自动去重机器人。
那个机器人把更早的同题单全列了出来：#55648、#55709、#54995、#55210 四条。28
翻其中三条，规模一次比一次具体。
10 月 18 日那条写周额度在一轮对话里从 26% 跳到 67%。30
10 月 20 日那条写一个短任务吃掉约 233 万 token，3 分 24 秒耗尽 5 小时额度。31
10 月 21 日那条写 Pro 账号 20 分钟用掉周额度约 15%。32
五条都开着，标签都是 rate-limits。它们共同指向一件事：按 token 或按窗口记账的中转，这几天的消耗速度可能不是你以为的那条曲线。
同窗口还有一条 Fast 模式的重连报障：任务跑了六七分钟，客户端反复显示
Reconnecting 2/5，并且不断收到 WebSocket 端点的 503。33重置信号那边，页头的图例别当成状态。codex-reset.com 顶部那行「strong Tibo signal · verified reset · banked reset」是三种徽章的说明，不是当前信号。
它现在的结论是：今天 UTC 还没重置，最近一次已验证的全局重置在 42 小时前（北京 10 月 20 日 14:33），累计 56 次、10 张存着，24 小时概率 22%、48 小时 39%。34
另一家站的读数一致：累计 64 次，中位间隔 3.1 天，最长等过 68 天。35
codex-reset 明写没有官方重置信号，opentherank 只记历史、不给预测。两家的累计数也不同源：56 是前者的样本，64 是后者从 2025 年 9 月起算的全部记录。
按这个口径排容量，比按「今晚可能重置」排要稳。
闭环：Fable 5 那条降级已经恢复
上一期主线那条 Anthropic 事件，在 20:29 UTC（北京 04:29）转成 resolved。事件从开到时隔 40 分钟，影响级别是 minor。36
最后一条更新写的是「影响其他 Claude 模型的问题已经解决」。标题只点了 Fable 5，恢复语写的是其他模型，两处口径仍不齐。36
Claude 状态页现在是 All Systems Operational，组件表全绿。37
OpenAI 状态页也是全绿。历史上最近一条是 FedRAMP 那条，19:34 UTC 已恢复。38
Google Cloud 的事故列表还停在 10 月 20 日那条 europe-west2，窗口内没有新的。39
四仓窗口内没有新版本
CLIProxyAPI 停在 v8.0.38、sub2api 停在 v0.2.17、codex-proxy 停在 v2.1.20-beta.0543eaa、codex2api 停在 v3.1.1。14404142
主干也基本没动。CLIProxyAPI 的 main 停在 15:04 UTC，dev 头就是那笔修复；sub2api 的 main 停在 12:19 UTC。
codex-proxy 与 codex2api 的 main 更久，分别停在 10 月 18 日与 10 月 20 日。
窗口扫描的条目变动只有五处：CLIProxyAPI 的 #6843、#6818、#6853、#6855 四张，加一张被顶起的旧 PR #6715；codex2api 的 #813；sub2api 只有 4 月那个交流长帖被顶了一下；codex-proxy 一条都没有。
今天要做的三件事
- 翻日志，确认有没有 101 的 WebSocket 升级。有，就把「吊销即刻生效」这条从你的预案里划掉，改成「吊销加断连接」。
- codex2api 上看到 429，先看正文。是「Codex 账号用量窗口已达上限」，就重置账号状态；是上游 JSON，就别重置，让它按上游的重置时间走。
- 按消耗速度重新算容量，别按「今晚可能重置」算。两家追踪站都给不出官方信号。
References
- 1
- 2
- 3Release v8.0.38
github.com
- 4server_middleware.go 第 204 行（v8.0.38）
github.com
- 5server_routes.go 第 85 行与第 122 行（v8.0.38）
github.com
- 6
- 7
- 8
- 9
- 10adapters_auth.go 第 139–149 行（dev）
github.com
- 11errors.go 第 82 行 NewDeniedError（dev）
github.com
- 12config_types.go 第 735 行（v8.0.38）
github.com
- 13server_routes.go 第 122 行（v8.0.38）
github.com
- 14CLIProxyAPI releases
github.com
- 15
- 16
- 17
- 18
- 19store.go 第 2013–2030 行（v3.1.1）
github.com
- 20store.go 第 10638 行（v3.1.1）
github.com
- 21usage_snapshot.go 第 72 行（v3.1.1）
github.com
- 22
- 23apikey_limits.go 第 303 行（v3.1.1）
github.com
- 24store.go 第 10565 行 ClearCooldown（v3.1.1）
github.com
- 25postgres.go 第 8669 行 ClearError（v3.1.1）
github.com
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34codex-reset.com
codex-reset.com
- 35opentherank codex reset tracker
opentherank.com
- 36Degraded performance for Claude Fable 5
status.claude.com
- 37Claude Status
status.anthropic.com
- 38OpenAI status summary
status.openai.com
- 39Google Cloud incidents
status.cloud.google.com
- 40sub2api releases
github.com
- 41codex-proxy releases
github.com
- 42codex2api releases
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.