缓存 5 分钟与 1 小时分档进了 dev，Grok 429 的冷却还钉在 2→10→30→60 分钟 (2026)

这一小时（北京 10-29 18:35 到 20:09）四个仓库都没发新版本：CLIProxyAPI 停在 v8.0.47、sub2api 停在 v0.2.19、codex-proxy v2.1.21、codex2api v3.1.21 2 3 4。

CLIProxyAPI 的 dev 分支倒落了三次合并：18:38 的用量明细结构化、19:29 的 aistudio 帧重组、19:42 的 home 模式 websocket 限制5。

同一小时里，sub2api 开出一张把 Grok 429 冷却做成配置的 PR，还没合6。

所以今晚没有必须升级的动作。有两处读数值得先弄清楚：你的账本读得到哪一层，Grok 被关起来的那段时间听谁的。

账本：v8.0.47 只到聚合

请求日志里现在能记的 token，全在这个结构体里：输入、输出、推理、缓存命中、缓存读、缓存创建、合计，八个数都是整数。

代码编辑器里 tokenStats 结构体的八个整数型 token 字段 — *`internal/redisqueue/plugin.go` 第 228–237 行，v8.0.47 的请求日志只有这八个聚合字段7*

分档的东西一个都没有。在 v8.0.47 整包里搜 cache_details、tool_usage_details、cost_details、cache_creation_5m_tokens，命中数全是零；sdk/cliproxy/usage/ 目录下也没有 detail.go8。

dev 上 18:38 那笔（合并提交 eabcb1b，41 个文件 +5213/−541）先把结构加了出来9。

新增的 CacheDetails 把缓存写入按 TTL 分四档，另带一个 by_ttl 映射。

代码编辑器里 CacheDetails 结构：5 分钟、30 分钟、1 小时、12 小时四档字段与 by_ttl — *`sdk/cliproxy/usage/detail.go` 第 5–15 行；同一文件还给出服务端工具计数、`usage.iterations[]` 与成本明细10*

四档是 5 分钟、30 分钟、1 小时、12 小时。上游本来就把 5 分钟与 1 小时分开报，是这一版之前的解析只取了总量。

parseClaudeUsageNode 只读 cache_read_input_tokens、cache_creation_input_tokens 与输出、思考四个数11。

为什么这件事值得盯：两档单价不同。claude-opus-5-5 的缓存写入，5 分钟档每百万 5 美元，1 小时档 8 美元12。

只有聚合值时，你算出来的缓存成本一定偏向其中一边，而且自己看不出偏了。

今天怎么拆：要么从上游原始响应里取 ephemeral_5m_input_tokens 与 ephemeral_1h_input_tokens，要么去 sub2api 的 usage_logs 看那两列——它已经存了13。

两套账别混：CLIProxyAPI 记在请求日志，sub2api 记在数据库表里，口径与时间戳都不一致。

还有一处顺带的变化：记录里早就有 accounting_version 字段。这套明细上线后，跨版本对账要按版本分组，否则一次口径调整就把趋势打断了。

aistudio：下午那条 502 的修法进了 dev

下午我们写过这条：gemini-3.6-flash 走 aistudio，一帧被切成四块，末帧的 finish_reason 落在碎块里被丢掉，客户端最后收到一条 50214。

v8.0.47 的写法是「块内切帧」：每个中继块交给 splitRelayFrames 切成帧，再逐帧翻译。块与块之间没有缓冲，一帧跨块就断15。

19:29 合入的修法换了结构：执行器改用一个带状态的 RelaySSEBuffer，没写完的帧留在缓冲里等下一块16。

代码编辑器里 RelaySSEBuffer 的定义与 Feed 方法：pending 缓冲、前缀判定、按空行切帧 — *`helps/relay_sse_buffer.go` 第 5–40 行，合并提交 265ca179 新增；`Feed` 保留未完成帧，`Finish` 冲最后一帧17*

三个细节决定它能不能用。裸 JSON 的中继消息不切，格式化过的多行 JSON 也整条放过；一帧写满却没有结尾空行时由 Finish() 补上；收尾流程里先冲缓冲再结束，最后一帧不漏。

那张单在 19:52:21 由 hkfires 关成 completed14。

今天仍要绕：v8.0.47 里没有这个文件。gemini-3.6-flash 继续别走 aistudio，按 provider 摘掉它，或换 gemini-3.5-flash-lite。

Grok 429：冷却还是五个常量

sub2api v0.2.19 里，Grok 429 之后关多久由五个常量决定：兜底 2 分钟、重复 10 分钟、持续 30 分钟、上限 1 小时、静默期 1 小时18。

升级条件写在同一个文件里：上一次冷却结束后一小时内再撞 429 才升级，而且按上一次冷却长度选下一档。

代码编辑器里 grokRateLimitResetAtForAccount 与随后的 switch：静默期比较与三档阶梯 — *`grokRateLimitResetAtForAccount` 第 1784–1814 行：静默期一小时内重复 429 才踩阶梯，按上一次冷却长度选下一档19*

于是 2 分钟之后是 10 分钟，再撞是 30 分钟，再撞就是 1 小时。只有一个号的池子，会被一次抖动带到最长那一档。

两个边界值得记住。这套阶梯只对 OAuth 号生效，isGrokOAuthAccount 要求 platform 是 grok、type 是 oauth20。

