10/19 凌晨续报：插件后端的模型清单不再报 400；Gemini 响应翻译不再每块重读整份请求 (2026)

10 月 19 日北京 00:11 到发稿这一小时，四个仓库都没有新的稳定版。CLIProxyAPI 停在 v8.0.33，sub2api 停在 v0.2.171 2。

codex-proxy 停在 v2.1.18，codex2api 停在 v3.1.13 4。

动的是分支。CLIProxyAPI 的 dev 在 00:23 与 00:55 各落一笔，main 仍停在 21:05 的 v8.0.33 提交5 6。

sub2api 的 main 停在 10 月 16 日 12:42，codex2api 停在 10 月 17 日 05:35，codex-proxy 的 dev 停在 10 月 18 日 18:467 8 9。

所以这一小时里有代码进账的只有 CLIProxyAPI，两笔都还没进发行版。

今晚可以先做这三件事

用 CLIProxyAPI、且装了插件 provider 的：面板里那三处模型选择器还是空的，继续手输模型 ID。修好的那笔只在 dev。
用 Gemini 或 Antigravity 上游跑 /v1/responses 的：抓一次 pprof，看 gjson.ValidBytes 与两个工具映射函数的占比。补丁也在 dev，现在没有开关。
用 sub2api 的：分组档位那张 PR 还开着，别照它的字段提前改库。它带一个迁移 246。

插件后端的模型清单，v8.0.33 还是回 400

面板要拿某个通道的模型清单，走的是 GET /v8/management/routing/model-definitions/:channel，路由注册在 server_management_v8.go 第 33 行10。

v8.0.33 里这个 handler 只查内建通道的静态表。查不到就返回 400 unknown channel，整个函数只有 33 行11。

静态表里只有十个通道：claude、gemini、vertex、aistudio、codex、kimi、antigravity、xai、devin、meta12。

插件贡献的 provider 一个都不在表里，例如 qoderwork、workbuddy、trae、zcode、lobster、officeace12。

受影响的是面板三处：OAuth 模型别名编辑器、OAuth 排除名单、凭证页的排除名单。三处都会退化成「这版不支持取模型列表」12。

插件模型名往往不好猜，比如 qwen3.8-flash-QoderWork，手输很容易出错12。

v8.0.33 的 model-definitions handler 只有静态表这一条路 — `CLIProxyAPI` v8.0.33 的 `internal/api/handlers/management/model_definitions.go` 全文 33 行：第 23 行取静态表，第 24 行判 `models == nil`，第 25 行直接返回 `unknown channel`。整份文件里没有插件宿主，也没有全局注册表的分支。11

自查一句就够：带上你的管理密钥请求 GET /v8/management/routing/model-definitions/qoderwork。回 unknown channel 就是 v8.0.33 这一版；返回模型数组，说明已经在带修复的构建上。

修复是 dev 上的 50cfd2380：作者 Luis Pater，提交时间 00:23:19，2 个文件 +186/−1，提交信息里写着 Closes: #673613。

改法三步。第一，空切片也走回退——判定从 models == nil 换成 len(models) == 014。

第二，回退先问插件宿主 ModelsForProvider(channel)，拿不到再问全局注册表 GetAvailableModelsByProvider(channel)14。

第三，注册表这条路上，多于一个模型时按 ID 升序排，同一个通道每次返回的顺序都一样14。

插件宿主那句调用，是在 h.mu 里取出指针、放锁之后才调的，不会把插件调用按在管理端全局锁上14。

dev 版先问插件宿主，再问全局注册表 — dev 版同文件第 26–29 行改判空切片并调用回退，第 40–65 行是 `pluginModelDefinitionsByChannel`：第 43–45 行在锁内只取指针，第 48 行先问插件宿主，第 52 行才落到全局注册表，第 53–63 行只对注册表这份排序。14

还没修的两处也值得知道：插件宿主返回的那份没有排序；通道名仍然只认注册过的 provider，其余照旧 40014。

想要它就两条路：把这一笔打上自己编译，或者等它并进 main 再发版。v8.0.33 的 main 停在 21:05，这一笔不在里面。

每块响应都重读一遍整份请求

#6741 在 19:05 开出，作者 JohnsonRan，正文第一句就写明与 #6665 同类15。

