10/16 中午续报：CLIProxyAPI 插件停用再启用后单核跑满，sub2api 在 HTTP 200 的流里丢掉过载换号、Grok 出口漏 created_at
10 月 16 日中午这五十来分钟里，CLIProxyAPI 插件停用再启用后会把一个 CPU 核跑满、sub2api 在 HTTP 200 的流里丢掉过载换号、Grokbuild 又报缺 created_at；四个仓库本窗口一个版本都没发。
北京 10 月 16 日 11:08 之后到现在这五十来分钟里，四个仓库一个版本都没发。
新开的几条单子指向同一类毛病：本地把上游的状态判错了。CLIProxyAPI 在一个进程里停用再启用插件，会有一个 CPU 核一直跑满。sub2api 上游在 HTTP 200 的流里发过载错误，本地不再换号重试。Grokbuild 那句
missing field 'created_at' 又回来了，补齐的代码还停在 PR 里。版本先说结论。CLIProxyAPI
v8.0.30、sub2api v0.2.16、codex-proxy v2.1.17、codex2api v3.1.0，四个仓库本窗口都没有新版本，也没有 PR 被合并。1234先看这几件事
- 四个仓库的版本都没动。 sub2api 主干多了一笔提交，但它只改了测试夹具，本窗口的报障一例都没修上。15
- 插件停用再启用一次，CLIProxyAPI 会有一个核跑满。 报障人在
v8.0.30（commit5be2cdab）上复现：同一个核心进程里卸载再加载插件之后，cli-proxy-api占满一个 CPU 核，再禁用也停不下来，只能重启进程。6 - HTTP 200 的流里，过载不再触发换号。 sub2api
v0.2.16的流事件分类只认response.created、response.in_progress、keepalive，上游在正文前发的response.queued、response.metadata被当成模型输出，后面的server_is_overloaded就进不了输出前的换号分支。78 - Grokbuild 缺
created_at的问题还修不了。 三个出口会送出没有这个字段的 Response 对象，修复 PR 开着没合并，主干也还没有这份实现。910 - codex2api 上
gemini-4-argon做工具调用会回 400。 缺的是thought_signature：v3.1.0里决定补不补这个签名的判定，只认 flash、pro、thinking 三个关键词。1112
插件停用再启用之后，CLIProxyAPI 会有一个核一直跑满
北京 11:21，CLIProxyAPI 上开了一张单子，作者 Roomen。6
环境是 macOS arm64、CLIProxyAPI
8.0.30（commit 5be2cdab）。插件 live-routes 是 Go 的 c-shared .dylib，这次从 v0.1.3 换到了 v0.1.5。6复现只要三步：起一个开了插件的核心；不重启，把插件停用再启用，或者更新到新版本；一分钟内 CPU 就上到 100%，并且一直不下来。6
日志只有两行：
11:18:37 [host.go:722] pluginhost: plugin unloaded plugin_id=live-routes version=0.1.5
11:18:39 [host.go:360] pluginhost: plugin loaded plugin_id=live-routes version=0.1.5第一次加载插件的核心不会这样。6
他抓到的现场是：只有一个线程忙，其中约 80% 是 system time。6
他的判断是：Go 的 c-shared 库没法安全
dlclose，运行时、线程和信号处理函数在 dlclose 之后还留在进程里。新加载的那份再往外转发信号，就撞上一个已经不可访问的旧地址，循环出不来。6本刊在读者正在跑的
v8.0.30 里把这条路径核了一遍。13卸载入口是
internal/pluginhost/host.go 第 650 行的 UnloadPluginContext，结束时打的正是日志里那句 pluginhost: plugin unloaded（第 722 行）。13重新加载在同一个进程里做热替换，第 352–358 行把被替换的实例收掉，第 360 行打出
pluginhost: plugin loaded。13只有「文件还加载着就想覆盖安装」这一支会告诉调用方要重启，
plugin_store.go 第 286 行回 plugin_update_requires_restart 和 restart_required: true。15删除插件是先试一次热卸载，卸载不掉才回
plugin_delete_requires_restart。16所以报障人那条路，也就是停用再启用或换插件版本，确实会在同一个进程里卸掉再装上。
v8.0.30 里没有「插件变更改为下次重启生效」这条路径。13他给的建议正是改成那种：插件的更新、停用、移除都在下次核心重启时生效，或者干脆自动重启核心。6
在那之前，跑过插件热重载的核心，重启一次是唯一能停掉这个忙线程的动作。6
HTTP 200 的流里，过载不再触发换号
北京 11:19，zenggang 开了一条改这个的 PR。7
他写的场景是：Responses 流在模型真正输出之前，会先发
response.queued 或 response.metadata。后者在实测里带着 openai_chatgpt_moderation_metadata 这样的审核信息。7也就是说，HTTP 状态码本身判断不了这一单成没成。7
问题出在本地的事件分类。
v0.2.16 的 backend/internal/service/openai_gateway_passthrough.go 第 1087–1094 行，只把 response.created、response.in_progress、keepalive 当元事件。8分类之外的事件名走「按输出处理」那一支，调用点在同文件第 1194、1272 行。17
结果就是 PR 里写的那两句：这两个事件被当成语义输出，本次尝试被提前固化，随后到来的降载错误进不了已有的输出前重试与换号流程。7
它们还可能让语义首 token 耗时提前起算，并解除首输出超时保护。7
修法只往元事件名单里加这两个确切的名字，重试次数、账号调度和其它错误分类都不动。7
PR 现在 open、mergeable clean，3 个文件 +15/−1，未合并。7
作者说三个相关回归在没改业务代码的基线
455d317d 上会失败，打完补丁才通过。7Grokbuild 又报缺 created_at，补齐还停在 PR 里
上一期登记过的那张单，开在 10 月 15 日 20:29（北京），作者 yonghumeijj，跑的是
v0.2.16。9他贴的报错是一句：
Couldn't read the response: serialization error: missing field `created_at`. Try sending again.他自己补了一句：这个问题之前解决过，
0.2.16 后又来了。9北京 11:23 开出的 PR #8140 把这条链补全了。10
PR 说明给的判断是：
#5601 当时只修了 apicompat 的两座桥（Chat→Responses、Anthropic→Responses）的合成路径。10它还列了三个仍在漏字段的出口：
buildOpenAIResponseFailedSSE（主流与透传）、buildOpenAIWSHTTPBridgeFailedEvent（WebSocket 到 HTTP 桥），以及 Grok 账号挂在不发 created_at 的上游后面时逐字节转发的流式、WS、非流式出口。10本刊在
v0.2.16 里把前两个出口的合成结果核了一遍。18buildOpenAIResponseFailedSSE 在 backend/internal/service/openai_gateway_response_handling.go 第 1831 行。它拼出来的 response 对象只有 id、object、status、output、error，有 model 时再加 model，没有 created_at。18WS 到 HTTP 桥的
buildOpenAIWSHTTPBridgeFailedEvent 在同仓 openai_ws_http_bridge.go 第 372 行，对象字段一样，顶层 sequence_number 写的是 0。19修法 PR 也给了：合成的终止帧取本条流的上游
created_at，没有就取当前时间。新文件 openai_responses_created_at.go 负责给出站的 Response 对象补字段。10主干这边有个容易看错的地方。5
它的提交说明写的是「网关现会为缺 created_at 的 Response 对象补齐该字段（#8118）」。5
实现并不在主干：新文件
openai_responses_created_at.go 在 main 上取不到，把主干整包拉下来也搜不到 responsesCreatedAtStamper 这个类型。5这份补齐逻辑目前只在 PR #8140 的分支上。10
所以
v0.2.16 上再看到这句报错，要等的是 #8140 合并。10按 PR 的说法，Grok 那几条路径是「上游本身不发 created_at 时逐字节转发」。缺不缺这个字段，取决于你后面挂的是哪家上游。10
codex2api 上 gemini-4-argon 做工具调用会回 400
北京 11:43，codex2api 上来一张单，作者 Likhixang。影响面他自己选的是「核心功能受影响，但有绕法」。11
现象是：用
gemini-4-argon 做函数调用、跑多轮工具循环，上游回 HTTP 400。11Function call is missing a thought_signature in functionCall parts.同一套工具循环换成
gemini-3.8-flash 完全正常。11根因他自己定位在
proxy/antigravity_responses.go 的 antigravityGeminiNeedsToolSignature：模型名里带 gemini，且含 flash、pro、thinking 三个词之一，才给工具调用补签名。12
v3.1.0 的 proxy/antigravity_responses.go，高亮段是第 928–947 行：第 934–937 行是那个判定函数，匹配的词只有 flash、pro、thinking。12同文件第 940–946 行的
antigravityGeminiSupportsFunctionTools 只排除了 2.5 系列和一个 gemini-3.1-flash-lite。gemini-4-argon 不在排除名单里，所以工具会被桥接过去、调用也会发出去，缺的只是那一个签名。12这张单现在 open、0 评论，codex2api 本窗口没有其它条目更新。11
本窗口的其它条目
sub2api 上还有三条，都只到登记的程度。
#7688 处理的是：智谱这类 Coding Plan 在额度没耗尽时也会因频率限制回 429，而现在的逻辑会冷却到长窗口重置，也就是小时级，生产上直接不可用。21这条单 9 月 29 日就开了，本窗口 11:35 被作者重基到当前主干。21
改法是频率型 429 改为秒级短退避，接近耗尽的额度仍冷却到下一个窗口重置。21
作者在说明里写「生产侧比较急」，目前运维要靠自己出私有镜像（例如
0.2.9-cn429）才能用。21#8141 还是 draft：Antigravity OAuth 加 gemini-3.8-flash-high 的多轮工具对话，在调用方的 system 指令要求每批工具前先给一句进度说明时，仍然只回 functionCall、没有正文。22它提的是针对这个显式契约的窄化兼容策略，作者说先等维护者看完再转正。22
#8142 改的是管理端账号页刷新后平台、状态两个筛选被重置的问题，改成存进 localStorage 并在首次列表请求前恢复校验。23跟踪清单本窗口没有条目关闭或合并。CLIProxyAPI 这边是 #6669、#6671、#6659、#6665、#6666、#6667、#6661，sub2api 这边是 #8135、#8136、#8121、#8127、#8125、#8123、#7962，加上本期的 #8140、#8139、#8141、#8142，codex2api 是 #790、#792，全部 open。6711
上游与额度核对
OpenAI 状态页仍是 Partial System Degradation，唯一降级的组件还是 Compliance API，本窗口没有新更新。24
那条事件最后一条更新停在 10 月 15 日 22:36:42Z，也就是北京时间 10 月 16 日 06:36 的 monitoring。25
Anthropic 状态页是 All Systems Operational，10 月 15 日写的是当天没有事件。26
Google Cloud 的 incidents.json 里，最近一条仍是 10 月 8 日到 9 日的 Cloud Storage 上传与写入延迟。27
Codex 这边，今天 UTC 到目前为止没有发生重置。最近一次已验证的全局重置是 22 小时前，即 10 月 15 日 6:13 UTC（北京 14:13）。28
同一页记的累计数是 54 次全局重置、10 次 banked，节奏约每 4 天一次。28
模型给的 24 小时重置概率是 18%、48 小时 33%，置信度 Low。28
opentherank 那站仍记 10 月 15 日 04:55 UTC、62 次、中位间隔 3.1 天。29
社区侧本窗口没有可收的条目。开发者社区 Codex 分区的最新一条停在 10 月 15 日 21:20:44Z，在窗口之前。30
r/OpenAI 窗口内只有两条新帖，一条问怎么当 OpenAI 的独立顾问并拿返佣，一条是配图闲聊，都不是额度或风控条目，按本刊的排除规则不收。
References
- 1Sub2API 0.2.16
github.com
- 2CLIProxyAPI v8.0.30
github.com
- 3codex-proxy v2.1.17
github.com
- 4codex2api v3.1.0
github.com
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24OpenAI Status
status.openai.com
- 25Delayed Costs data in the Compliance API
status.openai.com
- 26Anthropic Status
status.anthropic.com
- 27Google Cloud incidents.json
status.cloud.google.com
- 28Codex Reset Tracker
codex-reset.com
- 29Will Codex reset today? · OpenTheRank
opentherank.com
- 30Codex · OpenAI Developer Community
community.openai.com
- 31r/ClaudeAI 窗口内最新一条
reddit.com
- 32r/GeminiAI 窗口内最新一条
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.