自动重置那道闸撤了，价格改按列名读：codex2api 25 分钟进七张单，v3.1.1 还没带上
codex2api 在 25 分钟里合进七张单：自动重置那道闸撤了、官方价格改按列名读、Antigravity 配额门禁默认打开，但发行版仍是 v3.1.1，今天该做的是手动重置与核一遍缓存读取价。
从北京 16:37 到 17:02 的 25 分钟里，codex2api 的主干合进了七张单，另有一笔直接推上去的提交。发行页上最新的仍是 10-17 05:42 发的 v3.1.1，这一批没有一张随版本发出去。1
结论先说：今天没有可升级的新版本。三件事现在就能做——还在 v3.1.1 上、又开了「窗口用尽自动重置」的，继续走面板手动重置；开过官方价格同步的，去核一遍缓存读取价；多智能体那个新开关先别碰。
这批里有三处直接碰到钱与配额：自动重置的判定、官方价格的读法、Antigravity 的额度门禁。
| 单号 | 合并（北京） | 规模 | 改了什么 | 随版本发出 |
|---|---|---|---|---|
| #824 | 16:43 | 2 文件 | 自动重置只留 available_count 一道闸 2 | 否 |
| #812 | 16:41 | 4 文件 | 官方价格改按列名解析 3 | 否 |
| #818 | 17:02 | 36 文件 | 价格校验与四级来源回退 4 | 否 |
| #817 | 16:42 | 67 文件 | Antigravity 配额自动刷新与硬门禁 5 | 否 |
| #819 | 16:42 | 8 文件 | 账号同步时落 Codex 能力快照 6 | 否 |
| #822 | 16:42 | 1 文件 | 输入校验放行 configuration_update 7 | 否 |
| #803 | 16:37 | 13 文件 | 多智能体 v2 明文兼容（默认关） 8 | 否 |
| 0db88926 | 16:37 | 6 文件 | Go 升到 1.26.10、vite 升到 8.3.5 9 | 否 |
自动重置：上一期报的那道闸，上游自己撤了
报障单 #823 今天 16:24 开出，就是上一期那条主线的源头。Business Pro Lite 账号，7d 用到 100%、手里 2 张券，后台扫描一直
candidates=0 consumed=0。同一份报障里还有一句关键：同一天、同一套餐的另一个账号，自动重置成功过。这个字段的取值会变。10
18 分钟后维护者合并了 #824，再过 1 秒把 #823 关成 completed。2
改法只有一行：判定从「两个字段任一为 0 就放弃」，变成只看
available_count。11项目里的注释把理由写在了代码上：
applicable_available_count 只是参考值，这类账号在 7d=100% 时报过 0，consume 却照样成功；上游真要拒绝，按普通失败处理就行。11
james-6-23/codex2api 主干 admin/auto_reset_exhausted.go 第 58–78 行：第 66–68 行是新写的注释，第 69 行的判定只剩 credits.AvailableCount <= 0；后面那段注释说明只有 7d 长窗口消耗券，5 小时窗口与 Spark 的模型级窗口都不算。新加的用例按现场数据搭：账号 DBID 528、套餐
self_serve_business_prolite。发行版没动。v3.1.1 的第 66 行仍是两个字段并列。12
所以今天在 v3.1.1 上的实例，自动那条路照旧不会触发。手动这条路是通的，按顺序做：
- 在日志里搜
[auto-reset-credits] 扫描完成，看candidates与consumed两个数。 candidates=0就去面板点「重置额度」→「确认重置」，接口是POST /api/accounts/:id/reset-credits。13- 成功会打一行
windows_reset=，数值大于 0 说明窗口真的被清零了。14
价格：v3.1.1 还在按列的位置读
#812 改的是官方价格的解析。3
补丁里的注释写明了变动：2026 年 10 月，OpenAI 把 output 挪到 cached input 前面，又加了 30 分钟与 12 小时写入两列。3
补丁自带的测试夹具给了一个具体例子。按旧下标读，
gpt-6-astra 会得到 output 12.5、cached 50；那张表里 12.5 是 30 分钟写入价，50 是输出价，真实的输出是 50、缓存读取是 1。3夹具是合成的，线上表有没有已经变成这个形状，得你自己核。假如对得上，缓存读取会按 50 倍计，输出只按四分之一计。
james-6-23/codex2api v3.1.1 的 proxy/official_model_pricing.go 第 213–234 行：第 223–228 行六个字段全部按下标取，第 219 行只挡住列数不足 9 的行。这段就是发行版里正在跑的读法。#818 在同一窗口跟上，把校验和回退补齐。4
现在的顺序是：先校验官方页面结构，失败或缺价就按模型依次回退 LiteLLM、models.dev、项目默认 JSON，最后用内置默认价；管理员手工价始终优先。4
校验里有一条正好卡住这次的事故：缓存读取价不得高于对应的输入价。4
今天能做的：打开价格面板，看
gpt-6-astra 与 gpt-6-sol 的缓存读取价是不是远高于输入价。是的话，等带上这两个提交的版本发布后重跑一次同步；在那之前用分组价卡或手工价兜住。Antigravity：配额门禁默认就是开的
#817 是这批里最大的一张，67 个文件。5
它新增三个设置字段。
quota_refresh_enabled 缺省 true，quota_refresh_interval_minutes 缺省 60（读取时钳在 3 到 60 之间），quota_gate_enabled 缺省 true。16门禁是硬闸：配额事实判为 0（含过期事实）的账号直接不进选号，原因统一记成
quota_exhausted；非 Antigravity 账号不受影响。5两条止血路径是分开的。关
quota_gate_enabled 只停判定，不动已落库的事实。设置走 PUT 整体 JSON 合并，带单调递增的
config_revision，改完不用重启；多实例混布时，旧实例写回也不会把新字段抹掉。16升级后如果池子变小，先看是不是配额门禁挂的，再决定关开关还是清事实。
james-6-23/codex2api 主干 auth/antigravity_settings.go 第 18–48 行：第 20–24 行是间隔常量 3 / 60 / 60，第 36–44 行三个字段的注释各自写明「缺省 true」「缺省 60」「缺省 true」。两个开关：现在别开
#803 加的是 Codex Multi-Agent v2 的明文兼容层，默认关闭，开关是进程级环境变量
CODEX_MULTI_AGENT_V2_COMPAT，改完要重启。8文档把代价写在最前面：只要父请求匹配，父到子的任务消息都会以明文生成和传输，网关分不出子 Agent 是原生 OpenAI 还是第三方模型。17
还有两条：上游看到的是非标准
collaboration-optimize schema，可能按 reserved schema 拒绝，也可能触发账号风控；兼容层没有自动回退。17多实例处理同一批流量时，所有实例必须一起开或一起关。17
同一份文档第 5–25 行：「结论与边界」写明默认关闭、开启后明文、需要保留原生子 Agent 加密时不要开；「风险与适用账号」第一条写上游可能按 reserved/unknown schema 拒绝或触发风控，且没有自动回退。
另一笔是直接提交 0db88926：Go 从 1.26.9 升到 1.26.10，对应 GO-2026-6809，可达路径是
auth/utls_client.go 的 TLS 握手。同一笔里 vite 升到 8.3.5，修的那条只影响 dev server。9
v3.1.1 的
go.mod 与 Dockerfile 还是 1.26.9。自己从那个 tag 构建，用的仍是旧工具链。18剩下两张小改动
#819 让账号同步时把 Codex 能力快照一起落库，修的是新 OAuth 账号进共享组后推理档位变空。6 报障单 #816 写明了这条路径：新账号没有快照，共享组拉清单时又优先挑 DBID 更小的老账号，新账号那份始终补不上。19
#822 只放行一种 Responses 输入类型
configuration_update，之前带这个类型的请求会被输入校验挡下。7次条：sub2api 那张按张计费，被审出一个 P1
F1（P1）是钱：Composite 分组配了 token 价卡、又勾上按张计费时，经 Gemini 与 Antigravity 的生图计费会变成 $0。21
原因在分支顺序。开关打开后直接进
calculateImageCost，第一个分支只判来源是不是分组，没判计费模式；token 全为 0 时它返回 $0 和一个空错误，结果被直接采用。21分组里另外配了 1K/2K/4K 单价也救不回来，那个分支排在单价判断前面。21
F2（P2）是另一个方向。
n 到 1 的兜底不受开关控制，API Key 流式解析到 0 张时，原来基本不计费，现在按 1 张全价扣；上游截断、中途报错、只发 partial_image 就结束的流都算在内。21后面还有两条：渠道级 token 价卡下这个开关无效，两条管线语义不一致；混合请求里只要出过图，文本 token 就整段不计。21
维护者的处置是「先修 F1、F2 并补对应测试，F3/F4 建议一并处理」。21
这张单今天开不出效果：v0.2.18 里有 246，没有 247，也没有它要加的 248；发行页也仍是 v0.2.18。22
状态与额度
- codex-reset 首页写着今天 UTC 还没重置，最近一次已验证的全局重置在北京 10-23 01:10（41 小时前），累计 57 次、账上 10 张、节奏约每两天。23
- 同一站的 feed 最新帖停在 10-24 11:41，落在本窗口之前；10-22 那条「Lands tomorrow before 10am PST」仍是 pending。23
- opentherank 记的是 66 次、中位间隔 3 天、最长 68 天，页面更新到 10-24。24
- 上游三家：OpenAI 全绿，最近一条 CIMD 事件在北京 10-24 07:43 已恢复；25 Anthropic 全绿，页面在 15:09 更新过；26 Google Cloud 最近仍是 europe-west2 的 Multiple Products，最后更新在 10-23 00:19。27
- 另三个仓库窗口内没有新条目：CLIProxyAPI 的 dev 停在 14:43、main 停在 10-24 02:18；28 sub2api 的 main 停在 10-24 10:12；29 codex-proxy 的 dev 停在 10-23 03:54。30
- 四个仓库的发行版仍是：CLIProxyAPI v8.0.41（10-24 02:25）、31 sub2api v0.2.18（10-23 15:44）、22 codex-proxy v2.1.20（10-23 03:56）、32 codex2api v3.1.1（10-17 05:42）。1
- OpenAI 社区 Codex 分区最新帖在 10-24 09:46，落在窗口前；33 openai/codex 窗口内新开的都是客户端与权限类，没有额度相关。34
References
- 1codex2api v3.1.1 发行页
github.com
- 2PR #824
github.com
- 3PR #812
github.com
- 4PR #818
github.com
- 5PR #817
github.com
- 6PR #819
github.com
- 7PR #822
github.com
- 8PR #803
github.com
- 9提交 0db88926
github.com
- 10codex2api issue #823
github.com
- 11
- 12
- 13v3.1.1 admin/handler.go 第 1216 行
github.com
- 14
- 15
- 16
- 17
- 18v3.1.1 Dockerfile 第 22 行
github.com
- 19codex2api issue #816
github.com
- 20sub2api PR #8323
github.com
- 21维护者的审阅意见
github.com
- 22sub2api v0.2.18 发行页
github.com
- 23codex-reset
codex-reset.com
- 24opentherank
opentherank.com
- 25OpenAI 状态页
status.openai.com
- 26Claude 状态页
status.claude.com
- 27Google Cloud 状态页
status.cloud.google.com
- 28CLIProxyAPI dev 提交
github.com
- 29sub2api main 提交
github.com
- 30codex-proxy dev 提交
github.com
- 31CLIProxyAPI v8.0.41 发行页
github.com
- 32codex-proxy v2.1.20 发行页
github.com
- 33OpenAI 社区 Codex 分区
community.openai.com
- 34openai/codex 窗口内新开条目
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.