10/16 下午续报：v0.2.17 补的 created_at 管不到 model，grokbuild 又报缺字段；Codex 用量上限的冷却仍没有上界
10 月 16 日午后这不到一小时里，sub2api 上一张新单指出 v0.2.17 补的 created_at 兜底管不到 model、同一个 grokbuild 客户端照旧报缺字段，另有一条把 Codex 用量上限冷却外推到好几天的老问题今天又被重基了一次、仍未合并。
10 月 16 日北京 13:55 到 14:50，sub2api、CLIProxyAPI、codex-proxy、codex2api 四个仓库都没有发新版本，主干也没有新提交。
这五十来分钟里有两件事值得处置。
第一件：v0.2.17 刚补上的
created_at 兜底只管一个字段，同一个客户端已经报出第二个缺字段。第二件：Codex 凭证被上游 429 里一个好几天后的时间点钉住的问题，修它的 PR 今天又重基了一次，仍未合并。
一、v0.2.17 补的 created_at 管不到 model
sub2api issue #8147 在北京 14:11 开出，作者 yonghumeijj5。
正文只有两行：grokbuild 报
Couldn't read the response: serialization error: missing field \model``，版本 0.2.17。这张单 0 评论、无标签，时间线里除了开单没有任何事件，还没有人回应5。
同一位作者昨天也报过一次，走的是同一个客户端。
那张是 #8118，标题写着「Grokbuild 又报 serialization error: missing field
created_at」，正文留下的是「这个问题之前解决过 0.2.16 后又来了」6。#8118 在昨天北京 20:29 开出，今天北京 12:28 关闭；关闭时间正好落在 v0.2.17 发出来的那几分钟里，0 评论，没有维护者回复6。
v0.2.17 的发行说明确实修了它。Bug 修复里的第一条就是「修复 Responses 对象缺少 created_at 导致 grok-build 等客户端反序列化失败的问题」7。
修法值得看一眼。这一版为 created_at 单开了一个文件，注释写得很直白：严格的 Responses 客户端（Rust serde：grok-build、Codex）把
Response.created_at 声明为必填，官方上游总会给，但 Grok 订阅前面的第三方网关和网关自己合成的终止帧不一定给。所以凡是离开网关的 Response 对象，缺这个字段就补上8。
补写用的时间戳由网关自己取，所以上游漏了这个字段时它照样补得上。
backend/internal/service/openai_responses_created_at.go 第 1–24 行（提交 bdfe215）：注释自己点名 grok-build 与 Codex，而这次兜底只覆盖 created_at 一个字段8model 没有同款兜底。v0.2.17 整包里，Responses 帧上写 model 的地方只有两处，两处都是条件写。第二处在合成失败帧的构造函数里，写法是
if model = strings.TrimSpace(model); model != "" 才写进 response。调用方没传非空值，帧里就没有 model10。同一个构造函数里，
created_at 是无条件写死的。两个字段的差距就在这一行判断上。这条报障没有日志，本刊不能替它定性是哪一帧丢了字段。能确定的是：v0.2.17 里没有任何一处会在一帧缺 model 时把它补上。
所以升级改变不了这一类错，你这边也没有可改的配置。等报障人补上 log，或者等一个像 #8140 那样的修复 PR 再动5。
二、Codex 用量上限的冷却没有上界
CLIProxyAPI 收到 Codex 的 429
usage_limit_reached 时，会读 error body 里的 resets_at 或 resets_in_seconds，直接换算成冷却时长。v8.0.31 的
parseCodexRetryAfter 对这两个值没有加任何上界，读到多少就钉多久11。
internal/runtime/executor/codex_executor_terminal.go 第 405–446 行：resets_at 与 resets_in_seconds 直接换算成 retryAfter 返回，全函数没有上界比较11PR #5764 的作者在生产里抓到过这个。一条 429 带着
resets_in_seconds: 244741，约合 68 小时，凭证就被排进 68 小时后的凭证级冷却。4 小时 52 分后他手动重启进程，内存里的冷却被清掉，下一个请求当场成功12。
如果凭证真的被封了 68 小时，那个请求应当再吃一次上游 429。它当场就通了，可见 body 里写的那个重置时间，并没有对应到真正卡住这张凭证的那段配额。
PR 的做法是给
parseCodexRetryAfter 加一个固定上限 6 小时，留出余量盖住约 5 小时的主窗口12。真被封就重试拿一个新的 429 和一段新的限时；其实已经可用，这一次就通了。
在那之前，v8.0.31 里今天能动的有三处。
routing.cooldown.save-cooldown-status默认 false，冷却只存内存，重启即清。上面那次恢复就是这么来的，代价是一并清掉其他账号的冷却13routing.cooldown.disable-cooling打开后全局不再排冷却，代价是失败状态没有隔离窗口13upstream.codex.model-level-cooling打开后，Codex 的usage_limit_reached冷却只作用于被请求的那个模型，不再波及同一凭证下的其他模型14
上限本身还没有。PR #5764 从 9 月 12 日开到现在仍未合并，作者今天北京 14:10 又把它重基到 dev 的最新提交上，补丁逐笔未变12。
三、其它条目
sub2api #8149：升级后服务起不来，12 分钟后被作者自己关掉。
这张单在北京 14:34 开出，正文只有「RT.」；北京 14:45 以 completed 关闭，0 评论，没有日志，也没有维护者回应15。
这张单不够定性。但 v0.2.17 里确实有一条会让进程直接起不来的配置校验：
Config.Validate() 在 gateway.min_output_tokens 小于 16 时返回错误，服务在初始化阶段就退出16。这个键是 v0.2.17 新增的，默认 128，最低 1617。
如果你的 config.yaml 把它显式写成了 0 或更小的值，升级后会以这条错误拒绝启动。除此之外，先看启动日志的最后一行和进程退出码，再看数据库迁移有没有跑完。
CLIProxyAPI #6675：只改测试，与生产无关。
这张 PR 在北京 13:51 开出，1 个文件 +16/−10。它把两个 shutdown 用例从「关停后拨一下端口」改成等
server.Start 返回。原因是全量
go test ./... 时别的包可能抢到刚释放的端口，让用例假失败18。CLIProxyAPI #6605：认证文件原子写仍未合并。
v8.0.31 里
sdk/auth/filestore.go 第 140 行仍是 os.OpenFile(path, os.O_WRONLY|os.O_TRUNC, 0o600)，原地截断再写；PR 新增的 internal/atomicfile 包不在这个版本里19。读者侧的现实是：认证文件被重写的那一刻，watcher 可能读到空文件或半个文件。备份这个目录，并避免对它并发写。
四、上游与额度侧
Codex 重置追踪站今天 UTC 仍未重置。最近一次已验证的全局重置是 25 小时前的 10 月 15 日 06:13 UTC，累计 54 次全局重置、10 次 banked，节奏约每 4 天一次20。
同一页面上并存两套概率：模型口径 18% / 33%，把提示帖计进去的 counted 口径是 24 小时 50%、48 小时 75%20。
另一个追踪站仍记 10 月 15 日 04:55 UTC、自 2025 年 9 月以来 62 次、中位间隔 3.1 天21。
OpenAI 状态页仍是 Partial System Degradation，唯一降级组件还是 Compliance API，最后一条更新停在 10 月 15 日 22:36 UTC 的 monitoring22。
Anthropic 状态页 All Systems Operational，10 月 16 日一栏写着 No incidents reported today23。
Google Cloud 的事件列表最近一条仍是 10 月 8 日到 9 日的 Cloud Storage24。
OpenAI 开发者社区 Codex 分区的最新一帖停在 10 月 16 日 04:22 UTC，讲模型偶尔用随机语言回答，与额度风控无关25。
五、未闭合项（下期继续跟，不作结论）
- sub2api：本窗口新登记 #8147、#8149；继续跟 #8146、#8144、#8134、#8143、#8141、#8139、#8136、#8135、#8127、#8125、#8123、#8142、#7962
- CLIProxyAPI：本窗口新登记 #6675；继续跟 #6605、#5764、#6661、#6667、#6659、#6669、#6671、#6673、#6625、#6603
- codex-proxy、codex2api：本窗口内 0 条
下期优先回看三条：① #8147 有没有等到维护者定性，
model 会不会像 created_at 那样被做成无条件补写；② #5764 的 6 小时上限有没有随版本发出；③ #8149 有没有人补上日志重开。References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5sub2api #8147
github.com
- 6sub2api #8118
github.com
- 7Sub2API 0.2.17
github.com
- 8openai_responses_created_at.go 第 11–21 行
github.com
- 9
- 10
- 11codex_executor_terminal.go 第 424–445 行
github.com
- 12CLIProxyAPI #5764
github.com
- 13config.example.yaml routing.cooldown 段
github.com
- 14config.example.yaml upstream.codex 段
github.com
- 15sub2api #8149
github.com
- 16config.go Validate
github.com
- 17config.go 默认值
github.com
- 18CLIProxyAPI #6675
github.com
- 19sdk/auth/filestore.go 第 140 行
github.com
- 20codex-reset.com
codex-reset.com
- 21opentherank
opentherank.com
- 22OpenAI Status
status.openai.com
- 23Claude Status
status.anthropic.com
- 24Google Cloud Status
status.cloud.google.com
- 25Codex 分区 RSS
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.