10/18 入夜速报：codex-proxy 的离线包从没附到发行版上，修法进了 dev；codex2api 的被动额度会改短已有冷却
10 月 18 日北京 19 点这一个小时：四仓没有新版本；codex-proxy 的 npm 离线包从 v2.1.15 起就没附到发行版上，README 那条安装命令一直 404，修触发条件的提交刚进 dev；codex2api 的被动额度快照会把已经在跑的冷却改短。
10 月 18 日北京 18:04 到 19:01 这不到一个小时，四个仓库都没有新版本：CLIProxyAPI 还是 v8.0.32，sub2api 还是 v0.2.17，codex-proxy 还是 v2.1.18，codex2api 还是 v3.1.11234。
这一小时值得单独说的有两件事：一个从 v2.1.15 起就没成功过的发布步骤，和一处会把冷却改短的被动额度观测。
codex-proxy 的离线安装包，一次都没附到发行版上
先给影响面。README 方式三里那条下载命令，现在对所有人返回 4049。按文档装机的人，第一步就停在那里。
codex-proxy v2.1.18 的 .github/workflows/npm-publish.yml 第 365–373 行：步骤名是「Attach offline npm bundle to the release」，第 370 行的 if: 要求事件为 push、ref 类型为 tag。上一行注释还写着「只有 tag 运行才对应一个 GitHub Release」。12稳定版到达这个工作流的方式，是
workflow_dispatch --ref <tag>。bot 打完 tag 之后由发布流程显式派发，而 bot 推的 tag 触发不了下游工作流，所以 event_name 一直是 workflow_dispatch13。两个条件缺一个，步骤每次都 skipped。PR 作者把两次真实运行摆了出来：v2.1.16 的 run 38362508934、v2.1.17 的 run 38592736055，
Attach offline npm bundle 都是 skipped13。被跳过的步骤在日志里只留一个 skipped，整条流水线照常往下走。这条步骤就这样一路躲过三个发行版；直到有人照着 README 的命令去装，才在 404 上撞见它。
18:46 的合并提交 501d76b0 只动这一行：条件换成
startsWith(github.ref, 'refs/tags/')，注释也重写，把「tag 推送」与「稳定版 dispatch」两条来路都讲明白1415。
if: startsWith(github.ref, 'refs/tags/')，第 366–370 行新增的四行注释写明「稳定版以 workflow_dispatch --ref <tag> 到达本工作流」，改动量 2 文件 +11/−5。14这笔改动在 dev，任何发行版里都还没有。你今晚下载的 v2.1.18 里是旧条件，装机照样 404。
旧版本要补，得绕开重跑这条路。re-run failed jobs 对跳过的步骤无效；拿
npm-publish.yml --ref v2.1.16 重跑也没用，因为 workflow_dispatch 加载的是该 tag 提交里的工作流文件，那里条件还是旧的13。作者给了回填三步：从旧 run 下载
npm-tarballs 产物（v2.1.16 的产物保留到 10 月 20 日）；把 *.tgz 与 scripts/npm/offline-install.mjs（改名 install.mjs）放进同一目录后 zip -r codex-proxy-npm.zip .；再 gh release upload v2.1.16 codex-proxy-npm.zip，v2.1.17 同理13。
README.md 第 120–133 行：方式三的标题是「npm 安装（适合已有 Node 的开发者）」，第 122 行写「推荐从 GitHub Release 下载离线包安装（免认证）」，第 125 行就是那条指向 /releases/latest/download/codex-proxy-npm.zip 的 curl。9今晚能做的：
- 换路径。方式二的
codex-proxy-2.1.18-no-node-lite-all-platforms.zip在 v2.1.18 的资产里，现在就能下；解压后 Linux/macOS 跑./codex-proxy.sh，Windows 双击codex-proxy.exe，前置要求 Node.js 20 或更新1016。 - 需要全局
codex-proxy命令的，走 GitHub Packages，token 要有read:packages权限9。 - 自查只要一条：
curl -sI https://github.com/icebear0828/codex-proxy/releases/latest/download/codex-proxy-npm.zip，回 404 就是这一处，省下排查网络的时间。 - 把部署文档、装机脚本里那条 URL 一并换掉。这条链接从 v2.1.15 起就是空的。
- 别把 dev 当发行版：下一个版本才会带上这笔修复。
次条：codex2api 的被动额度快照，会把已经在跑的冷却改短
这一条讲 v3.1.1 现在的行为：被改短的是冷却截止时刻与冷却原因两样。
链条是这样：WHAM 用量探测读到 5h 窗口 100% 时调用
MarkPremium5hRateLimitedAt17，后者在 markPremium5hRateLimited 里无条件写 acc.CooldownUtil = resetAt 与 acc.CooldownReason = cooldownReason18。
codex2api v3.1.1 的 auth/premium_rate_limit.go 第 309–329 行：第 325 行 acc.CooldownUtil = resetAt、第 326 行 acc.CooldownReason = cooldownReason，函数体里没有任何比较分支，末尾还会把同一个原因与时刻写进缓存与数据库。18函数体里没有「已有更晚截止就跳过」这一层判断。账号此刻若正被一次真实 429 扣到更晚的时刻，或被鉴权失败扣住，这次快照会把截止时刻换成自己手里的 reset，把原因换成
rate_limited_5h。7 天窗口那半条一样。
MarkUsage7dRateLimited 先算出到 reset 的时长，再走 MarkCooldown；markCooldown 里是 until := now.Add(duration) 之后直接 setCooldownUntilLocked1920。后果有三层。第一层最直白：账号提前回到可选池，下一次请求再撞一次真实 429。
第二层跟开关有关。
ignore_usage_limit_status 只放过 WHAM 推导出来的那类冷却，权威 429 一律拦住——原因常量上的注释把这条边界写得很明确21。原因一旦被覆盖成 rate_limited_5h，开着这个开关的活跃轮次就会被放行，而那正是 429 拦住的事。第三层是计数。被动观测每次都会把
FailureStreak 加一、把健康档位往 risky 推20。同一段窗口被反复读到，等于反复记一次失败。窗口内 #801 补的正是这一处。第 19 笔提交 301ec4964c（18:10 落地）新增
usageCooldownTargetLocked：已有更长的冷却就保留，原因也保留；真实 429 能把本地用量冷却的原因升级成 responses_rate_limited，同时保留原来的截止；重复观测不再重复写冷却，也不再重复计失败22。#801 现在 19 笔提交、31 文件 +3368/−200、mergeable clean，仍未合并23。v3.1.1 里没有这笔改动。
今晚能做的：
- 开着
ignore_usage_limit_status的部署先关掉。它依赖「冷却原因没被覆盖」这个前提。 - 自查口径：看一张 premium 账号在上游 429 之后是不是很快又出现在可用列表，且冷却原因显示成 5h 限流形态；是，就是这一处。
- 这一版没有开关能关掉这个覆盖行为，只能等 #801 进发行版。
次条：新加的登录限速表，会挤掉还在封禁期的 IP
这一处在 #804 里，属于还没落地的代码。v3.1.1 整包里没有
admin/auth_throttle.go 这个文件，管理端登录目前连失败限速都没有24。评审 18:50 指出的问题是容量淘汰。表里最多记 4096 个 IP，新 IP 失败触顶时按最旧淘汰——即使那条记录的
blockedUntil 还在未来。被淘汰之后 retryAfter 找不到条目，中间件就接受这张 IP 的下一次尝试，封禁等于失效25。评审给的改法是两句话：先淘汰已经解封的；全表都在封禁期时，拒绝新 IP 的准入，把有效封禁留在表里25。
#804 现在 18 笔提交、72 文件 +2358/−148、mergeable clean，仍未合并24。合并前改掉这一条，比合并后再补便宜。
今晚能做的：管理端别放公网。这条路径在 v3.1.1 上本来就没有限速，跟 PR 合不合并无关。
CLIProxyAPI 把上游 499 定性为设计行为
上一期报过的那条「成功请求在上游被记成 499」，维护者给了定性，两秒后就把单子关了，状态是 not planned26。
原文的意思是：下游客户端主动断开或取消连接时，CLIProxyAPI 会同时断掉上游；这个时序由客户端控制，中转只是严格透传两端的生命周期27。
他给的建议是把问题报给客户端（例如 Hermes Desktop），让它等到终局的
data: [DONE] 帧或流 EOF 再关连接27。对运维的意义很实际。上游面板的 499 与本地 Success、token 全部记上同时出现时，按客户端断连处理就行，省下查配置与换版本的时间。报障人当时的对照是 7 组输出 token 与上游 499 一一对上26。
他提的另一种改法——终局帧之后先等 100 到 250 毫秒再取消上游 context——维护者没有接受26。这一版维持现状。
时间上补一句：这条回复在 17:59:37，关闭在 17:59:39，都落在上一期截稿之后，上期没来得及写26。
窗口内其余
#6740（ProMax ultrafast 按账号分流）这一小时时间戳动了，提交没动：三笔仍停在 16:46、17:19、17:45，13 文件 +467/−5，仍 open、clean28。
sub2api 这一小时只有一条 4 月的交流长帖被顶起。四仓这一小时的合并只有 codex-proxy #875 一次，没有新版本。
上游与额度
Codex 侧今天 UTC 还没重置。codex-reset.com 记最近一次已验证全局重置为 10 月 18 日凌晨 04:41（约 14 小时前），累计 55 次全局、10 次 banked、pace ≈ 每 3 天，24 小时 21%、48 小时 37%，模型置信度 Low，页面自述最近 8 次里 0% 更短35。
opentherank 的同一项读数是 63 次、中位间隔 3.1 天、最长 68 天36。两站的累计口径差 8 次，取数时选定一处用。
社区侧这一小时的新帖都落在闲聊与作品上。官方社区 Codex 分区窗口内 0 条新话题，最新一条停在 15:3437。
References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5codex-proxy dev 提交时间轴
github.com
- 6CLIProxyAPI dev 提交时间轴
github.com
- 7sub2api main 提交时间轴
github.com
- 8codex2api main 提交时间轴
github.com
- 9dev README 方式三 第 120–133 行
github.com
- 10codex-proxy v2.1.18 Releases
github.com
- 11codex-proxy v2.1.16 Releases
github.com
- 12v2.1.18 npm-publish.yml 第 358–376 行
github.com
- 13PR #875
github.com
- 14合并提交 501d76b0
github.com
- 15dev npm-publish.yml 第 362–380 行
github.com
- 16dev README 方式二 第 88–93 行
github.com
- 17v3.1.1 usage_wham.go 第 738 行
github.com
- 18v3.1.1 premium_rate_limit.go 第 309–330 行
github.com
- 19v3.1.1 store.go 第 2351–2375 行
github.com
- 20v3.1.1 store.go 第 10082–10128 行
github.com
- 21v3.1.1 premium_rate_limit.go 第 11–16 行
github.com
- 22提交 301ec4964c
github.com
- 23PR #801
github.com
- 24PR #804
github.com
- 25评审意见 · admin/auth_throttle.go
github.com
- 26issue #6729
github.com
- 27维护者回复 · issuecomment-6248511810
github.com
- 28PR #6740
github.com
- 29PR #5511
github.com
- 30PR #6245
github.com
- 31status.openai.com summary
status.openai.com
- 32status.openai.com incidents
status.openai.com
- 33Anthropic Status
status.anthropic.com
- 34Google Cloud Status incidents
status.cloud.google.com
- 35codex-reset.com
codex-reset.com
- 36opentherank · Codex Reset
opentherank.com
- 37OpenAI Developer Community · Codex
community.openai.com
- 38r/OpenAI
reddit.com
- 39r/GeminiAI
reddit.com
- 40r/ClaudeAI
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.