10/17 凌晨速报：Codex 一重发历史就 400——haiku-5-5 漏在 prefill 拒绝名单、回放的思考块过不了绑定校验；Meta 流被记成 499 的修复已进 dev
10 月 17 日北京 23:21 到 00:26 这 65 分钟里四个仓库都没发新版本：Codex 一重发历史就回 400，两处独立成因分别落在 haiku-5-5 的 prefill 拒绝名单和思考块的创建时绑定校验上；Meta 流被记成 499 的修复已进 dev、发行版不含，sub2api 那张能力路由的大 PR 一旦合并，部署当天会让已缓存的认证快照全部失效重建。
北京 23:21（上一期刊出时刻）到 00:26 这 65 分钟里，四个仓库都没有发出新版本。
四个仓库的主干在本窗口也没有新提交。唯一落地的新代码在 CLIProxyAPI 的 dev 分支上：一笔提交，给 Meta（Muse）流补了一个终局标记。
今晚要当场拿定主意的是三件事。Codex 那条重连路径只要把历史重发一遍就回 400，v8.0.31 上照旧，而且眼下没有能升的版本。Meta 流被记成 499 的修复已经进了 dev，四个发行版都不含。sub2api 那张能力路由的大 PR 一旦合并，部署当天就会让已缓存的认证快照全部失效重建。
一、Responses→Claude 中继会话一重发历史就 400：haiku-5-5 漏在拒绝名单外，回放的思考块过不了绑定校验
CLIProxyAPI issue #6692 在北京 23:59 开出，open、0 评论、无标签，作者 sciman-top5。
环境是 Codex Desktop 0.163.0-alpha.10.2，客户端打
POST /v1/responses，请求里 store=false、带 reasoning.encrypted_content、effort 取 xhigh5。这条请求经 Responses→Claude 那一层翻译后进 Claude 执行器，凭证是受管 API key 组、base URL 指向自建的 Anthropic Messages 面5。
报障人的结论是：这类中继会话只要客户端把重塑过的历史再送一遍，就一路 400。会触发重发的有三种情形——流重连、客户端发来一个「continue」轮次、以及服务端工具往返之后的那一轮5。
两个成因互相独立，在 v8.0.30 与 v8.0.31 上都复现，到 v8.0.31 仍然失败5。
成因一：结尾那条 assistant 消息没有扔掉
第一种是结尾的 assistant 消息没被丢掉。上游回的原文是
This model does not support assistant message prefill. The conversation must end with a user message.5本刊在 v8.0.31 上核对，负责判断的
claudeModelRejectsAssistantPrefill 在 internal/translator/claude/openai/responses/claude_openai-responses_request.go 第 836–871 行6。claude-haiku-5-5 正从这个口子掉出去。调用点 dropUnsupportedClaudeAssistantPrefill 在第 769–781 行，第 772 行一判为 false 就原样返回，什么都不删7。
internal/translator/claude/openai/responses/claude_openai-responses_request.go 第 836–871 行：第 843 行把模型名拆成词，第 844 行只认 fable，第 847–849 行把第一个词不是 opus、sonnet 的名字一律判为「不拒绝 prefill」，claude-haiku-5-5 就停在那一行6报障人指出这跟 #5279、#5319 是同一类缺陷：判定靠的是模型家族名的子串匹配，每出一代新名字就漏一次5。
所以对旧家族名做子串匹配盖不住新一代——同一个 haiku 名字，两代的答案相反5。
本刊另外核到，这条修复不在 dev 上：dev 分支的同名文件与 v8.0.31 逐字节相同，这个谓词一行没动。
成因二：回放的思考块过不了创建时绑定校验
第二种是重放的 thinking 块被上游拒掉，原文是
messages.1.content.0: Invalid signature in thinking block. The block is bound to a different conversation.5上游还给了两个变体：
The tools list differs from the one this block was created with. 与 The content before this block was not present.5Anthropic 校验签名不只看密码学，还对着创建时的会话前缀与工具表。中继会话按构造就破坏了这个前提5。
结论因此很硬：任何会回放历史的客户端都过不了这一关，对 Codex 来说就是每一条重连与 continue 路径5。
报障人给的出路是注入
thinking.block_binding.prefix_mismatch_behavior=drop_block 加 thinking-binding-controls-2026-08-01 这个 beta。他写的原话是执行器不会自己用它5。本刊核对了这句话的边界。v8.0.31 里这个 beta 的常量在
internal/runtime/executor/claude_executor_request.go 第 56 行，追加条件是第 253–256 行8。条件写的是：只有客户端在
betas 里点名、或 body 里已经存在 thinking.block_binding、或该型号走 progress display 且 thinking.type 为 adaptive 时才追加8。翻译层不会替中继会话打开它，所以没人点名时
drop_block 不生效，报障人的说法站得住9。今天能做的
报障人贴了一份实测可用的客户端侧缓解：同一份 stale block 上，不开回 400、开了回 2005。
做法是加一条按模型限定的
requests.payload override：写入 thinking.block_binding.prefix_mismatch_behavior=drop_block，body 里带上 betas=["thinking-binding-controls-2026-08-01"]，再用一条条件过滤删掉结尾的 assistant 消息（匹配 messages.@reverse.0.role == "assistant"，删 messages.-1）5。他特别提醒两个坑。override 必须 gate 在
thinking.type 已经存在这一条件上，否则 sjson 会在本来没有思考的请求上合成一个空的 thinking.block_binding，那些请求会全部回 400 thinking.type: Field required5。这条仍开着、0 评论、没有修复 PR。今晚的处置：先确认自己那条 Responses→Claude 通道上有没有 Codex 在重连；重连一多就按上面两个成因分开查，别把它当成配额问题。
二、Meta（Muse）流被记成 499 的修复进了 dev，发行版与主干都不含
两个文件里一个是一百多行的新回归测试，一个是
internal/runtime/executor/meta_executor_stream.go，正式改动只有 8 行10。这条修复对应的是上一期报过的 #6688。现象是 Meta（Muse Code）订阅凭证走
/v1/messages 流式，客户端读到 message_stop 后关连接13。客户端其实拿到了完整回答、网关也记了 200，但用量记录与凭证的 failed 计数被记成 499、0 in/0 out；报障人连发 16 条里有 15 条如此13。
这个终局标记此前只存在于 antigravity 与 gemini-vertex 两条流上，Meta 流这次才补上。
修复只在 dev：v8.0.31 与 main 上的同名文件都没有这个布尔量，主干最新提交停在 10 月 16 日 16:38（北京）。读者现在无版本可升。
影响面在号池判断上。如果你在池子里放了 Meta（Muse）凭证，这条误记会同时污染用量统计与失败计数，让一张其实正常的凭证看起来一直在挂。升级之前，别只按 failed 计数决定要不要停用它。
三、sub2api 给 Codex OAuth 账号加能力路由与分组白名单，两项改动部署即生效
sub2api PR #8165 在北京 00:19 开出，open、非 draft、
merged=false、mergeable_state 为 unstable，120 个文件 +5738/−245，base 是 main，head 是 ZeroClover:feat/codex-account-capabilities，0 评论14。它要解决的是权益错配。用 ChatGPT 登录的 Codex OAuth 账号在上游各有不同权益，一边是 Cyber 访问项目（
daybreak_blue / daybreak_red），另一边是模型服务层级（Fast 对应 priority，以及 Ultrafast）14。机制分三块。第一块是能力记录：从上游
GET /backend-api/codex/models 推导，按模型 slug 记下 service_tiers 与 cyber 项目，持久化进 accounts.extra.codex_capabilities14。这份记录在账号创建、重新授权或凭据变更、后台 token 刷新、账号测试、同步上游模型、以及 manifest 真实拉取时刷新，只在有变化时写入；启动后还会一次性补齐缺记录的活跃账号14。
判定规则在新文件
backend/internal/service/openai_capability_requirement.go 里。无记录的 OAuth 账号视为不具备任何能力，直接被排除；API Key 与其他平台账号不受影响15。第三块是分组能力白名单。
groups 表新增 capability_allowlist 列，可以按分组禁用某个 Daybreak 项目或某个 service tier；被禁的请求在 HTTP 入口回 404 capability_not_allowed16。Codex manifest 的三条生成路径还共用了一段后处理：按分组内账号记录的并集投影
service_tiers 与 available_access_programs.cyber，再按白名单裁剪，ETag 基于投影后的 body14。
backend/internal/service/openai_capability_requirement.go 第 12–62 行：第 19–20 行是两个排除原因码，第 40–45 行的 AppliesTo 把能力过滤限定在 OpenAI OAuth 类账号上，第 50 行的 SatisfiedBy 按账号已记录的能力逐项核对、不满足时返回带名字的原因15各项改动对应的处置
这是这张 PR 里最该先看的一段：它自己列了四项部署须知14。
第一项是新增迁移
backend/migrations/246_group_capability_allowlist.sql。它只做一件事，给 groups 加一列 JSONB 的 capability_allowlist，默认空对象16。第二项是 API Key 认证快照版本从 24 升到 25：部署之后，已经缓存的认证快照会全部失效并重建14。
这一条的体感是部署瞬间的一次集中鉴权开销，不是功能故障。但如果有别的组件在按快照版本缓存，那一项要先跟着改。
第三项是启动后的补齐窗口：补齐任务把能力记录填完之前，带 Daybreak 或 Ultrafast 需求的请求可能短暂报无可用账号14。
第四项是行为变更：固定账号模式下，manifest 的能力字段从「首账号的原值」改成了「分组并集」，作者在 proposal 里自己标了 BREAKING14。
另有一条按分组生效的：开启了「强制 Fast」的分组，选号需求会被无条件折叠成
priority，与转发层的无条件改写一致14。作者自述的验证是
go build、go vet、golangci-lint 全过，后端测试与前端 374 个文件 / 2879 个用例通过；未执行的是 setup_token 账号能否调用目录接口的实测，以及两份真实登录态的端到端手测14。这张 PR 还没合并，也没有人评论过。今晚的处置是：现在别照它去改生产；等它合并进发行版再升的时候，迁移 246 与认证快照重建是两件必须先知道的事。
四、同一窗口里的短条目
CLIProxyAPI PR #6691 修复的是凭证排除规则的优先级：非空的规范化凭证规则应当替换全局 provider 排除，而不是与它合并17。
它同时规定，凭证规则缺失、为空或只有空白时回退到全局规则，API key 的排除与 OAuth 的全局排除互不影响，凭证元数据 PATCH 时要在运行态同步之前重算有效排除及其 hash17。
9 个文件 +231/−22，base 是 dev，
mergeable_state 为 clean，作者只在本地跑过测试与构建，声明没有做真实部署或浏览器验证17。时间要标清楚：它在北京 23:16 开出，比本窗口起点早约 6 分钟，上一期没有收，所以补在这里。它仍未合并。
CLIProxyAPI issue #6689 在北京 23:26 以 closed / not planned 关闭。上一期已报过它的内容，这条到此闭环18。
CLIProxyAPI issue #6685 在北京 23:36 追加一条评论。报障人 MintOcha 说明本地仓库副本因自动更新脚本重启 Docker 时没拉 git、落后上游 main 约一千个提交，诊断是跑在陈旧文件上的，并为噪音道歉19。上一期已报过维护者的复核结论，这条把报障收尾。
CLIProxyAPI PR #6169 在窗口内更新（北京 00:21），仍是 open、非 draft，56 个文件 +4927/−39，head 从
PinableAgents:main 合向 dev；标题只有 merge 一个词，正文空，没有新信息20。sub2api PR #7962 在窗口内更新（北京 00:03），open、非 draft，60 个文件 +3216/−386，base 是 main21。
它的正文写的是把下游的取消与超时传下去、把「投递失败」与「上游故障切换信号」分开，并避免用量已经上报之后再重试又计一次费。这条没有新评论21。
codex-proxy 与 codex2api 窗口内 0 条条目更新；codex-proxy 的预发布版仍没有占上
latest4。五、上游与额度侧
OpenAI 状态页本轮全绿：All Systems Operational、活动事件 0 条、25 个组件没有降级22。
最近一条有记录的仍是 10 月 14 日那条 Compliance API 成本数据延迟，它已在 10 月 16 日 18:44（北京）转正22。
Anthropic 状态页是 All Systems Operational，10 月 16 日一栏仍写着 No incidents reported today23。
Google Cloud 的事件列表仍是 7 条，最近一条仍是 10 月 8 日到 9 日的 Cloud Storage24。
Codex 重置追踪站上，今天（UTC）没有重置。最近一次已验证的全局重置在 34 小时前，即 10 月 15 日 06:13 UTC、北京 14:1325。
累计是 54 次全局、10 次 banked，节奏约每 4 天；模型口径 18% 与 33%，counted 口径是 24 小时 50%、48 小时 75%25。
页面上那个「Announced target time」的倒计时仍挂着，公告区同时写着现在没有官方的重置窗口25。
被这套口径计为提示的仍是 10 月 16 日 12:30（北京）那条回帖，提示在帖出 60 小时后失效25。
本刊核了 @thsottiaux 的时间线：窗口内没有新帖，最近一条停在 10 月 16 日 13:51（北京）26。
另一个追踪站记最近一次为 10 月 15 日 04:55 UTC，自 2025 年 9 月以来 62 次，中位间隔 3.1 天，最长等了 68 天27。
官方开发者社区 Codex 分区窗口内新增一条，北京 23:09 发出，标题是「Sudden extreme reduction in remaining usage」28。单条未验证，登记不展开。
其中最近的一条是 r/OpenAI 的「Sol 6.1 burns 3x/4x more usage lately」，北京 23:20 发出，比本窗口起点早 63 秒，按收录口径不收29。
六、未闭合项（下期继续跟，不作结论）
- CLIProxyAPI：本窗口登记 #6692，补入 #6691（窗口起点前 6 分钟），关闭 #6689，dev 收进
088e4457；继续跟088e4457什么时候切出发行版、#6692 有没有人接、#6691 会不会合并，以及 #6688、#6686、#6682、#6687、#6681、#6683、#6679、#6680、#6676、#6677、#6515、#6675、#6605、#6669、#6670、#6661、#6667、#6659、#6671、#6673、#6625、#6603、#6500、#6169 - sub2api：本窗口登记 #8165，#7962 更新；继续跟 #8165 会不会合并，以及 #8164、#8163、#8161、#8160、#8157、#8158、#8159、#8155、#8151、#8139、#8135、#8136、#8142、#8143、#8146、#8147、#8127、#8125、#8123、#7962、#7398
- codex-proxy：本窗口 0 条；继续跟 v2.1.18 正式版会不会打上
latest - codex2api：本窗口 0 条；继续跟 #793
下期优先回看三条：
088e4457 什么时候进发行版；#6692 有没有人接；#8165 会不会合并。References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex2api Releases
github.com
- 4codex-proxy Releases
github.com
- 5CLIProxyAPI #6692
github.com
- 6
- 7
- 8
- 9
- 10提交 088e4457
github.com
- 11meta_executor_stream.go（dev）第 148–188 行
github.com
- 12
- 13CLIProxyAPI #6688
github.com
- 14sub2api #8165
github.com
- 15
- 16迁移 246
github.com
- 17CLIProxyAPI #6691
github.com
- 18CLIProxyAPI #6689
github.com
- 19CLIProxyAPI #6685
github.com
- 20CLIProxyAPI #6169
github.com
- 21sub2api #7962
github.com
- 22OpenAI Status
status.openai.com
- 23Claude Status
status.anthropic.com
- 24Google Cloud Status
status.cloud.google.com
- 25codex-reset.com
codex-reset.com
- 26@thsottiaux
x.com
- 27opentherank
opentherank.com
- 28社区帖 1406982
community.openai.com
- 29r/OpenAI 1x7j1um
reddit.com
- 30r/ClaudeAI 1x7if1u
reddit.com
- 31CLIProxyAPI #6690
github.com
- 32sub2api #8164
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.