池模式账号根本不装账号级冷却，命中后只打一行 grok_pool_mode_error_state_skipped 就返回21。

两个现成入口为什么都不管用。账号级「临时不可调度规则」在这条路上没有匹配入口：整个文件只读取 TempUnschedulableUntil 字段，没有调用规则匹配。

tempUnscheduleGrok 只用于 401（10 分钟）、402（30 分钟）、403（30 分钟）与 5xx（2 分钟）。后台的「429 默认回避」走通用 handle429，Grok 自己处理错误，不经过它。

PR #8418（北京 19:11 开、14 个文件 +649/−40、一个提交、评论只有 CLA）把这五个常量换成八个配置键6。

代码编辑器里 GatewayGrokRateLimitConfig 的说明注释与八个 mapstructure 键

gateway.grok.rate_limit.* 的八个键与逐条说明，来自 PR 头分支的 backend/internal/config/config.go 第 1179–1210 行22

默认值一个字都不改行为：兜底 120 秒、阶梯 600/1800/3600、静默 3600、最短冷却 0、手动恢复 false；环境变量是 GATEWAY_GROK_RATE_LIMIT_*。

两个键值得单独看。min_cooldown_seconds 是所有 429 冷却的下限，连上游给的 Retry-After 与额度窗口 reset 一起抬；要「429 之后至少歇一天」就写 86400，校验上限 30 天。

manual_recovery 在网关真收到 429 时顺手把调度关掉，等人来开。冷却本身照写，所以提前开调度仍然守上游的 reset。

它同时回应两类相反的诉求。#4808（7 月开、仍开着）要大号池「429 后至少歇 24 小时或人工恢复」；小号池与单账号要的正好相反，关掉升级，别把整个平台推到 1 小时23。

状态：open、未合并、mergeable_state 是 unstable、零人工评审。就算合了，也要等下一次 sub2api 发版。

今天怎么手工处理：被推到 1 小时后，用面板的「清除限流」或 POST /api/v1/admin/accounts/:id/clear-rate-limit24。

这个接口清三列——rate_limited_at、rate_limit_reset_at、overload_until，还顺带清临时不可调度、模型级冷却与 403 计数25。

想预判会不会升级，看那两列的时间差就够：上一次冷却 ≥10 分钟，下一次是 30 分钟；≥30 分钟，下一次就是 1 小时。

今晚四步

版本先确认：v8.0.47 与 v0.2.19 都没变，今晚没有必须升级的动作。
对账别按分档算：CLIProxyAPI 侧只有聚合值，要拆 5 分钟与 1 小时，去上游原始响应或 sub2api 的 usage_logs。
aistudio 上 gemini-3.6-flash 继续绕开，等下一版带上帧重组。
Grok 429 后先看那两列时间差；要立刻恢复就清限流，别让一个号被一次抖动推到 1 小时。

窗口内另外两件小事

home 模式下 AI Studio 的 websocket 网关不再注册。19:42 合入的那笔让 AttachWebsocketRoute 在 home 模式直接返回，同时把 ws 鉴权强制打开26。

配置键是 oauth.providers.aistudio.ws-auth，示例文件默认 true；home 模式不看这个值，一律按开处理27 28。

影响很直接：home 模式实例升级后 /v1/ws 不存在，别在那里指望 aistudio 的 ws 中继。

sub2api 两张修单在 19:04 关闭，合并标记都是 false：一张修 Anthropic 工具改名后引用没对齐29，一张修更新检查把 build metadata 当版本差异30。

关闭不等于合并，别把它当已修。

上游这边干净：OpenAI 与 Anthropic 状态页全绿、没有降级组件，Google Cloud 最近一条仍是 10-28 早上的 europe-west231 32 33。

codex-reset 显示今天 UTC 尚未重置，最近一次已验证的全局重置在 30 小时前，累计 61 次、10 张 banked34。

References

1
CLIProxyAPI Releases
github.com
2
sub2api Releases
github.com
3
codex-proxy Releases
github.com
4
codex2api Releases
github.com
5
CLIProxyAPI dev 提交记录
github.com
6
PR 8418
github.com
7
plugin.go 第 228–237 行
github.com
8
usage 目录 at v8.0.47
github.com
9
合并提交 eabcb1b
github.com
10
detail.go 第 5–24 行
github.com
11
parseClaudeUsageNode
github.com
12
模型价目表
github.com
13
usage_log.go 第 150–160 行
github.com
14
issue 7093
github.com
15
splitRelayFrames
github.com
16
合并提交 265ca179
github.com
17
relay_sse_buffer.go 第 5–40 行
github.com
18
openai_gateway_grok.go 第 27–31 行
github.com
19
openai_gateway_grok.go 第 1784–1814 行
github.com
20
isGrokOAuthAccount
github.com
21
handleGrokAccountUpstreamError
github.com
22
config.go 第 1179–1210 行
github.com
23
sub2api 4808
github.com
24
ClearRateLimit
github.com
25
account_repo.go 第 2618–2635 行
github.com
26
合并提交 d30edd7f
github.com
27
service_config.go 第 340–350 行
github.com
28
config.example.yaml 第 1094–1098 行
github.com
29
PR 8330
github.com
30
PR 8331
github.com
31
OpenAI Status
status.openai.com
32
Claude Status
status.claude.com
33
Google Cloud Status
status.cloud.google.com
34
Codex Reset
codex-reset.com