ConvertGeminiResponseToOpenAIResponses 每收到一个上游块就跑一次。它的第一行是 reqJSON := pickRequestJSON(...)，位置在 if *param == nil 之外16。

pickRequestJSON 会对整份请求体跑一次 gjson.ValidBytes。请求 500 KB、一条流 500 块，这个校验就跑 500 次15。

工具映射也在重算。两个映射函数在没有需要处理的工具名时返回 nil，于是每一块都满足 == nil，每一块重建一次16。

代价是 O(请求大小 × 块数)。作者的 profile 里，这三个函数在 gjson.ValidBytes 上占掉 55.7 秒中的 0.4 秒15。

基准更直白：1 MiB 请求、64 个增量块，Responses 从 66.8 毫秒降到 4.4 毫秒，Chat Completions 从 33.3 降到 0.6815。

走这条路的执行器不止一个：Antigravity 的 Responses 流共用同一个转换器，Chat Completions 那条有同类的 SanitizedNameMap 重建15。

CLIProxyAPI v8.0.33 的 internal/translator/gemini/openai/responses/gemini_openai-responses_response.go：第 287 行是转换函数入口，第 288 行先取请求体，第 289 行才开始判 *param == nil——取请求体这一步落在所有块上，不只第一块。16

修复是 dev 上的 5de9de9ae24：00:55:46，4 个文件 +181/−22，Closes: #674117。

Responses 那条加了三个状态位：RequestJSON、RequestResolved、ToolMapsResolved。请求体只在建状态时取一次，之后都读 st.RequestJSON17。

Chat Completions 那条加了 SanitizedNameMapResolved，nil 映射也算「已解析」，不再每块重来17。

连 determineWebSearchStreamMode 也改成接收取好的 reqJSON，只在自己没有时才取17。

v8.0.33 里这些字段一个都没有，pickRequestJSON 仍在外层每块执行一次16。

没有开关可关。能做的两件：给大请求体加并发上限；抓一次 pprof，确认这一项在自己流量里的占比。

sub2api 把「强制 Fast」改成四档下拉

#8203 在 00:18:36 开出，作者 stl25，49 个文件 +1022/−267，基于 main，Fixes #8201，现在 open、mergeable unstable18。

它解决现状的两处别扭。v0.2.17 的分组只有一个布尔 force_openai_fast。打开后，该分组里 OpenAI 账号的请求一律被写成 priority，客户端传的 ultrafast 也盖掉19。

另一处是没有「强制 Standard」。想让整组按 Standard 走，只能靠客户端都不传档位20。

改法是把布尔换成字符串 forced_service_tier：空串跟随请求，default 强制 Standard，priority 强制 Fast，ultrafast 强制 Ultra Fast21。

强制值先写进请求体，之后仍要过全局 Fast/Flex 策略。全局设成 filter 会删掉它，设成 block 会返回 40318。

Ultra Fast 不是无条件的：只有 gpt-6-astra（含 gpt-6 别名与后缀）、gpt-6.1-sol、gpt-5.6-sol 会被写成 ultrafast，其余模型按客户端原值透传21。

强制档位与三款模型的判定写在同一处 — PR 头分支 `stl25/sub2api` @ `codex/group-forced-service-tier` 的 `backend/internal/service/openai_gateway_request_body.go` 第 2046–2076 行：第 2050 行是新的 `openAIGroupForcedServiceTier`，第 2059 行起是档位分支，第 2073 行 `openAIModelSupportsForcedUltrafast` 只认 astra、`gpt-6.1-sol` 与 `gpt-5.6-sol`。21

计费两件事。gpt-6.1-sol 的 Ultra Fast 倍率补成 6 倍；v0.2.17 那处 6 倍只挂在 astra 上21。

另一件是新增独立开关 free_openai_ultrafast：打开后 Ultra Fast 按 Standard 价计费，与原来的「免费 Fast」互不影响21。

这一条最该盯：Ultra Fast 的上游成本更高，PR 说明里写着「开启免费前确认利润」18。

库表改动是迁移 246：加 forced_service_tier（默认空串）与 free_openai_ultrafast（默认 false），并把 force_openai_fast = true 的分组回填成 priority22。

