v8.0.47 把 ts_ 换成 tsc_，402 那张单关了却没合入 (2026)

本窗口四个仓库里只有一个发了新版本。CLIProxyAPI v8.0.47 北京时间今天 08:27 挂出，上一版 v8.0.46 是昨晚 19:01，相隔 13 个半小时。1

配置不用动。v8.0.47 的 config.example.yaml 与 v8.0.46 逐字节相同，升级只换二进制。2

三处代码改动里只有一处会打到所有站：Gemini 转 Responses 的 tool search 记事前缀从 ts_ 换成 tsc_。另两处要插件自己在 schema 里声明能力位才生效。1

还有一件要单独处置：sub2api 那张 402 的单今天 09:08 关成「已完成」，配套 PR 没有合并。v0.2.19 里找不到对应的配置键。

一、这一版改了什么

v8.0.47 与 v8.0.46 之间是 5 个提交、27 个文件。发布对象在北京时间 07:03 建好，08:27 正式挂出。2

四个仓库里只有这一个发了版本，这就是它今天排在最前面的原因。

提交	实际变化	影响谁
`e324e481`	schema v7 起，前端鉴权 provider 可声明 `frontend_auth_provider_omit_body`，host 不再读、克隆、序列化整包请求体 3	装了这类插件的站，省下一份 body 的内存与 CPU
`0fe38224`	schema v8 插件可对原始请求体做字节区间补丁，能力位 `request_interceptor_patch_body_before` / `after`，方法 `request.patch_body_before` / `request.patch_body_after` 4	装了声明该能力插件的站
同一笔 `0fe38224`	双工 WebSocket 后续的 `response.create` / `response.append` / `response.steer` 也过 before-auth 与 after-auth 拦截器 5	走双工 WS 且装了请求拦截插件的站
`90c447d3`	Gemini → Responses 的 tool search item id 前缀改 `tsc_`，出口把历史里的 `ts_` 与无前缀 id 归一化 6	所有走 Gemini 转 Responses 的站

升级动作只有一步：换二进制。两端配置样例逐字节相同，没有要新增或改写的键。2

不在这一版的有三件：#7090 今天 08:21 关成 not_planned，#6902 08:27 关成 not_planned，PR #7091 仍开着。7 8 9

二、所有站都碰得到那一处：`ts_` 变 `tsc_`

报障原文是 Codex 侧回的 400：Invalid 'input[6].id': 'ts_call_4000860'. Expected an ID that begins with 'tsc'. 6

这张单昨天 01:39 开出，今天 08:26:50 关成完成，比发版早 23 秒，标签 Fixed。6

改法分两层。出口新增常量 codexToolSearchCallItemIDPrefix = "tsc"，在第 21 行。10

SanitizeCodexInputItemIDs 的 case "tool_search_call" 那一段在第 155–170 行，把 ts_ 开头的历史 id 改写为 tsc_，用的是 strings.CutPrefix(id, "ts_")。10

改写带重复与碰撞保护，同一个 tsc_ 已被占用时会另取一个。10

归一化挂在四条入口上：Codex 的 websocket 流式 907 行、websocket 执行 102 行、连接建立 180 行，以及请求组装 154 行。10

读者能感受到的是：客户端里已经存着旧 ID 的历史会话，升级后由出口改写，不必清缓存或重建会话。10

容易混的两张单独说清。PR #7091 做的是 /v1/models 保留显式能力元数据，跟这件事无关，仍开着；#7090 是另一件事，今天 08:21 关成 not_planned。7 9

Codex 输入项 ID 改写代码 — *`codex_input_ids.go` 第 148–175 行：`tool_search_call` 分支把 `ts_` 前缀切掉再补成 `tsc_`，这是历史会话在出口被修好的地方。10*

三、只对装了插件的站生效的两处

第一处是 schema v7 起前端鉴权可以不要请求体。插件声明 frontend_auth_provider_omit_body 之后，host 不再读、克隆、序列化整包 body。3

