Kimi 并发 403 从停调 10 分钟改成 5 秒冷却——改动只在主干，v0.2.19 照旧
sub2api 主干 58 秒并入 6 张修复，Kimi 并发 403 从停调 10 分钟改成 5 秒短冷却；但四仓本窗口零发版，v0.2.19 仍是旧行为，今晚能做的只有配规则与救号。
今天 17:11，sub2api 主干在 58 秒里并进了 6 张单1。
其中一张是 Kimi 并发上限 403 的改法：从「停调 10 分钟」改成「按 429 短冷却」2。
四个仓库今天都没有发版，你手上的 v0.2.19 仍是发行版3。
所以这篇只解决一件事：今晚要不要动手，以及拿什么口径判断。
六张单，一行一张
| 单号 | 改了什么 | 今晚的意义 |
|---|---|---|
| #8503 | Kimi 并发 403 改走 429 短冷却 | 号池不再被连锁停光 |
| #8499 | 透传放行空 instructions | 少一类本地 403 |
| #8465 | Grok 的 agent_message 归一 | 少一类 502 |
| #8318 | 中和 system 里的 GPT 身份声明 | 切模型不再直接 429 |
| #8436 | 导出 CSV 撞 429 后重试同一页 | 导出不再中断 |
| #8462 | 生图账号按 1K/2K/4K 分流 | 面板今天还看不到 |
六行有一个共同点：都只在主干，v0.2.19 一行都没带上。
发行版的发布时间是 10 月 28 日 18:16（北京），距今一周。
主线：8 个号怎么被一句 403 停光
#8502 把现场写得很完整：Kimi Coding Plan，8 个号同组，单号并发 54。
并发一满，上游回 403。每个号都被标成临时不可调度，池子逐个变空。
池空之后，新请求拿到的是 503，而错误日志里账号和上游状态码都是空的。
修复合入主干 3 秒后，维护者把这张单关成 completed，没留评论。
v0.2.19 里的两条 403 路
第一条是专属分支：命中 Kimi 那句并发上限原文，就临时停调 10 分钟5。
命中的条件是整句原文相等：「You've reached your concurrent request limit」后面那半句也一字不差。
差一个词就不再命中。没命中的 403 继续往下走。
第二条路是兜底：平台不是 Antigravity、也不是 OpenAI 兼容号时，直接落到通用 4036。
通用 403 走的是 handleAuthError：把账号标成 error，并且要人工恢复。
所以同一个 403，一边是「等 10 分钟」，另一边是「等人来救号」。
这是本期最该记住的一条：风险不在 403 本身，在于你命中了哪条分支。
合进去的改法只动了一行
主干里同一个函数只剩一行：改走 429 兜底冷却7。
429 兜底的默认值是 5 秒，可设区间夹在 1 到 7200 秒之间8。
从 10 分钟到 5 秒，池子恢复的时间差了两个数量级。
有一个细节容易看漏：把这条 429 兜底关掉，路径不是「不冷却」，而是「什么都不记」9。
实现里关闭时只打一条日志就返回，账号状态一个字段都不写。
判据也没改：仍然要求那句原文整句相等。
所以升级之后，措辞一变，这个 403 还是会落到下面的通用分支。
今晚在 v0.2.19 上能做的三件事
第一，给 Kimi 号配一条临时不可调度规则：状态码 403，关键词 concurrent request limit。
这条规则的优先级有前提：池模式且没开自定义错误码时，才会先试规则；否则整段跳过、什么都不记。
规则命中之后是短时停调，不是主干里那个 5 秒，但至少不会把号打进 error。
第二，号已经被标成 error 时，用 recover-state，而不是只点 clear-rate-limit。
三个接口在同一条路由分组里，动作范围不一样10。
recover-state 一次做完：清 error、清限流与临时不可调度、把 403 计数归零11。
clear-error 只清 error（OAuth 号会顺带失效 token 缓存），clear-rate-limit 只清限流和各处临时状态、完全不动 error。
第三，别在面板里调 429 冷却指望拦住 Kimi 的 403：v0.2.19 这条并发分支根本不读那个设置。
同批另外五张，各一句
#8499 删掉了透传里的空 instructions 拦截：Codex 协议账号没带 instructions 时，v0.2.19 会回本地 403；合入后放行，并把客户端原值回显回去12。
#8465 把 Grok Responses 里的 agent_message 转成普通消息：不转的话上游 422，客户端只看到 50213。
#8318 针对的是切模型就 429：system 里那句 GPT 身份声明会被上游认出来，现在只中和开头一句14。
#8436 是纯前端：导出每页 1000 条，撞面板限流后按 Retry-After 等几秒重试同一页15。
#8462 让生图账号按 1K/2K/4K 分流，缺省或三档齐全等于不限；面板今天还没有这个字段16。
窗口内新开的两条，知道就行
#8513 怀疑 Native Responses 的 WS 后续轮在 429 换号时重放首请求，上下文和工具被静默丢掉；作者自述没做成端到端复现17。
#8514 是另一条链路：/v1/chat/completions 打到 Pie 的 /v1/messages，请求里没有 session ID，回 400；同一个缺口也影响原生 /v1/messages18。
两条都还没人修，也都没有人回。
其余三仓与上游
CLIProxyAPI 停在 v8.0.53，codex-proxy 停在 v2.1.23，codex2api 停在 v3.1.3，三个仓库今天都没有新版本19。
CLIProxyAPI 那张「把上游流读完、让连接复用」的单还开着，这个窗口里没有新代码20。
Codex 额度今天 UTC 还没重置，最近一次是 10 月 28 日 14:35（北京）24。
也就是说，这一轮额度已经跑了七天，今天没有新的重置可等。
今晚的结论
如果你是 Kimi 号池的运维：先配那条 403 规则，再查一遍有没有号已经被标成 error。
如果你跑的是别的平台：这六张单今天都不影响你，等下一次发行再动。
如果你在等上游重置：今天没有，最近一次是七天前。
References
- 1sub2api main 分支提交记录
github.com
- 2sub2api PR 8503
github.com
- 3sub2api v0.2.19 发行页
github.com
- 4sub2api issue 8502
github.com
- 5
- 6
- 7main 分支同名函数
github.com
- 8v0.2.19 的 429 兜底默认值
github.com
- 9v0.2.19 的 429 兜底实现
github.com
- 10v0.2.19 的账号恢复路由
github.com
- 11v0.2.19 的 RecoverAccountState
github.com
- 12sub2api PR 8499
github.com
- 13sub2api PR 8465
github.com
- 14sub2api PR 8318
github.com
- 15sub2api PR 8436
github.com
- 16sub2api PR 8462
github.com
- 17sub2api issue 8513
github.com
- 18sub2api issue 8514
github.com
- 19CLIProxyAPI 发行页
github.com
- 20CLIProxyAPI PR 7237
github.com
- 21OpenAI 状态页
status.openai.com
- 22Anthropic 状态页
status.claude.com
- 23Google Cloud 状态页
status.cloud.google.com
- 24codex-reset 追踪站
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.