v0.2.17 目前的最后一个迁移是 245，246 是这张 PR 新加的23。

认证快照版本从 24 升到 25，部署后旧快照失效、按新字段重建18。

回滚要小心：退回旧二进制后，升级期间改过档位的分组不会同步回旧字段18。

这些都还没合并。别照着 PR 里的字段提前改库：没有迁移 246，那一列就不存在；有了迁移再退回旧二进制，行为又会对不上。

上期三件事的进展

凭证那份修复 7484a5216a 仍只在 dev。v8.0.33 的 clients.go 搜不到 incompleteRescanPaths，dev 版有五处24 25。

死锁补丁 #6748 仍 open，窗口内没有新提交26。分词 memoize 的 #6751 也仍 open、mergeable clean27。

窗口内另有一条：#6558（pluginapi 暴露配置字段默认值）在 00:51:59 被关闭，未合并28。

上游与额度

OpenAI 全绿、活动事件 029。最近三条已解决事件仍是 10 月 14 日 Compliance API 成本数据延迟（10 月 16 日 18:44 解决）、10 月 15 日的大范围功能降级、10 月 14 日两个图像模型的可用性30。

Anthropic 全绿，10 月 18 日无事件31。GCP 仍是 7 条，最近一条停在 10 月 8 日到 9 日的 Cloud Storage32。

Codex 侧今天 UTC 仍未重置。最近一次已验证的全局重置是北京 10 月 18 日 04:41，约 20 小时前；24 小时 21%、48 小时 37%，置信度 Low33。

同一页写着最近 7 天 Tibo 没有新提示，也没有官方的重置窗口公告33。OpenTheRank 记的是 63 次、中位 3.1 天、最长 68 天34。

官方开发者社区 Codex 分区窗口内 0 条新话题，最新一条停在 23:55 的图像分辨率问题35。

Reddit 窗口内只有这些：r/ClaudeAI 00:33 一条「Claude 打不开 Reddit」，r/GeminiAI 00:40 的 Argon vs Sonnet、00:44 的地标海报；r/OpenAI 窗口内 0 条，最新停在 23:3436 37 38。

未闭合

#6736 何时并进 main、随哪一版发出；#8203 评审会不会动 6 倍倍率；#8201 会不会随 PR 一起关；#6734 的凭证修复还要在 dev 待多久；「每块重读整份请求」在这个仓库里还有没有第三处。

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
CLIProxyAPI main 提交时间轴
github.com
7
sub2api main 提交时间轴
github.com
8
codex2api main 提交时间轴
github.com
9
codex-proxy dev 提交时间轴
github.com
10
v8.0.33 server_management_v8.go 第 33 行
github.com
11
v8.0.33 model_definitions.go 第 14–33 行
github.com
12
CLIProxyAPI issue #6736
github.com
13
dev 提交 50cfd2380
github.com
14
dev 版 model_definitions.go 第 26–65 行
github.com
15
CLIProxyAPI issue #6741
github.com
16
v8.0.33 gemini_openai-responses_response.go 第 287–350 行
github.com
17
dev 提交 5de9de9ae24
github.com
18
sub2api PR #8203
github.com
19
v0.2.17 openai_gateway_request_body.go 第 2046–2100 行
github.com
20
sub2api issue #8201
github.com
21
PR #8203 全量补丁
patch-diff.githubusercontent.com
22
迁移 246
github.com
23
v0.2.17 backend/migrations
github.com
24
v8.0.33 clients.go
github.com
25
dev clients.go
github.com
26
CLIProxyAPI PR #6748
github.com
27
CLIProxyAPI PR #6751
github.com
28
CLIProxyAPI PR #6558
github.com
29
status.openai.com summary
status.openai.com
30
status.openai.com incidents
status.openai.com
31
Anthropic Status
status.anthropic.com
32
Google Cloud Status incidents
status.cloud.google.com
33
codex-reset.com
codex-reset.com
34
opentherank Codex Reset
opentherank.com
35
OpenAI 开发者社区 · Codex 分区 RSS
community.openai.com
36
r/ClaudeAI
reddit.com
37
r/GeminiAI
reddit.com
38
r/OpenAI
reddit.com