10/19 夜间续报：readOnly 仍能把 Gemini 请求打成 400，断开计费的补丁已进 main (2026)

这一期从上期发稿的 19:32 到现在，约两小时十五分。四个仓库都没有新版本，最新仍是 sub2api v0.2.17 与 CLIProxyAPI v8.0.34。

今晚有三件事能马上用：Gemini / Antigravity 那侧的两个 schema 关键字仍会把整条请求打成 400；上游 OpenAI 正在报文件下载错误；sub2api 两张 Gemini 计费单合进了 main，发行版还没带上。

两个关键字漏在名单外，整条请求被退回

先看这条 400。报障在 21:05 开出，作者 cheerc，环境是 v8.0.30 的 Homebrew 安装、provider 为 antigravity。1

上游的原文是 Invalid JSON payload received. Unknown name "readOnly" at 'request.tools[0].function_declarations[N].parameters...'。

一次带 84 个工具的请求，回了 58 条 readOnly 与 4 条 writeOnly，全在同一个 400 里。

撞上它的主要是 Google Discovery 派生的 MCP 工具。Firestore 的 create_database、update_database、create_backup_schedule、update_backup_schedule、create_index 会把 createTime、uid、etag 标成 readOnly。

所有走 Gemini / Antigravity schema 清洗的请求都会撞上它：Antigravity 执行器与几个函数声明翻译器共用同一条清洗路径。请求里只要有一个工具 schema 带着这两个词，整条就过不去。

本刊核了 v8.0.34 与 dev 两份 internal/util/gemini_schema.go。removeUnsupportedKeywords 的删除名单在第 1918–1919 行：deprecated、encrypted、discriminator、contentMediaType、contentEncoding 都在名单上，readOnly 与 writeOnly 两个词都搜不到。2

internal/util/gemini_schema.go 第 1898–1924 行，v8.0.34。第 1918 行是 schema metadata 类关键字，第 1919 行是结构类关键字；两行里都没有 readOnly 与 writeOnly。

补丁不到五分钟就开出来了：PR #6779，2 个文件 +95/−1，基分支 dev，状态 open、mergeable clean。3

改动只往名单末尾追加两个字符串。isPropertyDefinition 保持不变，所以真有一个参数叫 readOnly 的工具仍然保得住，测试里专门留了这条。

同一改法的旧单 #5853 还开着，基 dev，没有冲突评审。4

值班动作：挂着 Firestore 或其它 Google Discovery 类 MCP 的实例，这段时间先把这些工具摘掉，或在客户端侧把 schema 里的 readOnly / writeOnly 删掉。等 #6779 合进发行版再升级解决。

上游此刻在抖：文件下载报错

21:31 上游开了一条新事件，名字是 File Download errors，影响级别 minor，状态停在 identified。5

降级的组件是 Responses、Images、Files、File uploads、Image Generation 五项，状态页整体从 All Systems Operational 变成 Partial System Degradation。6

这条事件眼下只有一条更新：已定位，正在做缓解。

写稿时它还没恢复。这段时间里的文件下载、上传、图片生成报错，先归到上游；等它 resolved 再回看本地。

Gemini 的账单口径，两张单同时合了

20:45 这一分钟，sub2api 的 main 连吃两次合并。先合的是 #8168（20:45:03，merge 0fa02816），后合的是 #8177（20:45:16，merge 8f2cbb53）。main 头现在就是 8f2cbb53。7 8

#8168 改的是断开后的计费。它管三条流式路径：Gemini 原生 /v1beta、/v1/messages 兼容、/v1/chat/completions 兼容。客户端中途断开、或读到 finishReason 后立刻关连接时，过去会把已解析到的用量丢掉，这次请求不计费。

现在按断开前最后一份 usageMetadata 计费，ForwardResult.ClientDisconnect 置 true。断开前没有任何用量的，仍然不计费。

backend/internal/service/gemini_chat_completions_compat_service.go 第 294–314 行，v0.2.17。第 304 行 ClientDisconnect: false 就是这次改动前的样子。

#8177 改的是负数。Vertex 拦截 prompt 时（promptFeedback.blockReason，例如 PROHIBITED_CONTENT），usageMetadata 可能只有 cachedContentTokenCount，没有 promptTokenCount。

Gemini 的用量换算写的是 promptTokenCount - cachedContentTokenCount，没有 0 下限，于是算出负的 input_tokens 与负费用。报障举的例子是 input −12980、cache_read 12980、total_cost −0.0039。

扣费路径本身都有 > 0 的守卫，余额不会被倒加，被拉低的是用量记录与统计。改动把四处换算都改成 max(prompt − cached, 0)：extractGeminiUsage、antigravity 非流式、antigravity 流式的累计用量与 message_start。