第二处是 schema v8 的原始请求体字节区间补丁。能力位在 internal/pluginhost/rpc_schema.go 第 21–45 行，拦截方法在 sdk/pluginabi/types.go 里同段给出。11

host 做单趟拼接，校验边界与重叠，再用 json.Valid 校验拼出来的结果，空改动直接复用原 body。12

这笔提交自己给出的动机是：JSON 加 Base64 的整包包装带来约 3.33 倍内存与 CPU 放大。12

两处都要插件自己声明。sdk/pluginabi/types.go 第 22–53 行的注释写明 v7 与 v8 都按插件声明生效，未声明或 schema 小于 7 的插件照旧收整包 body。13

配置侧没有开关。没装插件、或插件没声明能力位的站，这两处行为与 v8.0.46 一致。13

会改行为的是同一笔里的另一处：双工 WebSocket 的后续帧现在也走请求拦截器，v8.0.46 只拦首个 turn。5

代码在 codex_websockets_duplex.go 第 256–295 行的 interceptTurnPayload，第 256 行是「前后两个拦截器都为空就直接返回」。5

自查点：站里若有插件改写请求体、又走双工 WS，升级后翻一遍它的日志，看有没有对后续 response.append / response.steer 报错。5

双工 WebSocket 请求拦截入口 — *`codex_websockets_duplex.go` 第 256–295 行：`interceptTurnPayload` 在首个 turn 之后的每一帧上都会再跑一次，这就是这版多出来的调用。5*

四、402：单子关成完成，代码里没有

#8197 10 月 18 日中午开单，今天 09:08:48 关成 completed，一条评论。14

评论是报障人自己写的，原文一句：Closing issue as upstream work has been discontinued. 15

配套 PR #8198 同一分钟关掉，merged 为 false、merged_at 为空，改的是 3 个文件、+314/−1。16

结果是补丁一行没进主干。v0.2.19 与 main 的 backend/internal/config/config.go 都搜不到 payment_required_402_cooldown_minutes 与 PaymentRequired402。17

v0.2.19 发布于昨晚 18:16，早于关单，所以当前版本没有这条修复。18

现有行为三条，各一句：

池模式且没启自定义错误码时，规则未命中就打 pool_mode_error_skipped，本地状态一个字不改。19
非池模式的通用 402：国产通道、OpenCode Zen、Command Code 走可恢复的临时停调；OpenAI 的 deactivated_workspace 置 error；其余走 handleAuthError 写 SetError，要手工恢复。19
Grok 另有一份：402 直接 tempUnscheduleGrok 停调 30 分钟，池模式在更早处早退。20

能自己动手的只有一条：账号的 credentials.temp_unschedulable_rules。21

规则四个字段是 error_code、keywords、duration_minutes、scope。解析时四个缺任何一个，整条规则被丢弃。21

匹配在 ratelimit_service.go 第 2730–2755 行，把响应体前 64KB 转小写做子串匹配。19

这条规则在 pool_mode_error_skipped 之前生效，所以池模式下它是唯一的抓手。19

PR 正文写「充值或检测恢复后自动解除」，代码里只有到期时间，没有充值探测。按到期时间填 duration_minutes 才是能落地的写法。16

sub2api 池模式早退与规则先行 — *`ratelimit_service.go` 第 339–352 行：自定义规则在池模式早退之前先试一次，未命中才打 `pool_mode_error_skipped`。19*

五、另一条计量口径：流式输入被算两遍

#8407 今天 11:33 开单，0 条评论，模型是 claude-sonnet-5.5，上游是 Kiro 系。22

样本里 message_start 给 8,535，最终 message_delta 显式报 input_tokens 为 0、cache_read 为 4,004，记账结果是 8,535 加 4,004。22

v0.2.19 的两条解析路径都用「大于 0 才覆盖」这一条规则。第一条在 gateway_upstream_response.go 的 case "message_delta"，四个字段各要 ok && v > 0。23

第二条在 gateway_anthropic_passthrough.go 第 649–663 行，覆盖条件同样只看 v > 0。24

计费侧把输入 token 直接乘单价，缓存读另算一行，两笔都落在同一张单上。25

