10/16 凌晨续报：Claude→Responses 逐块重校验请求体已修进 dev，sub2api 投递记账 PR 重基到主干
补报 10 月 16 日 03:33 到 04:21（北京）：CLIProxyAPI 把 Claude→Responses 流式转换里每个数据流块都重校验整份请求体的性能问题修进了 dev 分支，但还没有进任何发行版；sub2api 一条把下游投递结果与上游计费分开的大 PR，在同一窗口重基到了最新主干。四个仓库本窗口都没有新版本。
补报 10 月 16 日 03:33 到 04:21（北京）。第二十六期在北京 03:33 刊出，本期接在它后面。
这个窗口四个仓库都没有发新版，主干上只有 CLIProxyAPI 的一笔提交，上游三家状态页也没有新事件。
中转侧有两条动态。CLIProxyAPI 把「每个数据流块都重校验一次整份请求体」这条性能报障修进了 dev 分支，还没有进任何版本。sub2api 一条把下游投递结果与上游计费分开的大 PR，重基到了最新主干。
影响面两块。跑 v8.0.30 的站点，那条 CPU 开销还在，要等下一个发行版才能带走。sub2api 那条 PR 还在草案状态，现在不用改任何配置。
这段时间先看这几件事：
- 没有要升的版本：四个仓库本窗口都没有新版本，主干上只有 CLIProxyAPI 的一笔提交。
- 跑 v8.0.30、且走 Claude→Responses 转换的站点：那条逐块重校验还在，等下一个发行版；想自己核，看
claude_openai-responses_response.go第 678 行。 - 用 sub2api 的站点：投递记账那条 PR 重基过了、还没合并，
v0.2.16里没有response_outcome这一列，什么都不用动。 - 上游不用管：OpenAI 状态页剩下的「部分系统降级」仍是 Compliance API 那条旧事件，本窗口没有新更新。
CLIProxyAPI：逐块重校验请求体，修复已进 dev
issue
#6665 在北京 10 月 16 日 00:49 开出，报的是 Claude 转 OpenAI Responses 的流式转换里，每个数据流块都要重跑一次全请求体校验。1北京 10 月 16 日 03:37，维护者 luispater 自己重写了这个修复，直接提交进
dev 分支。2提交标题是
feat(claude): pin validated request body per-stream in OpenAI Responses translation，改动只有两个文件：转换主文件 +7/−3，测试文件 +75。2做法是给每条流的转换状态加一个
RequestJSON 字段，建 state 时把校验过的请求体存进去，之后每个数据流块直接复用，不再重新取值。2回归测试叫
TestConvertClaudeResponseToOpenAIResponses_PinsRequestPerStream，构造方式是只有第一个块带请求体，后面几块都不带。2本刊拉到的时间线上，北京 03:37 只有一次提交引用，没有关闭动作。1
你手上那一版有没有带上它，看一行就知道。
v8.0.30 的 internal/translator/claude/openai/responses/claude_openai-responses_response.go 第 678 行还写着 requestForToolMetadata := pickRequestJSON(originalRequestRawJSON, requestRawJSON)。3同一份文件第 665 行在建 state 时取一次，第 1012 行在收尾、拼
response.completed 时再取一次。3dev 上第 678 行与第 1012 行那两处已经换成
st.RequestJSON。2
v8.0.30 的 internal/translator/claude/openai/responses/claude_openai-responses_response.go，高亮段是第 675–682 行：第 678 行在转换每个数据流块时又取一次请求体，这一步就是 dev 上被换掉的那一处。第 665 行在函数开头建好 state，那一次在修复后保留。3对运维意味着什么：不用为此升级。
v8.0.30 是北京 10 月 15 日 21:55 发的版，早于这笔提交。4等下一个发行版出来，再核那一行是不是变成了
st.RequestJSON。2自己从 dev 构建的站点，现在就已经拿到这个修复。2
sub2api：投递记账那条大 PR 重基到最新主干
#7962 是 10 月 9 日开出的单，作者 XKHoshizora，标题 fix(openai): propagate cancellation and separate delivery from consumption。5它做的是把 GPT 转发链路上一直混在一起的两件事拆开：下游有没有真的收到响应，和上游那笔消费怎么记账。5
具体是给
usage_logs 加一列 response_outcome，四个取值：response_written 是服务端写完，client_cancelled 是下游取消，write_failed 是写失败，upstream_failed 是上游失败。6这一列为空表示该路径没有记录投递结果，迁移文件的注释写明它不代表投递成功。6
配套的行为也改了：下游投递失败时不再走 failover，不再罚账号健康，也不再写一行 0 用量的记录。5
本窗口里它动了两笔提交，都在北京 10 月 16 日 04:07：一笔把分支重基到最新主干，三秒后补了一笔时钟精度相关的测试。7
PR 现在仍是 open、未合并，60 个文件 +3180/−386，合并状态显示 unstable。5
对运维意味着什么：
v0.2.16 里没有这一列，现在不用改任何东西。9这条 PR 值得看一眼的原因，是它把「下游断开」和「上游故障」变成了能分开统计的两种结果。6
其余上游与社区：本窗口没有新事件
OpenAI 状态页整体仍写着「部分系统降级」，唯一降级的组件仍是 Compliance API 的成本数据延迟。10
上一期报过的那条登录与注册降级，最后一条更新仍是北京 10 月 16 日 02:56 的「已恢复」，本窗口没有新更新。11
Anthropic 状态页是全系统正常，当日无事件记录。12
Google Cloud 最近一条事件仍是 10 月 8 日到 9 日的 Cloud Storage 上传与写入延迟。13
Codex 重置追踪两站都没有新记录。codex-reset.com 仍记最近一次已验证的全局重置在北京 10 月 15 日 14:13，累计 54 次、另有 10 次 banked，24 小时概率 18%、48 小时 33%。14
opentherank 也停在同一天：最近一次记录是北京 10 月 15 日 12:55，累计 62 次，中位间隔 3.1 天。15
OpenAI 开发者社区的 Codex 分区最新一条停在北京 10 月 16 日 00:31，窗口内没有新话题。16
扫的三个板块里没有与额度、封号相关的新帖。r/OpenAI 窗口内那条是 Windows 客户端退出登录后重登不上，属客户端侧问题。17
本期未闭合项
本窗口该仓库另有一条繁体中文本地化 PR，与额度风控无关，未收为本期条目。25
codex2api 的
#790 降智检测也仍开着、未合并。26References
- 1
- 2
- 3
- 4CLIProxyAPI Releases
github.com
- 5
- 6
- 7sub2api #7962 提交列表
github.com
- 8sub2api main 分支提交
github.com
- 9sub2api Releases
github.com
- 10OpenAI Status summary
status.openai.com
- 11Widespread feature degradation
status.openai.com
- 12Claude Status
status.anthropic.com
- 13Google Cloud incidents.json
status.cloud.google.com
- 14Codex Reset Tracker
codex-reset.com
- 15Codex reset tracker
opentherank.com
- 16Codex - OpenAI Developer Community
community.openai.com
- 17
- 18
- 19
- 20
- 21
- 22
- 23fix(typesafe): 透传 System One 图片开关请求头
github.com
- 24
- 25
- 26
- 27codex-proxy Releases
github.com
- 28codex2api Releases
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.