backend/internal/pkg/antigravity/response_transformer.go 第 272–292 行，v0.2.17。第 284 行直接把两个数相减，负数就是从这一行出来的。

两张单都不在发行版里。v0.2.17 的 gemini_stream_client_abort.go 取回来是 404，上面两张图也是 v0.2.17 的原始写法。9

今晚升级拿不到，要等下一个 tag。自己从 main 构建的实例，今晚之后 pull 下来就有。

两件事先说在前面：断流以后不再免费，统计里会开始出现 ClientDisconnect 的请求；拦截类请求不再把 input_tokens 拉成负数，与历史数据对比时会跳一下。

昨天那条 413，补丁来了

昨天头条里那条「DeepSeek 内联图写两份、24 MiB 入站就撞 48 MiB」的问题，20:16 有了补丁。10 11

PR #8224 只动两个文件（+25/−19）：openai_gateway_request_body.go 与它的 DeepSeek 图片测试。说明写得很短，只说调整请求体构建、避免重复生成图片负载。

它还是 open，发行版更拿不到。上期那条处置不变：内联图按 24 MiB 的入站预算算，原始图压到 18 MiB 以下。

三条次要动态

Codex 的远端压缩在 Kimi / Meta 两条原生路线上还是通不过。21:27 的新单用同一份 30 条历史做了对照：gpt-6.1-sol、gpt-6-astra、gemini-4-argon、grok-4.7 都能压出一个 compaction 项并接着用；kimi-k3 回 item type "compaction_trigger" is not supported，muse-wonder-1.0 回 input[30] did not match any supported type。12

报障人给的退路在 Codex 侧：model_providers.<id>.capabilities.remote_compaction = "unsupported"。官方配置文档写的是这个键取 unsupported | v2，unsupported 走本地压缩。13

这条紧接着上一版：v8.0.34 把 #6769 修完之后，两条路线开始直连工具，压缩这一层的缺口才露出来。

v8.0.34 新加的搜索缓存生产上能用了，但只活在进程内存里。21:19 的反馈说：重启或升级一次缓存就空，仍开着的会话里 Claude 又看不到自己搜过什么；取不到值时也只写 debug 日志，没有可见的计数。14

插件那条是 21:35 的补丁：按索引取插件配额时，它从 auth 文件重新灌一份凭据，内存里换过的凭据、或根本不落文件的运行时凭据就会取错。改法是先解析唯一一份已登记的 Auth 快照，再调插件。3 个文件 +324/−25，仍 open。15

另外两张单在 20:50 拿到维护者评审。16

#8210 拿到三点意见：

客户端还在线时，上游空闲超时被当成「成功完成」回给客户端。agent 类客户端会把截断的回答和工具参数当成完整结果。
stream_data_interval_timeout = 0 时，断开后的读取没有上限，客户端走了还在读到上游自己结束。
它与 #7791、#7797、#7849、#7862 改的是同两处函数，最终要维护者择一。

#8166 的第一点也值得看一眼：账号被软删除时，在途请求的用户扣费会整笔回滚。17

上游与额度

Anthropic 状态页全绿，今天没有事件。18

Google Cloud 的清单仍是 7 条，最近一条还是 10 月 8 日到 9 日的 Cloud Storage。19

Codex 今天 UTC 没重置。最近一次已验证的全局重置在 10 月 18 日凌晨 4:41（北京），距今 41 小时。20

累计 55 次全局重置、10 次 banked，节奏大约是每 3 天一次。把 Tibo 17 小时前那条提示算进预测，24 小时口径 45%、48 小时口径 70%。

opentherank 的口径是 63 次、中位间隔 3.1 天、最长 68 天。21

四仓版本：sub2api v0.2.17、CLIProxyAPI v8.0.34、codex-proxy 稳定版 v2.1.18（预发布 v2.1.19-beta.f824033）、codex2api v3.1.1。22 23 24

codex-proxy 与 codex2api 这个窗口里 0 条条目更新，动过的只有 sub2api 与 CLIProxyAPI 的几张单。

OpenAI 开发者社区 Codex 分区这一轮取到 25 条，最新一条是 18:05 的，落在窗口之前。Reddit 的 r/OpenAI 也取到了，窗口里的帖子都是讨论与展示，没有额度或封号类。25

未收与待跟

#6779 什么时候合，要不要先合 #5853，今晚没有答案。

#8224 的说明只写了「调整构建逻辑」。改法到底是删掉重复的那一份，还是改写其中一份，要等合并后的 diff。