按报障人的样本，多算的是 8,535 个输入 token，再叠加 4,004 个缓存读。22

适用边界写清楚：只对「先给估算、最终显式报 0」的上游成立。非流式路径报障人已核过是对的。22

自查办法是抓一条流式响应，看 message_delta 里的 input_tokens。为 0 的那一类就会多记一份输入钱。23

流式用量解析的覆盖条件 — *`gateway_upstream_response.go` 第 1234–1262 行：`message_delta` 分支对四个用量字段都要求大于 0 才写回，显式报 0 的那一次因此被跳过。23*

六、封号与档位：三条社区自述

#8404 今天 09:29 开单，2 条评论。报障人说手上 20 个 Codex Pro 200 账号近期被封 2 个，附了截图，问怎么降低风控概率。26

两条回复分别是「才封 2 个那么少。。」和「为什么被封？」，都没给出措施。26

这条只有报障人自述，本刊没有独立证据，封号原因与比例都无从核。26

Antigravity 论坛 11:31 一条：第二个付费 Google AI Pro 账号几乎没用过 Antigravity，Gemini 4 Argon 的周额度显示 0%，重置倒计时在走而额度不动。27

11:32 另一条：Jio 18 个月促销档的「Google AI Pro」拿不到 Gemini 4 Argon、Carbon 与 Claude 5.5，被提示只对 Ultra 与付费 Pro 开放。28

两条都是单帖，发帖人不是官方身份，按自述登记。27

上期写过机理的那条 #7079（AI Studio 渠道 stream 回 400 PROXY_GENERATION_DISABLED）新增两条 me-too，02:48 与 03:42 各一条。标签仍是 pending，维护者没回。29

上游状态：OpenAI 全绿、0 个活动事件。30

Anthropic 最新一条仍是 Google Calendar connector，昨晚 20:05 已恢复，窗口内没有新事件。31

额度重置：codex-reset 说今天 UTC 还没重置，最近一次已验证的全局重置是北京时间昨天 14:35，累计 61 次、banked 10 次。32

opentherank 那边记的是 69 次、中位间隔 2.9 天，两站的统计口径本来不同。33

七、今天能做的三步

第一，换 v8.0.47：只换二进制，配置不动。装了请求拦截插件、又走双工 WS 的，升级后先翻一遍它的日志。2 5

第二，给余额敏感的 OpenAI 账号补一条 temp_unschedulable_rules：error_code 写 402，keywords 取上游余额文案，duration_minutes 按充值节奏，scope 按账号或模型。21

第三，抽查一条流式响应：message_delta 里 input_tokens 为 0 的，账单会比上游多一份输入钱。23

References

1
CLIProxyAPI v8.0.47
github.com
2
compare v8.0.46...v8.0.47
github.com
3
#7071
github.com
4
#7072
github.com
5
codex_websockets_duplex.go
github.com
6
#7084
github.com
7
#7090
github.com
8
#6902
github.com
9
PR #7091
github.com
10
codex_input_ids.go
github.com
11
rpc_schema.go
github.com
12
commit 0fe38224
github.com
13
types.go
github.com
14
#8197
github.com
15
作者关单评论
github.com
16
PR #8198
github.com
17
config.go
github.com
18
sub2api v0.2.19
github.com
19
ratelimit_service.go
github.com
20
openai_gateway_grok.go
github.com
21
account.go
github.com
22
#8407
github.com
23
gateway_upstream_response.go
github.com
24
gateway_anthropic_passthrough.go
github.com
25
billing_service.go
github.com
26
#8404
github.com
27
论坛帖 196609
discuss.ai.google.dev
28
论坛帖 196611
discuss.ai.google.dev
29
#7079
github.com
30
OpenAI 状态
status.openai.com
31
Anthropic 状态
status.anthropic.com
32
codex-reset
codex-reset.com
33
opentherank
opentherank.com

本窗口四个仓库里只有一个发了新版本。CLIProxyAPI v8.0.47 北京时间今天 08:27 挂出，上一版 v8.0.46 是昨晚 19:01，相隔 13 个半小时。1

