压缩历史被整项删掉，长会话在切号后悄悄变短
这一小时四仓零新版本：Codex 的原生压缩历史在 sub2api v0.2.17 上会被整项删掉、长会话悄悄变短，修复选择改成跨账号直接回 400；CLIProxyAPI 的 TLS 握手超时开关默认关着，该怎么设、设了会怎样都在文里。
北京 18:41 之后的这 50 分钟，四个仓库没有一个新版本：CLIProxyAPI 停在 v8.0.37，sub2api 停在 v0.2.17，codex-proxy 是 v2.1.20 的预发布，codex2api 是 v3.1.1。所以本期没有「该升级的版本」，只有两件可以现在动手的事。codex-proxy 与 codex2api 这两个仓库，窗口内连一条被更新的条目都没有。
第一件在 sub2api。Codex 的原生压缩历史在 v0.2.17 上会被整项删掉，触发点是失效密文的自动恢复；删掉之后客户端看不出来，只是提示词悄悄变短了。
第二件在 CLIProxyAPI。上游 TLS 握手有一把现成的锁，但它默认关着——不设这个键，对端收下连接却不回话时请求会一直挂着。
先认一下这类请求长什么样
判据只有一条：
input 数组里有没有 type 为 compaction（上游别名 compaction_summary）并带 encrypted_content 的项。这是 Codex 原生压缩产出的东西，网关解不开，只有签发它的那个账号能解。它和
reasoning 项不是一回事。reasoning 丢了还能重新生成，压缩项就是历史本身，删掉等于把前面几十轮对话从提示词里抹掉。v0.2.17 把两者放在同一条恢复路径上，这是问题的起点。换号就在这批场景里：另一个账号解不开这段密文时，上游回 400，自愈随即把压缩项剥掉。PR 说明里把三种场合并列——压缩规范化、账号切换、失效密文恢复——都指向同一句「提示词被静默缩短」1。
v0.2.17 里它会在哪几处被删
三处都指向同一个结果：历史被静默缩短。
失效密文的自愈。 剥离函数见到
compaction / compaction_summary 带 encrypted_content 就直接不保留（第 437–441 行，return nil, true, false）；它对 reasoning 只删字段、留骨架，对压缩项是整项丢弃。调用这个函数的是 trimOpenAIEncryptedReasoningItems，在 WebSocket 重连恢复与 HTTP 恢复两处被调用23。
sanitizeEncryptedReasoningInputItem 的三行判定：带密文的压缩项整项丢弃，与下面 reasoning 只删字段的做法不同4失效密文的血缘名单。 记录失效摘要的名单把
compaction、compaction_summary 与 reasoning 并列收进来5。某段密文被上游拒绝过一次，摘要就留在会话里，后续每一轮进场都会被预先剥掉——不是一次，是每轮。Grok 侧的压缩块恢复。 同一个剥离函数也被 Grok 的恢复路径调用6，
invalid_compaction 同样整项删。这条在修复 PR 里由测试改名反向确认：从「剥掉压缩项」改成了「永不删压缩项」。三次删除都只落一行日志。用户看到的是「上下文突然不够用了」，运维看到的是一个 400，两边对不上。
修复的选择：不删，改成跨账号直接拒
Gk0Wk 的 PR #8186 是这批改动的正主。它 10 月 17 日就开了，今天北京 19:03 又推了第三笔提交，现在 13 个文件、+416/−170，状态 open，合并检查还没干净。
改动有五条。压缩项在旧式与原生 compact 请求里都不再删除；同一账号的重试保持请求体原样不动；一旦检测到账号换了（
lastAccountID 变化）且请求带着原生压缩，就不再尝试重放，直接回 400 compaction_history_unavailable，文案直说「Native compaction state cannot be replayed on a different account; resume on the original account」，同时释放已占用的账号位。
nativeCompactionCrossAccountBlocked，不再往下走清洗7另外两条：失效密文恢复只对可重放的 reasoning 生效，WebSocket 重连那条路遇到压缩项直接跳过恢复；压缩能力的调度留给另一张单 #8204，没有并进来。
影响面要说清楚。这是把「静默变短」换成「明确拒绝」。对运维是好消息，多了一个能搜的错误码；对终端用户是「回原账号继续」。按作者在 PR 里的说明，跨账号重放本来也不成立——网关手里没有那段密文归谁的证据，与其送一份残缺历史上去，不如停在这里。
现在能做的三步（v0.2.17 上）
一、关掉客户端的原生压缩，改本地压缩。 Codex 的配置参考里，
model_providers.<id>.capabilities.remote_compaction 取 unsupported 即走本地压缩8。历史随后以普通文本项保存，跨号重试不会再出现解不开的密文。代价是压缩在你自己机器上做，长会话首字延迟会高一些。二、把这类会话钉在单账号。
gateway.max_account_switches 默认 10，改成 1 就只留一次换号机会；填 0 不会关掉换号，只会回落到代码里的内置值（Responses 入口内置 3）9。代价是账号故障时可用性下降，自己权衡。三、先去日志里确认有没有中过。 搜
invalid_encrypted_content 和 invalid_compaction 两个串。出现即说明这条会话已经走过一次剥离，历史被清过一轮；之后别再对同一会话做跨号重试。等 #8186 合进版本后，多一个可观察点：400
compaction_history_unavailable。见到它不用查上游，含义就是「这段历史属于另一个账号」。另一件事：握手没有上限，除非你设这个键
同一小时里，CLIProxyAPI 的 PR #6617 在北京 19:13 被作者自己关掉了，同分钟另一张 #6612 也关了。
它修的是个真洞。Claude 指纹通道用了自定义的
DialTLSContext，而 Go 的 HTTP 传输层在设了这个钩子时会忽略 TLSHandshakeTimeout10。对端接下 TCP 却不回 ClientHello 时，握手没有期限，请求一直挂着，request-retry 也永远不会触发。v8 里其实已经有这个开关：
requests.tls-handshake-timeout-seconds，默认值是 0，也就是关闭11。逐 tag 探过，承载它的文件在 v8.0.28 及以前不存在，v8.0.29 起才有12。
这个键的边界要记住三件事。它只管握手：计时从 TCP 或 proxy CONNECT 返回之后才开始，不绑拨号、不绑代理握手。握手成功即解除，推理与长流不受影响。两个指纹通道都管（Anthropic 与 ChatGPT/Codex），标准回退通道不管。
transientTransportErrorCode，与「连接生命周期」「请求级错误」分开处理15那作者为什么撤单？本刊能核到的两条：报障 issue #6615 已在 10 月 15 日凌晨（北京）关成 completed，v8 里也已经有了上面这个键；他的提案是硬编码 10 秒，与现成的可选开关重复。他本人的说明本轮没看到——这一句是本刊据关单时刻与代码状态作出的判断。
建议值就按他原提案的 10 秒设：
requests.tls-handshake-timeout-seconds: 10。不设，就还是老行为。简报
- CLIProxyAPI #6612（19:13 自撤）：给 devin 目录补
devin/claude-sonnet-5-5与devin/gpt-6-1-sol16。远端那份目录里这两个 ID 已经有了17，每三小时刷新一次的实例不用等它；但管理端按渠道取模型定义读的是随包的静态表，插件没声明该渠道时也不会回退到远端目录18，那里仍然没有。 - sub2api #8269（今天 18:54 并入主干）：账号配额累加改为按已设置的周期维度选语句，作者给的数是 0.77ms 降到 0.24ms19。属性能改动，未发版。
- CLIProxyAPI #6841：只改测试，3 个文件。把两处偶发失败的等待点换成回调钩子，没有运行时代码变化，不用管20。
- CLIProxyAPI #6715：把 Codex 设备码登录接进 v8 管理端（13 文件、+970/−35），窗口内把 dev 合进了自己的分支，仍在评审21。
- 上游状态：OpenAI 全绿，最近一次事故是今天 10:26 到 11:28 的降级，已恢复22；Anthropic 今日无事件23；Google Cloud 首条仍是 10 月 20 日那条多产品事件24。
- 额度读数：重置追踪站显示最近一次已验证的全局重置是 10 月 20 日 14:33（北京），距今 29 小时，累计 56 次全局、10 次可存25；另一家记 64 次，中位间隔 3.1 天，最长 68 天26。
- 社区：官方社区 Codex 分区窗口内只有一条新帖，18:58 那条「Codex Cloud vs Local 的用量差异」，没有新报障27。
本期没有需要升级的版本。两件能动手的事——关掉客户端的原生压缩、给握手设一个期限——位置都在上面。
References
- 1Wei-Shaw/sub2api · PR #8186
github.com
- 2
- 3
- 4
- 5
- 6
- 7
- 8OpenAI Codex 配置参考
learn.chatgpt.com
- 9
- 10net/http · Transport
pkg.go.dev
- 11
- 12
- 13
- 14
- 15
- 16router-for-me/CLIProxyAPI · PR #6612
github.com
- 17router-for-me/models · devin_models.json
raw.githubusercontent.com
- 18
- 19Wei-Shaw/sub2api · 合并提交 624874b313
github.com
- 20router-for-me/CLIProxyAPI · PR #6841
github.com
- 21router-for-me/CLIProxyAPI · PR #6715
github.com
- 22OpenAI Status
status.openai.com
- 23Anthropic Status
status.anthropic.com
- 24Google Cloud Status
status.cloud.google.com
- 25codex-reset.com
codex-reset.com
- 26OpenTheRank · Codex Reset Tracker
opentherank.com
- 27community.openai.com · Codex Cloud vs Local
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.