10/17 凌晨速报：Devin 周额度耗尽会把整条凭证钉到重置时刻——修复已进 dev、发行版还不含；同一小时开出按重置额度排号的伴随脚本
10 月 17 日北京 01:43 到 02:47 这 64 分钟里四个仓库都没发新版本：CLIProxyAPI 把 Devin 周额度耗尽后的短退避改成整条凭证钉到重置时刻，修复只进 dev、发行版上仍会把同一张凭证反复派出去；同一小时里一条按重置额度排号的伴随脚本开出，同一个 PR 也把 README 里的伴随工具列表补了一行。
当前版本仍是 sub2api v0.2.17、CLIProxyAPI v8.0.31、codex2api v3.1.0。codex-proxy 最新的那个仍标着预发布4。
sub2api main 停在 10 月 16 日 12:42（北京），codex-proxy dev 停在 10 月 16 日 01:16（北京），codex2api main 停在 10 月 16 日 18:45（北京）。三个仓库的主干在本窗口没有新提交567。唯一动过的是 CLIProxyAPI 的 dev，一笔提交8。
今晚最该拿主意的一件事是 Devin 凭证。CLIProxyAPI 把「周额度耗尽的凭证被反复选中」这条修好了，但只修在 dev 上。
一、Devin 周额度耗尽现在会把整条凭证钉到重置时刻
CLIProxyAPI dev 在北京 02:18 落下一笔提交，标题是给 Devin 加账号级额度耗尽跟踪与凭证冷却刷新，正文末行写着
Closes: #66909。这笔提交 12 个文件 +2210/−18，其中四个文件是新增的回归测试9。
被它接掉的 #6690 是 10 月 16 日北京 22:37 开出的报障单，作者 Ivan0514Xu，环境写的是 v8.0.31 官方 Docker 镜像、Devin 通道、流式请求、冷却开着10。
现象是这样的。Devin 的周额度耗尽之后，上游明确回
failed_precondition: Your weekly usage quota has been exhausted.，CPA 把它归成 HTTP 429，然后只按模型做了 1 秒、2 秒、4 秒、8 秒的短退避10。报障人给的时刻表是四个失败点：15:37:09.661、15:37:24.365、15:37:33.525、15:37:42.145，都是 UTC+8，冷却分别到 1、2、4、约 8 秒之后10。
短退避一过，同一张凭证又被选中。17:47:23、17:47:25、17:47:30 这三次它被派给
devin/claude-haiku-5-5，三次都以同一条周额度报错失败10。人工停用这张凭证之前，累计已有 21 次模型调用因周额度耗尽失败10。
本刊在读者手上这一版核到，重置时刻其实一直在被观测。v8.0.31 的
devin_executor.go 第 209–215 行，Refresh 已经把每日与每周的剩余百分比、以及 daily_quota_reset_at 与 weekly_quota_reset_at 两个重置时刻写进 Quota.Signals11。缺的是拿它做决定的那一步。报障人把这条路径列得很细：判定在
helps/devin_wire.go 的 ParseDevinTrailerError，配额类的 failed_precondition 一律归成通用 429；冷却层只有 result.CredentialScope 为真才把凭证写成 credential_quota10。冷却层这一侧本刊也核了：v8.0.31 的
conductor_cooldown.go 第 1004–1024 行，同凭证的其他模型与整条凭证都被写上 credential_quota，整段都在凭证作用域的分支里12。模型级那个
"quota" 不满足这几个条件，所以整条凭证照常参与调度。修复分三段，每一段都在把这三步接上。
作者把匹配写得很窄：monthly ACU 这类措辞、通用限流、瞬时容量错误都不匹配，仍留在原来的短退避路径上14。
两个窗口同时被提到时按 weekly 算，因为它是更长的那个窗口14。
internal/runtime/executor/helps/devin_quota.go 第 27–46 行：第 36 行要求消息里同时出现 quota 与 exhausted，第 39–44 行再分辨 weekly 还是 daily，两个周期词都没有就返回「不算额度耗尽」14第二段把这个 429 升成凭证级。
devin_executor.go 新增的 devinQuotaScopedStatusError 先看状态码是不是 429、再看消息是不是上面那种耗尽；两条都命中才把 credentialScoped 置真15。取到的时刻必须落在未来、且不超过 8 天，否则这个观测值作废，冷却时长交回给冷却层14。
上游自己已经给了
Retry-After 的情况，观测值不覆盖它15。
internal/runtime/executor/devin_executor.go 第 2549–2565 行：第 2550 行先卡状态码必须是 429，第 2557 行把这次失败标成凭证级，第 2559–2563 行按周期去 Quota.Signals 里取对应的重置时刻15第三段给了一条提前解除的路。Devin 的会话令牌不过期，所以原来的自动刷新循环永远不会再回来看这张凭证一眼，代码注释把这一点写明了16。
新逻辑只在凭证已超、原因是
credential_quota、恢复时刻还没到时生效，把下一次复检排在上次刷新之后一小时、并以重置时刻为上限16。复检拿回来的观测必须严格新于已存的快照、也新于耗尽状态写入的时刻，才允许解除整条凭证的冷却16。
陈旧或重放的一次刷新，因此无法把一张已经耗尽的凭证复活。这一条针对的是自动刷新循环每几秒就要评估一次的现实。
sdk/cliproxy/auth/conductor_refresh.go 第 508–536 行：第 510 行把复检间隔定为一小时，第 521 行要求凭证确实处于 credential_quota 冷却中，第 531–534 行把下一次复检排在刷新之后一小时、并以恢复时刻为上限16这条单子现在的状态是 open、0 评论，但已经被打上
Fixed 标签10。今晚能做的事有三件。第一件是把已经耗尽的 Devin 凭证手工停用——在 v8.0.31 上它还进得了调度；第二件是翻一下错误事件里的
quota_reason，写着 "quota" 就说明这一趟走的是短退避那条路；第三件是升级前先看发行版本号，这笔提交眼下只在 dev 上9。二、同一小时开出的重置额度路由伴随脚本
CLIProxyAPI PR #6694 在北京 01:46 开出，作者 kakcil，open、非 draft、
merged=false、mergeable_state 为 clean、3 个新文件 +462/−0、3 个提交17。它的基分支原本写的是 main，机器人随后自动改成了 dev，页面上留了两条同样的说明17。
这是一个本地伴随脚本，作者自己写明它不是核心路由改动17。
它要做的事是按「已获得的重置额度即将过期」给 Codex OAuth 账号排优先级，再把结果写回 CLIProxyAPI 的凭证优先级17。
Codex 这一侧，它只在两个条件同时成立时尝试兑换：距离这次额度过期不足 24 小时，且每周窗口的续期时间更晚、当前用量已经很高——90%，或者在一小时里到了 10%17。
兑换之后它会重新读一次额度，只有确认兑换成功才清掉 CLIProxyAPI 本地的冷却17。
它从不发送人为的模型请求去燃烧额度，这是作者特意写进正文的一条17。
Claude 这一侧它只认本地核实过的 offer 日期，按显示的过期时间给该账号排优先级，到期后把优先级退回零17。
它不会自动点那个兑换按钮。作者给的理由是 Anthropic 目前只在 Claude 网页版与桌面版提供 offer 与兑换入口，所以他只做到「替你盯着、替你排队」17。
作者自述的验证是三句话：6 项策略与幂等单测通过；对 Codex 账号做过只读实测、没有消耗任何一份已获得的重置额度；在 Claude 桌面版的用量页面上看到过一份完整重置 offer，本地优先级更新验证过，没有点那个按钮17。
他自己也标了两条边界：Codex 由外部托管的 token app-server 模式是实验性的，以后可能要跟着改；这个示例是选装件17。
脚本本体在
examples/reset-aware-router/reset_router.py，同一目录里另有一个 README 与一份单测18。新提的三条都落在最要紧的两步上，值得想跑它的人先看一眼。
一条是顺序问题：已经确认额度被兑换掉之后，要先清本地冷却，再做那次可能长时间不返回的额度读取；顺序反了，这一次就会卡在那儿，其它账号也一起不再被检查17。
另一条是要把冷却重置这件事挂起来重试：重置接口返回瞬时错误时如果就此结束，额度已经花掉、凭证却还扣着，后面几轮也不会再走到这里17。
三、上期那条用量伴随工具的增量
CLIProxyAPI PR #6693 上期已报过，本窗口的变化有三处19。
基分支被机器人从 main 自动改到 dev，说明在 01:21 与 02:13 各出现一次19。
作者在北京 02:00 前后回复了 6 条评审意见，其中一条指出工具该打印客户端请求的别名、而不是解析之后的上游模型名19。
北京 02:06 对新提交 6043b7c 的复审，结论仍标着未解决的发现19。
状态仍是 open、非 draft、3 个新文件 +245/−0、2 个提交19。
有一个边界依然决定它今晚能不能跑：它要消费的管理端 usage 队列是破坏性消费，同一个队列上不能再有第二个消费者19。
四、同一窗口里的短条目
CLIProxyAPI PR #6695 在北京 02:20 开出，作者 mindtheflo，open、非 draft、3 个文件 +12/−0，改的是三个 README 的伴随项目段20。
加进去的是 Juice Bar，一个 macOS 菜单栏应用，显示 Claude 与 OpenAI Codex 订阅的池化容量、账号续期时间与基于证据的用量预测21。
它从源码用一个编码代理提示安装，打包和替换代理这两件事它都不做20。
这是纯文档条目，作者自己写明了这一点；自动审查对它的结论是没有发现20。
版本与主干的总括放在这里：本窗口四个仓库都没有新版本，三个仓库主干没有新提交。
窗口内 CLIProxyAPI 只有上面三条条目更新，sub2api、codex-proxy、codex2api 都是 0 条。
五、上游与额度侧
OpenAI 状态页本轮全绿：All Systems Operational，活动事件 0 条22。
上期还挂着的那条 Compliance API 成本数据延迟，已经在北京昨天 18:44 转正22。
Anthropic 状态页同样是 All Systems Operational，10 月 16 日那一栏写着 No incidents reported today23。
Google Cloud 的事件列表仍是 7 条，最近一条仍是 10 月 8 日到 9 日的 Cloud Storage 上传与写入延迟24。
Codex 重置追踪站上，今天（UTC）没有重置。最近一次已验证的全局重置在 37 小时前，即 10 月 15 日 06:13 UTC、北京 14:1325。
累计是 54 次全局、10 次 banked，节奏约每 4 天。两套概率口径仍并列：模型口径是 24 小时 18%、48 小时 33%；把那条回帖计为提示的口径是 24 小时 50%、48 小时 75%25。
本刊直接核了 Codex 负责人 @thsottiaux 的时间线：窗口内没有新帖，最近一条仍是北京昨天 13:51 的那句 "Either we are out of ideas or we are cooking. Time will tell"26。
也就是说，这一小时里没有新的重置信号出现。
另一个追踪站仍记最近一次为 10 月 15 日 04:55 UTC；自 2025 年 9 月以来 62 次，中位间隔 3.1 天，最长等了 68 天27。
官方开发者社区 Codex 分区窗口内没有新帖。最新一条仍是北京昨天 23:09 那份报障，报告人说自己当天还没动手、小时窗口就只剩 4%，并且说不清是哪部分活动消耗掉的28。
Reddit 上本窗口内有一条额度报障。r/OpenAI 在 02:18 发的帖子说，上一次重置之后一天内他从 100% 掉到 0%，其后又用掉约 3 万 credits；他的工作流是 Astra 带 Sol 6.1 子代理、两边都开 thinking High29。
这条目前 4 分、3 条评论，是一条未经核实的个人读数29。
同一主题的另外两条都不在本窗口，其中一条已经被作者自己撤回。北京昨天 23:20 那条《Sol 6.1 burns 3x/4x more usage lately》在北京 00:38 被作者编辑补了一句：主要是上下文长度，那条会话在额度耗尽之前已经触发了 compaction30。
所以这一串说法里，今天能站住的只是「个人账号的额度消耗比平时快」这类主观读数，而且只出现在小时窗口上。三个来源都没有给出同一台机器上的对照数据，本刊不作方向性结论。
r/ClaudeAI 与 r/GeminiAI 的板块在本窗口内没有额度或风控条目。
六、未闭合项（下期继续跟，不作结论）
上一期盯的三条，本窗口都停在原地：sub2api #8168、#8167、#8166 三张修复仍是 open、没有合并、也都没有新动静313233；CLIProxyAPI #6616 通过评审之后仍没有并进 dev34。
- CLIProxyAPI：本窗口登记 #6694、#6695，#6693 更新，dev 落下 b946d54；继续跟 b946d54 会不会进下一个发行版、#6694 把审查意见改完之后会不会合并、#6693 会不会被采纳，以及 #6691、#6690、#6688、#6686、#6682、#6687、#6681、#6683、#6679、#6680、#6676、#6677、#6515、#6675、#6605、#6669、#6670、#6661、#6667、#6659、#6671、#6673、#6625、#6603、#6500、#6169
- sub2api：本窗口 0 条；继续跟 #8168、#8167、#8166 会不会合并，以及 #8165、#8164、#8163、#8161、#8160、#8157、#8158、#8159、#8155、#8151、#8139、#8135、#8136、#8142、#8143、#8146、#8147、#8127、#8125、#8123、#7962、#7398
- codex-proxy：本窗口 0 条；继续跟 v2.1.18 正式版会不会打上
latest - codex2api：本窗口 0 条；继续跟 #793
下期优先回看三条：b946d54 会不会随下一个发行版出去（出去那天，跑 Devin 凭证的实例要把错误事件的
quota_reason 重新对一遍）；#6694 剩下的三条审查意见会被怎么改；三张 sub2api 修复有没有合并。References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex2api Releases
github.com
- 4codex-proxy Releases
github.com
- 5sub2api 主干提交
github.com
- 6codex-proxy dev 提交
github.com
- 7codex2api 主干提交
github.com
- 8CLIProxyAPI dev 提交
github.com
- 9dev 提交 b946d54
github.com
- 10CLIProxyAPI #6690
github.com
- 11devin_executor.go（v8.0.31）第 209–215 行
github.com
- 12
- 13selector.go（v8.0.31）第 836–838 行
github.com
- 14devin_quota.go（dev）第 27–63 行
github.com
- 15devin_executor.go（dev）第 2541–2570 行
github.com
- 16conductor_refresh.go（dev）第 508–545 行
github.com
- 17CLIProxyAPI #6694
github.com
- 18reset_router.py（该 PR 头分支）
github.com
- 19CLIProxyAPI #6693
github.com
- 20CLIProxyAPI #6695
github.com
- 21Juice Bar
github.com
- 22OpenAI Status
status.openai.com
- 23Claude Status
status.anthropic.com
- 24Google Cloud Status
status.cloud.google.com
- 25codex-reset.com
codex-reset.com
- 26
- 27opentherank
opentherank.com
- 28社区帖 1406982
community.openai.com
- 29r/OpenAI 1x7nqxl
reddit.com
- 30r/OpenAI 1x7j1um
reddit.com
- 31sub2api #8168
github.com
- 32sub2api #8167
github.com
- 33sub2api #8166
github.com
- 34CLIProxyAPI #6616
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.