配置不用动。v8.0.47 的 config.example.yaml 与 v8.0.46 逐字节相同，升级只换二进制。2

三处代码改动里只有一处会打到所有站：Gemini 转 Responses 的 tool search 记事前缀从 ts_ 换成 tsc_。另两处要插件自己在 schema 里声明能力位才生效。1

还有一件要单独处置：sub2api 那张 402 的单今天 09:08 关成「已完成」，配套 PR 没有合并。v0.2.19 里找不到对应的配置键。

一、这一版改了什么

v8.0.47 与 v8.0.46 之间是 5 个提交、27 个文件。发布对象在北京时间 07:03 建好，08:27 正式挂出。2

四个仓库里只有这一个发了版本，这就是它今天排在最前面的原因。

提交	实际变化	影响谁
`e324e481`	schema v7 起，前端鉴权 provider 可声明 `frontend_auth_provider_omit_body`，host 不再读、克隆、序列化整包请求体 3	装了这类插件的站，省下一份 body 的内存与 CPU
`0fe38224`	schema v8 插件可对原始请求体做字节区间补丁，能力位 `request_interceptor_patch_body_before` / `after`，方法 `request.patch_body_before` / `request.patch_body_after` 4	装了声明该能力插件的站
同一笔 `0fe38224`	双工 WebSocket 后续的 `response.create` / `response.append` / `response.steer` 也过 before-auth 与 after-auth 拦截器 5	走双工 WS 且装了请求拦截插件的站
`90c447d3`	Gemini → Responses 的 tool search item id 前缀改 `tsc_`，出口把历史里的 `ts_` 与无前缀 id 归一化 6	所有走 Gemini 转 Responses 的站

升级动作只有一步：换二进制。两端配置样例逐字节相同，没有要新增或改写的键。2

不在这一版的有三件：#7090 今天 08:21 关成 not_planned，#6902 08:27 关成 not_planned，PR #7091 仍开着。7 8 9

二、所有站都碰得到那一处：`ts_` 变 `tsc_`

报障原文是 Codex 侧回的 400：Invalid 'input[6].id': 'ts_call_4000860'. Expected an ID that begins with 'tsc'. 6

这张单昨天 01:39 开出，今天 08:26:50 关成完成，比发版早 23 秒，标签 Fixed。6

改法分两层。出口新增常量 codexToolSearchCallItemIDPrefix = "tsc"，在第 21 行。10

SanitizeCodexInputItemIDs 的 case "tool_search_call" 那一段在第 155–170 行，把 ts_ 开头的历史 id 改写为 tsc_，用的是 strings.CutPrefix(id, "ts_")。10

改写带重复与碰撞保护，同一个 tsc_ 已被占用时会另取一个。10

归一化挂在四条入口上：Codex 的 websocket 流式 907 行、websocket 执行 102 行、连接建立 180 行，以及请求组装 154 行。10

读者能感受到的是：客户端里已经存着旧 ID 的历史会话，升级后由出口改写，不必清缓存或重建会话。10

容易混的两张单独说清。PR #7091 做的是 /v1/models 保留显式能力元数据，跟这件事无关，仍开着；#7090 是另一件事，今天 08:21 关成 not_planned。7 9

三、只对装了插件的站生效的两处

第一处是 schema v7 起前端鉴权可以不要请求体。插件声明 frontend_auth_provider_omit_body 之后，host 不再读、克隆、序列化整包 body。3

第二处是 schema v8 的原始请求体字节区间补丁。能力位在 internal/pluginhost/rpc_schema.go 第 21–45 行，拦截方法在 sdk/pluginabi/types.go 里同段给出。11

host 做单趟拼接，校验边界与重叠，再用 json.Valid 校验拼出来的结果，空改动直接复用原 body。12

这笔提交自己给出的动机是：JSON 加 Base64 的整包包装带来约 3.33 倍内存与 CPU 放大。12

两处都要插件自己声明。sdk/pluginabi/types.go 第 22–53 行的注释写明 v7 与 v8 都按插件声明生效，未声明或 schema 小于 7 的插件照旧收整包 body。13

