10/16 傍晚速报：response.completed 之后本地中断窗口还开着，会多回一句合成应答；OpenCode 大输入首字延迟的单被关掉
10 月 16 日傍晚这五十来分钟里，CLIProxyAPI 上同一族 Responses 中断缺陷出现了两份都还没合并的修复，一份让本地中断窗口随终端事件关闭、一份把 HTTP 回退的中断按 response ID 绑定；sub2api 上一张 OpenCode 大输入首字延迟的单被报障人自己关掉，四个仓库本窗口都没有新版本。
10 月 16 日北京 15:42 到 16:36，sub2api、CLIProxyAPI、codex-proxy、codex2api 四个仓库都没有发新版本，主干也没有新提交。当前版本仍是 sub2api v0.2.17、CLIProxyAPI v8.0.31、codex-proxy v2.1.17、codex2api v3.1.01234。
这五十来分钟里没有要升的版本，也没有要改的键。有两件需要看清形态：CLIProxyAPI 上出现了同一族 Responses 中断缺陷的两份修复，两份都还没合并；sub2api 上一张 OpenCode 大输入首字延迟的单，被报障人自己关掉了。
一、CLIProxyAPI：中断窗口要等数据通道关闭才结束
CLIProxyAPI PR #6676 在北京 15:46 开出，open、未合并、非 draft，基分支是
dev，3 个文件 +194/−2、3 笔提交5。作者把
TestResponsesLateInterruptDoesNotPoisonNextCreate 在 dev 的 355fd10e 上跑了一千次，16 次失败，每次都停在同一处断言：本该收到错误，实际收到的是一句 {"type":"response.incomplete","response":{"id":"unknown",…}}5。这句应答是本地合成出来的。v8.0.31 的
sdk/api/handlers/openai/openai_responses_websocket_forward.go 里，本地中断窗口在进入转发循环之前用 begin() 打开，关上它的是函数返回时才执行的 defer end()6。窗口的寿命于是等于整个转发函数的寿命，而不是一轮应答的寿命。
openai_responses_websocket_forward.go 第 70–90 行：第 75 行 begin() 打开本地中断窗口，第 76 行的 defer end() 要等函数返回才执行；第 82 行是转发循环收取本地投递进来中断帧的那条分支6上游的数据通道不会在
response.completed 那一刻关掉，它可能还开一会儿。客户端在这段空隙里发来的 response.interrupt，就落进了一扇还开着的窗口。中断帧由输入读取侧处理：它先把帧交给执行器，执行器回
ErrNoActiveUpstreamWebsocket（上游那一轮已经结束）时，就地投递给本地窗口7。投递成功后，转发循环把这一帧交给
completeResponsesWebsocketLocalInterrupt，由它写出一句 response.incomplete。这句话里的 response.id 直接取中断帧携带的 response_id8。结果是：客户端已经看到
response.completed，还会再收到一句 response.incomplete，而它的 response.id 跟刚结束的那一轮对不上。测试名字点出的后果更重：这类迟到中断会污染同一条连接上的下一次
response.create。修复的改法是在终端事件上收口。记下
response.completed、response.done、response.incomplete 时先 end()，再把事件写给客户端；同一个流上新的 response.created 到来时重新 begin()。response.failed 也是终端事件，同样 end()。作者的跑数：
dev 上这条测试 16/1000 失败，改后 0/1000；同一条流程里另一条 flaky 测试从 49/1000 降到 0/10005。这条修复没有对应的配置项。本地中断这条路径只在客户端用 Responses WebSocket、而这一轮没有活着的上游 WebSocket 时才会走到，也就是上游走 HTTP 的时候7。路径对得上的话，剩下的选择是自己打这个分支的补丁，或者等它合并。
二、同一族的另一条路径：HTTP 回退按 response ID 绑定取消
CLIProxyAPI PR #6515 更早，10 月 10 日 23:39 开出，本窗口内 15:45 有一次更新，现在 open、未合并、可以干净合并，7 个文件 +592/−36、3 笔提交9。
它讲的是同一族缺陷在 HTTP 回退路径上的形态。Responses WebSocket 客户端走 HTTP 上游时，一条在应答完成之后到达的中断会回 400；如果这时另一个 response 正在跑，针对旧 response 或者未知 ID 的中断会把当前这一轮取消掉，并发出
response.id 不对的 response.incomplete9。改法是把本地取消绑定到已经观察到的当前 response ID。对已经结束的 response，中断变成幂等的空操作；未知 ID 仍然回 400，而且不碰当前请求9。
作者给出的验证是三个集成用例
late_idle、stale_active、unknown_active 在修复前全部失败、修复后通过，另有一次真实模型冒烟，链路从 WebSocket 客户端到 HTTP 再到 gpt-6.1-sol，用的服务没有被替换或重启9。两份修复改的是同一批文件，是同一族缺陷的两份独立实现。谁先合进
dev，另一份都要重基；#6515 自己也说与 #6500 有重叠9。所以这段修复还要在未合并状态里停一阵。对读者的意思很直接：v8.0.31 上没有配置项能躲开这两条路径，两份修复也都还没进版本。
三、窗口里被关掉的一张单：OpenCode 大输入的首字延迟
sub2api issue #8024 在 10 月 12 日 11:23 开出，10 月 16 日 16:16 关闭，关闭原因标的是 completed，关单的是报障人自己，没有维护者定性，也没有修复10。
单里写的是：同一份输入，经过 sub2api 首字要等；输入 token 比较小的时候正常；不经过 sub2api、直连
https://opencode.ai/zen/go/v1 就没有这个延迟10。单里唯一一条回复来自贡献者 StarryKira，时间是 10 月 12 日。他让报障人先看网络，判断是不是流式失败，并给出读数「总耗时 1m26 TTFT1m24 吐了 4000tokens」10。
按这组读数，84 秒花在第一个 token 之前，4000 个 token 是之后两秒里出来的。
这张单没有给出成因，也没有人复现。OpenCode 这条链路上有两处，可以直接在自己的部署里核。
第一处是出站的会话标识。OpenCode Go 从 2026-09-05 起要求每个会话带一个值，缺了会回
MissingSessionID。sub2api 会把出站的 x-opencode-session 收敛成它找到的第一个稳定标识：客户端头、客户端 body 里的 prompt_cache_key 或 metadata.user_id、已有的同名头，都没有才生成一个新 UUID。客户端不报任何稳定标识时，每一轮都是新会话11。第二处是出站的 User-Agent。sub2api 会把发往官方 OpenCode 主机的 UA 收敛成
opencode/1.0.0。源码注释写明 opencode.ai 前置的 Cloudflare 按客户端 UA 做 bot 拦截，Python-urllib 这类编程库 UA 会被拒绝并回 403，而这个 403 又被计入账号的凭证类 strike，健康账号会因此被自动禁用12。账号自己的 header_overrides 里显式写的 user-agent 优先级更高，会盖掉这次收敛13。如果你的用户报首字要等一分钟以上，可以拿同一份大输入走一次直连，先确认延迟出在网关这一侧；再核一下出站请求里有没有带会话标识。这两步都能在日志里看到。
四、其它条目
CLIProxyAPI #6677 与 #6676 是同一位作者、同一分钟开出，open、未合并，只改 1 个文件 +46/−0，是测试专用的一条14。它等错了信号：测试等的是「测试服务器回了 authB 的探测」，它需要等的是「authB 的模型已经发布」，于是在随后的
manager.Update 改掉 authB 前缀之后，探测结果被正确地丢掉了。这条测试在 v8.0.31 上跑 400 次失败 9 次，改完 0 次；产品代码没有动。sub2api #8154 在北京 15:44 开出，open、1 条评论，建议把模型厂商插件化，好让加新模型不用改代码15。正文自述是猜测、没有看过代码，单里没有机制也没有复现。
sub2api #8135 在本窗口得到一条支持评论（北京 15:52），仍然 open16。它报的是面板生成的 CC Switch 导入链接里模型写死了
gpt-5.5；上一期登记的那张改这个默认值的 PR #8150 已经关闭、没有合并17。codex-proxy 与 codex2api 本窗口 0 条。
五、上游与额度侧
Codex 重置追踪站今天（UTC）没有重置。最近一次已验证的全局重置是 26 小时前的 10 月 15 日 06:13 UTC，也就是北京 10 月 15 日 14:13；累计 54 次全局重置、10 次 banked，节奏约每 4 天18。
同一页上两套概率并存：模型口径是 18% 与 33%，把提示帖计进去的 counted 口径是 24 小时 50%、48 小时 75%18。
另一个追踪站记最近一次重置为 10 月 15 日 04:55 UTC，自 2025 年 9 月以来 62 次，中位间隔 3.1 天，最长一次 68 天19。
OpenAI 状态页仍是 Partial System Degradation，唯一降级组件还是 Compliance API，最后一条更新停在 10 月 15 日 22:36 UTC20。
Anthropic 状态页是 All Systems Operational，10 月 16 日一栏写着 No incidents reported today21。
Google Cloud 的事件列表最近一条仍是 10 月 8 日到 9 日的 Cloud Storage22。
社区侧这一窗口没有与额度、风控相关的新帖。r/GeminiAI 窗口内唯一一条是拿 Argon 分析自家电费账单的使用故事，r/ClaudeAI 与 r/OpenAI 都没有新帖；官方开发者社区 Codex 分区窗口内的一条是客户端崩溃报告占用磁盘23。
六、未闭合项（下期继续跟，不作结论）
- sub2api：本窗口内 #8024 被关闭、#8154 登记；继续跟 #8153、#8152、#8151、#8150（已关闭未合并）、#8139、#8135、#8134、#8136、#8142、#8143、#8141、#8144、#8146、#8147、#8127、#8125、#8123、#7962、#7398
- CLIProxyAPI：本窗口登记 #6676、#6677，#6515 有更新；继续跟 #6675、#6605、#5764、#6661、#6667、#6659、#6669、#6671、#6673、#6625、#6603、#6500
- codex-proxy、codex2api：本窗口 0 条
下期优先回看三条：#6676 会不会合进
dev、有没有版本带上这段；#6515 与 #6676 谁先合、另一份怎么重基；#8024 有没有人重新开单给出成因。References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5CLIProxyAPI #6676
github.com
- 6forward.go 第 70–90 行
github.com
- 7input.go 第 96–110 行
github.com
- 8forward.go 第 247–276 行
github.com
- 9CLIProxyAPI #6515
github.com
- 10sub2api #8024
github.com
- 11openai_opencode_session.go 第 60–100 行
github.com
- 12openai_opencode_session.go 第 18–24 行
github.com
- 13openai_opencode_session.go 第 116–135 行
github.com
- 14CLIProxyAPI #6677
github.com
- 15sub2api #8154
github.com
- 16sub2api #8135
github.com
- 17sub2api #8150
github.com
- 18codex-reset.com
codex-reset.com
- 19opentherank
opentherank.com
- 20OpenAI Status
status.openai.com
- 21Claude Status
status.anthropic.com
- 22Google Cloud Status
status.cloud.google.com
- 23Codex - OpenAI Developer Community
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.