#6781 的压缩适配会不会做成通用桥，还是只给 Kimi / Meta 补一个触发器，还没定。

#8210 与那四张改同一处的单最后怎么收口，要等维护者择一。

References

1
#6778 Antigravity/Gemini 400 readOnly
github.com
2
v8.0.34 gemini_schema.go 第 1911–1919 行
github.com
3
PR #6779 往名单加两个词
github.com
4
PR #5853 同一改法的旧单
github.com
5
OpenAI 状态页 File Download errors
status.openai.com
6
status.openai.com summary
status.openai.com
7
PR #8168 断开按已收集用量计费
github.com
8
PR #8177 负 input_tokens 归零
github.com
9
sub2api Releases
github.com
10
PR #8224 去掉重复的图片负载
github.com
11
issue #8222 原始报障
github.com
12
#6781 compaction_trigger 400
github.com
13
Codex 配置参考 remote_compaction
learn.chatgpt.com
14
#6780 搜索缓存重启即空
github.com
15
PR #6782 用选中的那份凭据取配额
github.com
16
#8210 维护者评审
github.com
17
#8166 维护者评审
github.com
18
status.anthropic.com
status.anthropic.com
19
status.cloud.google.com
status.cloud.google.com
20
codex-reset.com
codex-reset.com
21
opentherank Codex 重置追踪
opentherank.com
22
CLIProxyAPI Releases
github.com
23
codex-proxy Releases
github.com
24
codex2api Releases
github.com
25
OpenAI 开发者社区 Codex 分区
community.openai.com

这一期从上期发稿的 19:32 到现在，约两小时十五分。四个仓库都没有新版本，最新仍是 sub2api v0.2.17 与 CLIProxyAPI v8.0.34。

两个关键字漏在名单外，整条请求被退回

先看这条 400。报障在 21:05 开出，作者 cheerc，环境是 v8.0.30 的 Homebrew 安装、provider 为 antigravity。1

上游的原文是 Invalid JSON payload received. Unknown name "readOnly" at 'request.tools[0].function_declarations[N].parameters...'。

一次带 84 个工具的请求，回了 58 条 readOnly 与 4 条 writeOnly，全在同一个 400 里。

internal/util/gemini_schema.go 第 1898–1924 行，v8.0.34。第 1918 行是 schema metadata 类关键字，第 1919 行是结构类关键字；两行里都没有 readOnly 与 writeOnly。

补丁不到五分钟就开出来了：PR #6779，2 个文件 +95/−1，基分支 dev，状态 open、mergeable clean。3

改动只往名单末尾追加两个字符串。isPropertyDefinition 保持不变，所以真有一个参数叫 readOnly 的工具仍然保得住，测试里专门留了这条。

同一改法的旧单 #5853 还开着，基 dev，没有冲突评审。4

上游此刻在抖：文件下载报错

21:31 上游开了一条新事件，名字是 File Download errors，影响级别 minor，状态停在 identified。5

降级的组件是 Responses、Images、Files、File uploads、Image Generation 五项，状态页整体从 All Systems Operational 变成 Partial System Degradation。6

这条事件眼下只有一条更新：已定位，正在做缓解。

写稿时它还没恢复。这段时间里的文件下载、上传、图片生成报错，先归到上游；等它 resolved 再回看本地。

Gemini 的账单口径，两张单同时合了

20:45 这一分钟，sub2api 的 main 连吃两次合并。先合的是 #8168（20:45:03，merge 0fa02816），后合的是 #8177（20:45:16，merge 8f2cbb53）。main 头现在就是 8f2cbb53。7 8

现在按断开前最后一份 usageMetadata 计费，ForwardResult.ClientDisconnect 置 true。断开前没有任何用量的，仍然不计费。

backend/internal/service/gemini_chat_completions_compat_service.go 第 294–314 行，v0.2.17。第 304 行 ClientDisconnect: false 就是这次改动前的样子。

backend/internal/pkg/antigravity/response_transformer.go 第 272–292 行，v0.2.17。第 284 行直接把两个数相减，负数就是从这一行出来的。

两张单都不在发行版里。v0.2.17 的 gemini_stream_client_abort.go 取回来是 404，上面两张图也是 v0.2.17 的原始写法。9

今晚升级拿不到，要等下一个 tag。自己从 main 构建的实例，今晚之后 pull 下来就有。

两件事先说在前面：断流以后不再免费，统计里会开始出现 ClientDisconnect 的请求；拦截类请求不再把 input_tokens 拉成负数，与历史数据对比时会跳一下。

昨天那条 413，补丁来了

