Grok 自动停调阈值补丁开出：账单接进来了，接线只维持十分钟

补丁加了两条候选

主干 backend/internal/service/account_scheduling_threshold_eval.go 第 336–356 行：第 338–341 行的注释写「计费 7d/30d 窗口不参与停调」，第 346–353 行只有一个 window: "quota" 候选。

补丁分支 backend/internal/service/account_scheduling_threshold_eval.go 第 342–388 行：第 354 行的 IsGrokOAuth() 决定要不要读账单，第 376 行的 now.Sub(*observedAt) >= openAIProbeCacheTTL 就是十分钟那道闸。

这道闸要有人读用量才成立

主干 backend/internal/service/account_usage_service.go 第 1227–1241 行：grokBillingSnapshotNeedsRefresh 在第 1232 行先看 partial 与失败窗口，第 1240 行用同一个 openAIProbeCacheTTL 判旧。

响应头那条候选在请求路径上读不到

主干 backend/internal/repository/scheduler_cache.go 第 1336–1348 行：filterSchedulerExtra 的键表在第 1343 行以 "grok_billing_snapshot" 收尾；grok_sched_utilization 与 grok_sched_reset_at 整张表里都搜不到。

今晚的处置顺序

1. 先量一次真实用量。GET /api/v1/admin/grok/accounts/:id/quota 会走账单探测，把周、月两份结果写进 grok_billing_snapshot。1617
2. 逼近上限就关调度。POST /api/v1/admin/accounts/:id/schedulable，body 传 {"schedulable": false}。18
3. 额度回来再放开。同一个接口传 true；临时不可调度用 DELETE /api/v1/admin/accounts/:id/temp-unschedulable 单独清。19
4. 自己实现等价能力要补两样。照补丁加账单候选，同时给 POST /api/v1/admin/accounts/usage/batch 排一个五分钟一次的定时调用，body 传 {"account_ids": [...], "force": true}。少了后一样，十分钟的闸会把候选筛掉。20
5. 看日志判有没有生效。临时不可调度的原因 JSON 里有 window（7d 或 30d）、used_percent、threshold_percent、until_unix；日志键是 account_scheduling_threshold_temp_unschedulable。

次条：CLIProxyAPI 的 Kimi 文档草稿走在了随包目录前面

版本面与上游

• CLIProxyAPI v8.0.43（10-25 23:37 发布）26
• sub2api v0.2.18（10-23 15:44）27
• codex-proxy v2.1.20（10-23 04:10）28
• codex2api v3.1.1（10-17 05:46）29