配置侧没有开关。没装插件、或插件没声明能力位的站，这两处行为与 v8.0.46 一致。13

会改行为的是同一笔里的另一处：双工 WebSocket 的后续帧现在也走请求拦截器，v8.0.46 只拦首个 turn。5

代码在 codex_websockets_duplex.go 第 256–295 行的 interceptTurnPayload，第 256 行是「前后两个拦截器都为空就直接返回」。5

自查点：站里若有插件改写请求体、又走双工 WS，升级后翻一遍它的日志，看有没有对后续 response.append / response.steer 报错。5

四、402：单子关成完成，代码里没有

#8197 10 月 18 日中午开单，今天 09:08:48 关成 completed，一条评论。14

评论是报障人自己写的，原文一句：Closing issue as upstream work has been discontinued. 15

配套 PR #8198 同一分钟关掉，merged 为 false、merged_at 为空，改的是 3 个文件、+314/−1。16

结果是补丁一行没进主干。v0.2.19 与 main 的 backend/internal/config/config.go 都搜不到 payment_required_402_cooldown_minutes 与 PaymentRequired402。17

v0.2.19 发布于昨晚 18:16，早于关单，所以当前版本没有这条修复。18

现有行为三条，各一句：

池模式且没启自定义错误码时，规则未命中就打 pool_mode_error_skipped，本地状态一个字不改。19
非池模式的通用 402：国产通道、OpenCode Zen、Command Code 走可恢复的临时停调；OpenAI 的 deactivated_workspace 置 error；其余走 handleAuthError 写 SetError，要手工恢复。19
Grok 另有一份：402 直接 tempUnscheduleGrok 停调 30 分钟，池模式在更早处早退。20

能自己动手的只有一条：账号的 credentials.temp_unschedulable_rules。21

规则四个字段是 error_code、keywords、duration_minutes、scope。解析时四个缺任何一个，整条规则被丢弃。21

匹配在 ratelimit_service.go 第 2730–2755 行，把响应体前 64KB 转小写做子串匹配。19

这条规则在 pool_mode_error_skipped 之前生效，所以池模式下它是唯一的抓手。19

PR 正文写「充值或检测恢复后自动解除」，代码里只有到期时间，没有充值探测。按到期时间填 duration_minutes 才是能落地的写法。16

五、另一条计量口径：流式输入被算两遍

#8407 今天 11:33 开单，0 条评论，模型是 claude-sonnet-5.5，上游是 Kiro 系。22

样本里 message_start 给 8,535，最终 message_delta 显式报 input_tokens 为 0、cache_read 为 4,004，记账结果是 8,535 加 4,004。22

v0.2.19 的两条解析路径都用「大于 0 才覆盖」这一条规则。第一条在 gateway_upstream_response.go 的 case "message_delta"，四个字段各要 ok && v > 0。23

第二条在 gateway_anthropic_passthrough.go 第 649–663 行，覆盖条件同样只看 v > 0。24

计费侧把输入 token 直接乘单价，缓存读另算一行，两笔都落在同一张单上。25

按报障人的样本，多算的是 8,535 个输入 token，再叠加 4,004 个缓存读。22

适用边界写清楚：只对「先给估算、最终显式报 0」的上游成立。非流式路径报障人已核过是对的。22

自查办法是抓一条流式响应，看 message_delta 里的 input_tokens。为 0 的那一类就会多记一份输入钱。23

六、封号与档位：三条社区自述

#8404 今天 09:29 开单，2 条评论。报障人说手上 20 个 Codex Pro 200 账号近期被封 2 个，附了截图，问怎么降低风控概率。26

两条回复分别是「才封 2 个那么少。。」和「为什么被封？」，都没给出措施。26

这条只有报障人自述，本刊没有独立证据，封号原因与比例都无从核。26

Antigravity 论坛 11:31 一条：第二个付费 Google AI Pro 账号几乎没用过 Antigravity，Gemini 4 Argon 的周额度显示 0%，重置倒计时在走而额度不动。27

