Codex 又发一张 banked 券：三套中转里只有两套能把它花出去
Codex 今天发出第二张 banked 券，但三套中转里只有 sub2api 与 codex2api 兑得掉，CLIProxyAPI 只能等窗口滚动；顺带给出今晚的兑券顺序与三个回执告警码。
北京今天早上 07:27，Tibo 发了一条四个词的公告：「Day 28/ Banked 2/2」1。
这是今天第二张 banked 券，不是一次全局重置。
对中转站的意义很具体：池里被 429 打空的号，现在多两次手动回血的机会。
能不能用上，取决于你跑的是哪套实现。下面三套的差别，比公告本身重要。
一手事实
上一张是北京时间 11-01 08:43 的「Banked 1/2」2。
两张对应 10-31 中午那条预告：「Next two days will be resets… banked」3。
按这个说法，这两天各发一张。分母「2」的官方定义没有公开，本刊不替它下定义。
公告发出约半小时，这条已有 3000 余赞、15 万次浏览。
两站的时刻差 54 分钟，但都没错
追踪站 codex-reset 记的不是公告时刻，而是「自家监控账号收到券」的时刻：北京 06:32:56 4。
这条记录里
after_announcement 为 false，即先看到券、后看到公告。顺带补一笔。上一期窗口止于北京 06:30、06:36:56 发稿，券在 06:32:56 落地，正好卡在两次发稿之间。
同一页把 10-31 与 11-01 两条都标成「banked reset update · not a reset」5。
另一家首页写得更直：「banked 券必须去 Codex 的 Settings → Usage 自己领」6。
banked 不等于已重置
按追踪站的说法，banked 是「存到账号里、等你自己兑换」的一次重置。
券本身不刷用量。兑一次会同时重置 5 小时与周两个窗口，周窗口的日期往后推约七天 5。
同一页还引了 OpenAI 的一句话：不要为了测试第一张有没有生效，就把第二张花掉。
所以今晚真正的动作只有两种：在 Codex 侧领，或者在中转侧用接口兑。
sub2api：能兑，但不知道兑的是哪一张
v0.2.19 把上游返回的券信息裁到只剩一个字段：
expires_at。注释写得很直白：「Do not add upstream ids or tokens here」，上游券 ID 被刻意剥掉 7。
openai_quota_service.go 第 66–85 行，券详情只有 expires_at；第 79–82 行另注明 credits 余额与 reset credits 是两回事。7手动兑换入口是
POST /api/v1/admin/openai/accounts/{id}/reset-quota，与查额度、刷额度并在同一个路由组 8。不带券 ID 的消费，意味着这一下由上游替你挑一张。有券就兑得掉，挑不了那张。
账号级自动用券是显式开关，阈值默认 100%，未配置过的历史账号保持关闭 9。
所以「公告一来券就自动用掉」在 sub2api 上不成立，除非你早就开过。
codex2api：看得到是哪一张，也能只花那一张
同一个上游接口，v3.1.2 保留了完整字段：
id、reset_type、status、granted_at、expires_at、consumable_until。
proxy/usage_wham.go 第 425–468 行，同一上游接口保留了 id 与 reset_type，并用三重条件筛出可用券。10更关键的是那道过滤：只有
reset_type=codex_rate_limits、status=available、且带截止时间的才算当前可用。这解释了为什么
available_count 明明大于 0，点下去还是说没券——列表里那张可能不是 codex 类型。消费流程的注释写明：401 刷新账号 token 后，用同一个
redeem_request_id 重试，避免重复扣掉一次宝贵的重置次数 12。
admin/reset_credits.go 第 97–110 行，消费前先拿账号级互斥锁，成功后写一条 reset_credit 审计记录。12上游的报错它也翻成了中文，比如「额度计费计划不支持主动重置」「没有可用的主动重置次数」13。
CLIProxyAPI：这条路没有
也就是说它既查不到券，也兑不了券。今天这张公告对它是空的。
池子里 CLIProxyAPI 占多数的，今晚只能等 5 小时与周窗口自然滚动。
今晚的操作顺序
- 先在 Codex 侧确认券在不在：Settings → Usage，或 CLI 里跑
/status。公告只管「发了」，不管「到了」。 - 用 sub2api 的：
GET /api/v1/admin/openai/accounts/{id}/quota看available_count，再POST .../reset-quota。 - 用 codex2api 的：
GET /api/accounts/{id}/reset-credits看清是哪张、什么时候前必须用，再POST同一路径。 - 兑完看回执：
windows_reset为 2，才说明两个窗口都重置了。 - 用 CLIProxyAPI 的不用点，盯住窗口滚动时间即可。
第 4 步在 sub2api 上还要多看一眼
warning_code。回执里出现
reset_credit_cache_refresh_failed、account_state_recovery_failed、account_state_refresh_failed 三者之一，说明券可能已经花掉，但本地状态没跟上 15。
openai_quota_reset_workflow.go 第 26–72 行，兑券后按「恢复账号状态、刷新额度快照、重载账号行」的固定顺序收尾。15顺序是写死的：先恢复账号状态（顺带作废 token），再查用量写快照，最后重载账号行。
这么做是为了让手动与自动两个入口，不在失败语义上越走越远。
三件别做的事
别为了验证第一张有没有生效就把第二张花掉，这是追踪站引 OpenAI 的原话。
别把公告写进监控当「已重置」。两站都把这两天标成 not a reset，落地时间至今为空。
别指望自动用券。两套实现的自动消费默认都是关的，升级不会替你打开。
这一小时没变的
四套仓库窗口内零发版：CLIProxyAPI 停在 v8.0.51、sub2api 停在 v0.2.19、codex-proxy 停在 v2.1.21、codex2api 停在 v3.1.2 16。
主干与 dev 也没动：CPA 的 main 与 dev 都停在今天凌晨 01:07，sub2api 主干停在 10-30，codex-proxy 的 dev 停在今天 03:14。
窗口扫描只翻出三张旧补丁被顶起（#7184、#7174、#7142）。
后两张的修复其实已经在 v8.0.51 里，不算这一小时的新素材 17。
OpenAI、Anthropic、Google Cloud 三家状态页全绿，官方社区 Codex 分区窗口内 0 条新话题 18。
所以今天这一期只有一件事：券到了，看你兑不兑得动。
References
- 1
- 2Tibo：Banked 1/2
x.com
- 3
- 4codex-reset：banked 观测记录 api/feed
codex-reset.com
- 5codex-reset 首页：FAQ 与时间线
codex-reset.com
- 6opentherank：Codex 重置追踪
opentherank.com
- 7
- 8sub2api v0.2.19：admin.go 第 465-467 行
github.com
- 9
- 10
- 11codex2api v3.1.2：admin.go 第 1223-1224 行
github.com
- 12
- 13
- 14
- 15
- 16CLIProxyAPI 发行页（最新 v8.0.51）
github.com
- 17CLIProxyAPI PR #7184
github.com
- 18OpenAI 状态页
status.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.