Grok 订阅账号的自动停调阈值从不触发：v0.2.18 读的两个键，一个恒为 0、一个从没写入
Grok 订阅账号的自动停调阈值在 sub2api v0.2.18 上从不触发：判定只读两个由响应头派生的键，而 xAI 不给有效读数，本文给出三处源码、现场判据与今晚的处置顺序。
今天晚上 19:49 开出的那张单把一件事说穿了：Grok 订阅账号设了自动停调阈值，计费周用量到 89%、92%、甚至 100%，账号照旧被调度。1
直到上游回 429 才停。运维日志里一条
account_scheduling_threshold_temp_unschedulable 都没有。1我们在 v0.2.18 的源码里把这条链走了一遍，三处都对得上：判定只认两个 extra 键，这两个键只有一个写入点，写入点还要求上游给出一个未来的 reset 时间。
报障人的订阅账号上，xAI 返回的响应头恰好两样都不给。
影响面是配了阈值、指望它防打爆的 Grok 池。同一窗口还有三张单：两张围着 Grok 的可诊断性，一张是 Setup Token 的用量显示。
阈值这条链在 v0.2.18 上断在哪
判定入口是
EvaluateAccountSchedulingThreshold，按平台分派。2允许设阈值的平台有八个：OpenAI、Anthropic、Grok、Kimi、Zhipu、MiniMax、OpenCode Go、Command Code。3
Grok 那一支走
grokThresholdCandidates，候选只有一个。两个字段直接取自两个 extra 键。4这两个键是
grok_sched_utilization 与 grok_sched_reset_at。函数上方的注释写得很直白：官方计费的 7d/30d 窗口不参与这里的自动停调。
V0.2.18 的
backend/internal/service/account_scheduling_threshold_eval.go 第 336–358 行：候选的 usedPercent 与 until 都来自 account.Extra，注释写明计费窗口不参与自动停调。这两个键只有一个写入点：
buildGrokSchedulerExtraUpdates。5利用率按 (1 − 剩余/上限) 计算，取请求与 Token 两个窗口里更高的那个。reset 只在非空、且晚于当前时刻时才写入，写入时按 25 小时封顶。6
同版本
backend/internal/service/openai_gateway_grok.go 第 1895–1925 行：第 1916 行的 reset.After(now) 是写入 grok_sched_reset_at 的唯一条件，注释里写着过去值与无效值直接不写。三个条件在订阅账号上同时落空。
报障人存下来的四个限流头，值是 8300/8300 与 53000000/53000000，并且没有
x-ratelimit-reset-*。1剩余恒等于上限，利用率算出来是 0。没有 reset，
grok_sched_reset_at 从不写入。他同一个部署里有 9 个 Grok OAuth 账号，抽样 5 个：计费周用量 100%、92%、89%、82% 的四个都在被调度，其中两个的账号级阈值覆盖设成了 95%，剩下那个 15%。
到 100% 的那个被上游 429 之后，账号才退出调度。
面板上它为什么看起来是能用的
Grok 出现在阈值设置允许的平台清单里，账号编辑页还有「账号自动停调阈值覆盖」。8
面板说明原文是「当账号当前原生用量窗口（OpenAI Codex/Anthropic 会话，或 Grok 请求/Token 利用率）达到该百分比时，Sub2API 会临时将其移出调度，直到窗口重置」。
计费探测还会用它回填用量页的 7d / 30d 进度条。调度那条链不读这个键。
现场判据很简单：计费用量贴近 100%，日志里从没出现
account_scheduling_threshold_temp_unschedulable，就是这条链断了。反过来，日志里出现过这条键，说明阈值在那个平台上生效。
同一路还有三张单
#8335 在 18:32 开出：上游明确回了「The model is currently at capacity due to high demand」，客户端拿到 HTTP 502 加一句
Upstream service temporarily unavailable。10429 触发冷却之后的 503，同样没说明这是冷却。
这一类走 1 分钟模型级冷却加换号，不做整号停调。
泛化发生在出口：上游原文留在运维记录的
upstream_error_message 里。判容量还是判账号，看前者。#8337 在 20:11 开出（PR，未合并）：Setup Token 账号在渠道监控与账号页「查询」两处只显示 5h，7d 丢了。12
账号页默认那条链路会读
passive_usage_7d_*，所以两边不一致。#8338 与 #8339 在 20:15、20:16 开出：前者是单，后者是 44 文件 +10230/−187 的 PR。13
它们把本地映射、上游目录、响应声明的模型分开显示，并补上原始响应模型的审计字段。
版本面
四仓窗口内零新版本：
- CLIProxyAPI v8.0.42（10-24 22:21 发布）14
- sub2api v0.2.18（10-23 15:44）15
- codex-proxy v2.1.20（10-23 03:56）16
- codex2api v3.1.1（10-17 05:42）17
16:22 与 16:24 先出现两笔与 Responses WebSocket 中断、零输出终态相关的提交；20:46 与 20:47 再各有一个合并提交。
#827 统一 Codex attestation，35 文件 +1247/−1050；#829 修 Responses WebSocket 中断，12 文件 +663/−50。
两条都还没发版，跑 v3.1.1 的实例上仍是旧行为。
#829 修的是生成期间发
response.interrupt 被回 400 unsupported websocket request type 的那条路。#827 让 Codex HTTP、Responses WebSocket 与 Live 的
X-Oai-Attestation 只用本项目自己生成的值，并放开了 Linux / Docker 宿主调用 ChatGPT Live。同一仓库的 #832（非流式 images 发 102，在 Nginx 下变成协议错误）仍开着。
CLIProxyAPI 有一条与凭据无关的 501。20
POST /v1/realtime/transcription_sessions 在 v8.0.42 上恒定回 501 realtime_capability_not_supported。
V8.0.42 的
internal/client/codex/live/capabilities.go 第 210–218 行：writeCapabilityNotSupported 把 http.StatusNotImplemented 与 realtime_capability_not_supported 写死在同一行。带有效客户端 key、配好 openai-compatibility 的实例一样是 501，换凭据换不出结果。20
报障人实测 OpenAI 官方也走不通这条 REST 路径，直连回 404。
API key 那边要的是
client_secrets 加 intent=transcription 的 WebSocket。另外，上一期报的 #6969（home 配置订阅断线后立刻重连、没有退避）在 19:30 并进了 dev，同样没发版。22
Google Cloud 仍是 8 条事故，最新一次更新停在 10-22。
Codex 重置那边也没有新帖，追踪站的最新一条仍停在 14:07，登记状态还是 pending。25
今晚的处置顺序
先别等这个阈值。响应头不带 reset 的 Grok 订阅账号上它不会响，把用量看护放到计费快照或外部巡检上。
要立即止损，先用
GET /api/v1/admin/grok/accounts/:id/quota 拉一次真实用量。26逼近上限就
POST /api/v1/admin/accounts/:id/schedulable 关掉该账号的调度，不要等 429。27收到泛化的 502 或 503，先去运维记录看
upstream_error_message，再判断是容量还是账号。打算自己打补丁，方向是给
grokThresholdCandidates 加一个基于计费快照的候选。1用量取
usage_percent、截止取 period_end，并用快照的抓取时间判断时效，避免拿旧数据误停。原有的响应头候选保留即可。到发稿 #8336 仍开着，没有对应的修复 PR。
References
- 1sub2api issue #8336
github.com
- 2
- 3同版本 domain_constants.go 第 134–147 行
github.com
- 4
- 5
- 6同文件第 1968–1972 行
github.com
- 7
- 8v0.2.18 settings.ts 第 447–451 行
github.com
- 9
- 10sub2api issue #8335
github.com
- 11
- 12sub2api PR #8337
github.com
- 13sub2api PR #8339
github.com
- 14CLIProxyAPI 发行记录
github.com
- 15sub2api 发行记录
github.com
- 16codex-proxy 发行记录
github.com
- 17codex2api 发行记录
github.com
- 18codex2api 合并提交 c592242f
github.com
- 19codex2api 合并提交 d94e6ccd
github.com
- 20CLIProxyAPI issue #6974
github.com
- 21v8.0.42 capabilities.go 第 210–218 行
github.com
- 22CLIProxyAPI 合并提交 cf4fc4e7
github.com
- 23OpenAI 状态接口
status.openai.com
- 24Claude 状态接口
status.claude.com
- 25Codex 重置追踪接口
codex-reset.com
- 26v0.2.18 admin 路由第 500–502 行
github.com
- 27同文件第 408–412 行
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.