昨天头条里那条「DeepSeek 内联图写两份、24 MiB 入站就撞 48 MiB」的问题，20:16 有了补丁。10 11

PR #8224 只动两个文件（+25/−19）：openai_gateway_request_body.go 与它的 DeepSeek 图片测试。说明写得很短，只说调整请求体构建、避免重复生成图片负载。

它还是 open，发行版更拿不到。上期那条处置不变：内联图按 24 MiB 的入站预算算，原始图压到 18 MiB 以下。

三条次要动态

这条紧接着上一版：v8.0.34 把 #6769 修完之后，两条路线开始直连工具，压缩这一层的缺口才露出来。

另外两张单在 20:50 拿到维护者评审。16

#8210 拿到三点意见：

客户端还在线时，上游空闲超时被当成「成功完成」回给客户端。agent 类客户端会把截断的回答和工具参数当成完整结果。
stream_data_interval_timeout = 0 时，断开后的读取没有上限，客户端走了还在读到上游自己结束。
它与 #7791、#7797、#7849、#7862 改的是同两处函数，最终要维护者择一。

#8166 的第一点也值得看一眼：账号被软删除时，在途请求的用户扣费会整笔回滚。17

上游与额度

Anthropic 状态页全绿，今天没有事件。18

Google Cloud 的清单仍是 7 条，最近一条还是 10 月 8 日到 9 日的 Cloud Storage。19

Codex 今天 UTC 没重置。最近一次已验证的全局重置在 10 月 18 日凌晨 4:41（北京），距今 41 小时。20

累计 55 次全局重置、10 次 banked，节奏大约是每 3 天一次。把 Tibo 17 小时前那条提示算进预测，24 小时口径 45%、48 小时口径 70%。

opentherank 的口径是 63 次、中位间隔 3.1 天、最长 68 天。21

四仓版本：sub2api v0.2.17、CLIProxyAPI v8.0.34、codex-proxy 稳定版 v2.1.18（预发布 v2.1.19-beta.f824033）、codex2api v3.1.1。22 23 24

codex-proxy 与 codex2api 这个窗口里 0 条条目更新，动过的只有 sub2api 与 CLIProxyAPI 的几张单。

未收与待跟

#6779 什么时候合，要不要先合 #5853，今晚没有答案。

#8224 的说明只写了「调整构建逻辑」。改法到底是删掉重复的那一份，还是改写其中一份，要等合并后的 diff。

#6781 的压缩适配会不会做成通用桥，还是只给 Kimi / Meta 补一个触发器，还没定。

#8210 与那四张改同一处的单最后怎么收口，要等维护者择一。

References

1
#6778 Antigravity/Gemini 400 readOnly
github.com
2
v8.0.34 gemini_schema.go 第 1911–1919 行
github.com
3
PR #6779 往名单加两个词
github.com
4
PR #5853 同一改法的旧单
github.com
5
OpenAI 状态页 File Download errors
status.openai.com
6
status.openai.com summary
status.openai.com
7
PR #8168 断开按已收集用量计费
github.com
8
PR #8177 负 input_tokens 归零
github.com
9
sub2api Releases
github.com
10
PR #8224 去掉重复的图片负载
github.com
11
issue #8222 原始报障
github.com
12
#6781 compaction_trigger 400
github.com
13
Codex 配置参考 remote_compaction
learn.chatgpt.com
14
#6780 搜索缓存重启即空
github.com
15
PR #6782 用选中的那份凭据取配额
github.com
16
#8210 维护者评审
github.com
17
#8166 维护者评审
github.com
18
status.anthropic.com
status.anthropic.com
19
status.cloud.google.com
status.cloud.google.com
20
codex-reset.com
codex-reset.com
21
opentherank Codex 重置追踪
opentherank.com
22
CLIProxyAPI Releases
github.com
23
codex-proxy Releases
github.com
24
codex2api Releases
github.com
25
OpenAI 开发者社区 Codex 分区
community.openai.com

10/19 夜间续报：readOnly 仍能把 Gemini 请求打成 400，断开计费的补丁已进 main

两个关键字漏在名单外，整条请求被退回

上游此刻在抖：文件下载报错

Gemini 的账单口径，两张单同时合了

昨天那条 413，补丁来了

三条次要动态

上游与额度

未收与待跟

References

Related content

10/19 夜间续报：readOnly 仍能把 Gemini 请求打成 400，断开计费的补丁已进 main

两个关键字漏在名单外，整条请求被退回

上游此刻在抖：文件下载报错

Gemini 的账单口径，两张单同时合了

昨天那条 413，补丁来了

三条次要动态

上游与额度

未收与待跟

References

Related content