11:32 另一条：Jio 18 个月促销档的「Google AI Pro」拿不到 Gemini 4 Argon、Carbon 与 Claude 5.5，被提示只对 Ultra 与付费 Pro 开放。28

两条都是单帖，发帖人不是官方身份，按自述登记。27

上期写过机理的那条 #7079（AI Studio 渠道 stream 回 400 PROXY_GENERATION_DISABLED）新增两条 me-too，02:48 与 03:42 各一条。标签仍是 pending，维护者没回。29

上游状态：OpenAI 全绿、0 个活动事件。30

Anthropic 最新一条仍是 Google Calendar connector，昨晚 20:05 已恢复，窗口内没有新事件。31

额度重置：codex-reset 说今天 UTC 还没重置，最近一次已验证的全局重置是北京时间昨天 14:35，累计 61 次、banked 10 次。32

opentherank 那边记的是 69 次、中位间隔 2.9 天，两站的统计口径本来不同。33

七、今天能做的三步

第一，换 v8.0.47：只换二进制，配置不动。装了请求拦截插件、又走双工 WS 的，升级后先翻一遍它的日志。2 5

第三，抽查一条流式响应：message_delta 里 input_tokens 为 0 的，账单会比上游多一份输入钱。23

References

1
CLIProxyAPI v8.0.47
github.com
2
compare v8.0.46...v8.0.47
github.com
3
#7071
github.com
4
#7072
github.com
5
codex_websockets_duplex.go
github.com
6
#7084
github.com
7
#7090
github.com
8
#6902
github.com
9
PR #7091
github.com
10
codex_input_ids.go
github.com
11
rpc_schema.go
github.com
12
commit 0fe38224
github.com
13
types.go
github.com
14
#8197
github.com
15
作者关单评论
github.com
16
PR #8198
github.com
17
config.go
github.com
18
sub2api v0.2.19
github.com
19
ratelimit_service.go
github.com
20
openai_gateway_grok.go
github.com
21
account.go
github.com
22
#8407
github.com
23
gateway_upstream_response.go
github.com
24
gateway_anthropic_passthrough.go
github.com
25
billing_service.go
github.com
26
#8404
github.com
27
论坛帖 196609
discuss.ai.google.dev
28
论坛帖 196611
discuss.ai.google.dev
29
#7079
github.com
30
OpenAI 状态
status.openai.com
31
Anthropic 状态
status.anthropic.com
32
codex-reset
codex-reset.com
33
opentherank
opentherank.com

v8.0.47 把 ts_ 换成 tsc_，402 那张单关了却没合入

一、这一版改了什么

二、所有站都碰得到那一处：`ts_` 变 `tsc_`

三、只对装了插件的站生效的两处

四、402：单子关成完成，代码里没有

五、另一条计量口径：流式输入被算两遍

六、封号与档位：三条社区自述

七、今天能做的三步

References

Related content

v8.0.47 把 ts_ 换成 tsc_，402 那张单关了却没合入

一、这一版改了什么

二、所有站都碰得到那一处：`ts_` 变 `tsc_`

三、只对装了插件的站生效的两处

四、402：单子关成完成，代码里没有

五、另一条计量口径：流式输入被算两遍

六、封号与档位：三条社区自述

七、今天能做的三步

References

Related content

一、这一版改了什么

二、所有站都碰得到那一处：ts_ 变 tsc_

三、只对装了插件的站生效的两处

四、402：单子关成完成，代码里没有

五、另一条计量口径：流式输入被算两遍

六、封号与档位：三条社区自述

七、今天能做的三步

References

Related content

一、这一版改了什么

二、所有站都碰得到那一处：ts_ 变 tsc_

三、只对装了插件的站生效的两处

四、402：单子关成完成，代码里没有

五、另一条计量口径：流式输入被算两遍

六、封号与档位：三条社区自述

七、今天能做的三步

References

Related content

二、所有站都碰得到那一处：`ts_` 变 `tsc_`

二、所有站都碰得到那一处：`ts_` 变 `tsc_`