10/15 夜间快报：图片的 1440 分钟额度窗口被当成 Codex 周额度，整个账号被自动停
补报 10 月 15 日 19:18 到 20:00（北京）：一次成功的图片请求会把 sub2api 账号的 Codex 周额度快照写成 1440 分钟，越过阈值整个账号就被暂停，文本额度还在也用不了；文里给出完整链路、两个今晚就能改的账号级开关，以及维护者对「发一句 hi 就限流」那条报障的关闭理由。
补报 10 月 15 日 19:18 到 20:00（北京）。四个仓库这一窗口都没有新版本，主干也没有新提交。窗口内开出一条新条目，另一条被维护者收口：新条目在 sub2api，收口的在 CLIProxyAPI。
结论与影响面
受影响的是 sub2api 上跑 OpenAI OAuth 账号、并且这台实例会走图片生成或图片编辑的部署。
一次成功的图片请求，就能把整个账号按「周额度用满」暂停掉。此时账号真实的文本周额度可能还剩很多。
今晚有两条动作：
- 这张账号只是偶尔出图、文本还要继续用的，给它的
extra加上auto_pause_7d_disabled: true。 - 想保留自动暂停、只把门槛抬高的，改账号级
auto_pause_7d_threshold，或者改全局默认。
自查只看一个字段：账号
extra 里的 codex_7d_window_minutes。这一格正常读出来是 10080；读出来是 1440，说明它已经被别的窗口的读数写进去了。主线：图片成功响应把账号级周额度写成 1440 分钟
报障在 19:22 开出，编号 #8117，现在开着、0 评论、没有标签，作者 ChengLone 1。
他遇到的情况是：图片生成或图片编辑成功返回之后，账号级 Codex 周额度的读数被一个 1440 分钟的窗口覆盖。读数越过 7d 的自动暂停阈值，整个账号就退出调度。
这条链路在 v0.2.16 上是五步
第一步在图片的转发处理里。成功分支拿这次响应的响应头去更新账号级 Codex 快照，守卫只有「账号是 OAuth、且不是 spark 影子账号」这一条 2。
第三步是分类。
Normalize() 决定这组数字算 5 小时额度还是周额度。只有 primary 一个窗口时，它按阈值分：primaryMins <= 360 归 5h，否则归 7d 4。1440 大于 360，于是被判成周额度。
backend/internal/service/openai_gateway_service.go，高亮段是第 175–188 行。两个窗口都知道时按大小分；只有 primary 窗口时，第 184 行的 primaryMins <= 360 决定它算 5h 还是 7d 4第五步是调度器。判定里唯一被读到的字段是
codex_7d_used_percent，codex_7d_window_minutes 只是被一起存下来 6。达到阈值，整个账号跳出调度，同账号的文本模型跟着一起停。读数还有两道作废的守卫：窗口重置时间已经过去，或者快照太旧，都不再据此暂停 7。两道守卫都跟窗口长度无关。
两处与报障人自述不同
他写「7d 自动暂停阈值为 98%」。本刊在 v0.2.16 里读到的全局默认阈值是
0，也就是不启用；它存在运维设置里 8，面板上也写明 0 表示不启用 9。所以 98% 是他自己实例上配的值，版本出厂时这一项留给运维自己填。他写明现场是「基于 v0.2.14 的下游定制部署」。本刊核实的是 v0.2.16 的源码链路，不是他现场跑的那一版。
第三处要分开说：图片端点的响应头真的会带回一个 1440 分钟的单一窗口，这是他在 3 个账号上的现场观察 1。本刊核到的是「这样的头进来之后会被怎么处理」这一层；那个响应头本身来自他现场的观察。
今晚就能改的两个开关
账号级
auto_pause_7d_threshold。账号上有值就优先于全局默认 11。全局默认走
PUT /api/v1/admin/ops/advanced-settings，改 openai_account_quota_auto_pause.default_threshold_7d。这个接口绑定整个对象，先把设置 GET 回来、只改这一个字段，再整体提交 12。写入时有一个坑。账号更新接口
PUT /api/v1/admin/accounts/:id 的 extra 是整体替换的 13。它只会自动保留一张白名单：quota_used、quota_daily_used、quota_daily_start、quota_weekly_used、quota_weekly_start、grok 计费、上游探测与费率同步、Ollama 与 OpenCode 的快照、自动重置信用状态。只提交新键，其余 extra 会被清掉。先把账号读回来、把键并进去，再整体提交。还有一个例外要记一句。账号如果开了「自动用卡」（auto reset credit），它自己的消费阈值判断在
auto_pause_7d_disabled 之前，不走这个开关 14。这类账号要按 credit 自己的设置处理。怎么判断自己这台有没有中
在账号
extra 里看两个字段：codex_7d_window_minutes 是 1440 还是 10080；codex_usage_updated_at 是不是刚好落在那次图片请求的时间上。报障人用的就是这个对照法。他在 3 个独立账号上，
codex_usage_updated_at 都跟成功的 /v1/images/generations 或 /v1/images/edits 请求时间对得上 1。登记：维护者把「发一句 hi 就限流」按信息不足关闭
这条报障 15:54 开出、19:43 关闭，状态是 closed、not planned，标签
question，作者 juicedong999 15。维护者 luispater 在关闭前回了一条：现有信息不足以判断这条限额提示来自上游 provider、来自 CLIProxyAPI 的凭证与冷却处理，还是来自 Claude 桌面客户端自己的重试逻辑 15。
他把要再报时该带的东西列全了：
- 确切版本或 commit，以及部署方式。
- 真正在服务
claude-sonnet-4-6的上游与凭据类型，是否配了多凭证轮换与冷却，脱敏后的config.yaml相关片段。 - 客户端的确切版本、连到 CLIProxyAPI 的地址与端点路径（例如
/v1/messages）、复现的确切时间与时区。 - 那一次请求附近的 CLIProxyAPI 服务端日志与请求日志，含上游 HTTP 状态码、上游错误正文、限流与
Retry-After响应头、请求 ID。 - 能区分是谁在重试的证据：完整
Rate limit reached. Retrying (attempt 2/10)流程的客户端日志或截图，以及最后是成功了还是重试耗尽。 - 复现范围：是不是每个全新会话都会、同一实例的其他模型与 provider 是不是一样、绕开那坨初始化上下文用一条最小的
curl打同一个模型会不会也回限流。
报之前把 token、
Authorization 头、cookie、API key、邮箱、手机号都脱掉 15。本刊此前登记过这条，当时在 v8.0.29 的源码里搜过
Rate limit reached. Retrying (attempt 2/10) 这句话。那句话是报障人从界面里抄下来的；维护者这一次把它列进了「说不清来自哪一侧」的一类。所以今晚照着这条提示去动代理配置，没有依据。要推进它，就按上面的清单留证据再报。
上游与社区：本窗口无新事件
Anthropic 状态页是 All Systems Operational，10 月 15 日那一栏写着 No incidents reported today 16。
Google Cloud 最近一条事件仍是 10 月 8 日到 9 日的 Cloud Storage 上传与写入延迟 17。
OpenAI 状态页仍是 Partial System Degradation，唯一事件仍是北京 10 月 15 日 01:00 标记的 Compliance API 成本数据延迟，窗口内没有新更新 18。
Codex 重置追踪两站口径一致。codex-reset.com 记最近一次已验证的全局重置在北京 10 月 15 日 14:13（6:13 AM UTC），24 小时概率 18%、48 小时 33%，模型置信度低，累计 54 次 19。opentherank 记北京 10 月 15 日 12:55（04:55 UTC），中位间隔 3.1 天 20。
社区侧这一窗口，三个板块里与额度、风控相关的帖子是 0 条。r/ClaudeAI 最新一条停在北京 19:02，r/GeminiAI 最新一条停在 18:46，两条都早于窗口起点 19:18。
r/OpenAI 窗口内开出两条，两条都落在闲聊与动手项目上：一条是标题「Well that escalated quickly」的图片帖 21，一条是把 1989 年的 Atari Portfolio 接上 OpenAI API 的动手项目 22。
OpenAI 官方开发者社区的 Codex 分区这一窗口没有新话题，订阅源最新一条停在北京 18:01 23。
本期未闭合项
- sub2api #8117：开着、0 评论，还没有修复 PR。下期先看有没有修复并进
main，再看会不会随版本发出。 - CLIProxyAPI #6652：已按信息不足关闭。除非带齐清单重开，本期不再跟。
- CLIProxyAPI #6657 与 #6658（vertex-api-key 的
base-url前缀）：PR 仍未合并、维护者未回应 24。 - 仍在跟的还有：CLIProxyAPI #6656、#6655 25、#6654、#6653；sub2api #8115 26、#8114、#8113；codex2api #789、#788；codex-proxy #874、#873。
- 版本侧：CLIProxyAPI 最新发行版仍是 v8.0.29 27，sub2api 仍是 v0.2.16 28。
dev上的 35af74f 与 7459255675 仍未随版本发出。
References
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16Claude Status
status.anthropic.com
- 17Google Cloud incidents.json
status.cloud.google.com
- 18OpenAI Status summary
status.openai.com
- 19Codex Reset Tracker
codex-reset.com
- 20Codex reset tracker
opentherank.com
- 21Well that escalated quickly
reddit.com
- 22
- 23Codex - OpenAI Developer Community
community.openai.com
- 24
- 25
- 26
- 27CLIProxyAPI Releases
github.com
- 28sub2api Releases
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.