v8.0.39 发出：超上下文从「错误」改成「截断」，用量记录多出实际发出的档位
CLIProxyAPI v8.0.39 今晚发出：Claude 超上下文从 HTTP 400 改判为 finish_reason=length 与 response.incomplete，用量记录多出实际发出的档位；另附 WebSocket 逐轮鉴权、Codex 引导缓冲名单，以及 sub2api 里同一个病根的修复还没发版。
北京时间今晚 21:18，CLIProxyAPI 发出 v8.0.39。dev 上积压的活儿一次推完：16 笔提交、94 个文件的改动1。
其中四处会改变你在下游看到的东西。超上下文从一条错误变成一次普通截断，用量记录多出一个字段。
另两处只在特定用法下才碰得到：Responses 的 WebSocket 改成逐轮鉴权，Codex 的引导缓冲多收一个事件。
前两条要动客户端或面板。上一期结尾列的三张单，#6870、#6871、#6872，全部在这个版本里。
超上下文：从一条假错误，变成一次普通截断
v8.0.38 遇到 Claude 以
model_context_window_exceeded 停下时，会自己造一个错误。Chat Completions 那一侧回 HTTP 400、码写
context_length_exceeded，已经生成的文本和用量一起丢掉2。Responses 那一侧把它写成 response.failed。
length 这一个出口。3
影响落在客户端那一行判断上。以前收到 400 就知道「上下文满了，该压缩」。
现在这一轮正常结束，判断要挪到
finish_reason 或 incomplete_details.reason 上。没改的客户端会把截断当成正常答完，接着往下问，下一次仍然撞墙。计费口径跟着变。那 400 会把这一轮的输出用量一起吞掉；现在按实际生成的 token 记账，账单会比以前高一点，这是原本就该记上的部分。
相邻的一条路照旧。上游自己回 400、消息以
prompt is too long 开头时，代理仍会补上 context_length_exceeded 这个码。Codex 引导缓冲：多收一个 response.metadata
这一条只跟开了
upstream.codex.stream-bootstrap-buffering: true 的实例有关。示例配置里它的默认值是 false5。v8.0.38 的可缓冲名单是 created、in_progress、codex.rate_limits、codex.response.metadata、keepalive6。
上游现在会在 in_progress 之后、
server_is_overloaded 拒答之前插一个 response.metadata。这个事件不在名单上，缓冲就此收手、把流放给客户端。紧随其后的拒答于是原样漏出去，换号的时机被错过。
v8.0.39 把
response.metadata 加进名单。作者在注释里写明它带的是 prompt 审核标记，属于握手段的帧7。
codex.response.metadata 与 response.metadata 两个拼写，前者是私有事件、后者是上游新加的。7开了这个开关就升级，升级后同一类拒答会回到换号流程。没开这个开关的实例，这条路径根本走不到。
用量记录：多出「实际发出去的档位」
旧字段
service_tier 记的是客户端请求里写的值。服务端用 payload.override 把 service_tier 改成 priority 时，用量记录里仍然是 auto。下游面板因此看不到这条请求实际按 Fast 发出8。
v8.0.39 在协议转换与 payload 规则之后，从最终出站体里取值。顺序是
service_tier、request.service_tier、interaction.service_tier，第一个非空值写进 effectiveServiceTier9。
面板里读
service_tier 的那一处，要改成读新字段才看得到实际档位。老字段含义没变，仍然是「客户端要的那个」。WebSocket：每一轮都重新鉴权
旧实现只在握手时验一次 key。之后的
response.create、response.append、response.steer 沿用握手时的身份。v8.0.39 给每一轮补了一次鉴权，结果写回请求上下文11。
插件侧的 frontend-auth 因此对长连接生效，并且能拒某一轮而不掐线。新增
DenyStatusCode 与 DenyMessage 两个字段，拒绝走 denied 错误码，默认 40312。对你的操作是：换 key、封 key 之后，已经连上的 WebSocket 下一轮就按新身份验，旧身份的残留到此为止。
上一期那三张单，外加一条文件快照
#6870（auth 目录读不到时整池注销）、#6871（OAuth 协程不持锁读配置）、#6872（race 下随机失败）三张都在本版里，各自对应一笔带 Closes 的提交。
同一批还有一条更早的单。#6844 让文件快照把运行时状态搬回来：冷却、不可用标记、下次重试时间都从内存里那份取。
被丢弃的快照也会重读一次13。
v8.0.38 只搬
credential_quota 那一种状态14。改配置触发的全量扫描，从这一版起会把正在生效的冷却保留下来。同一个病根，sub2api 的发行版还没有
上游先发
response.queued 或 response.metadata 时，这条流被判成已经在输出。随后的 overload 拒答按普通失败回给客户端，换号同样被错过。主干上已经改了。PR #8139 把这两个事件加进同一份名单，10 月 21 日 08:33 UTC 合并进 main，三个文件、+15/−116。
v0.2.17 发布于 10 月 16 日，在这笔合并之前，所以发行版里没有它17。
#8239 那条 503 报障里，本窗口有两条用户回复，说按 #8139 改完之后 503 消失18。维护者到目前为止没有回复这条单。这两条是用户自述，我没有独立复现。
跑 sub2api 的实例只有两个选择：等下一个版本，或者照 #8139 的三行改动自己打补丁。
维护者口径两条
#6876 报的是「AI 提供商不能单独使用」，报错里带
session_blocked_by_cyber_policy。维护者回复说，这句话既不是 OpenAI 也不是 CLIProxyAPI 产生的，是第三方上游拦了请求报文；单子以 not_planned 关闭19。以后再看到它，去查上游那一层。
#6879 报的是请求日志里的 IP 全变成 127.0.0.1。维护者的答复是：扫描 CPA 的情况越来越严重，代码里不再信任前置代理转发的 X-Forwarded-For20。
记录里其实有三个 IP 字段。
client_ip 取 TCP 对端地址，nginx 后面就是 127.0.0.1；resolved_client_ip 是按可信代理判定后的地址；x_forwarded_for 是原始请求头21。要把真实来源带出来，就把 nginx 的地址或网段写进
server.trusted-proxies。它默认是空列表，改完要重启22。没合并的大 PR 与上游
codex2api 的 #817 今晚 20:55 开出来，67 个文件、+13200/−229，状态 unstable、还没合并23。
内容是 Antigravity 账户配额的自动刷新、耗尽回避的硬门禁、加权选号，外加 39 项规格的集成测试。它落地之前，这些行为只能自己改源码。
上游今晚安静。OpenAI 状态页回到 All Systems Operational，最近一次事故是今早 10:18 到 16:50（北京）的 ChatGPT 与 Responses 报错，已恢复24。
Anthropic 全绿25。Google Cloud 八条事故记录里最新的一条，仍是 10 月 20 日 europe-west2 的区域断电，今天下午 16:42（北京）补上了初查报告，状态已恢复26。
Codex 今天 UTC 还没重置。追踪站的读数是：最近一次已验证全局重置在 10 月 20 日 14:33（北京）。
累计 56 次、存着 10 次未用、节奏约每两天一次，Tibo 的承诺仍标着 not landed yet27。
今晚按这个顺序做
- 备份 auth 目录，再把二进制换成 v8.0.39。
- 改客户端判断：靠 HTTP 400 识别上下文溢出的地方，换成看
finish_reason或incomplete_details.reason。 - 改面板读取：用量记录里读
service_tier的地方，补上effective_service_tier。 - 检查长连接：插件 frontend-auth 若做准入，确认它接受逐轮鉴权，要拒绝时用
DenyStatusCode。 - 需要真实来源 IP 的实例：把 nginx 地址写进
server.trusted-proxies，重启生效。 - 只跑 sub2api v0.2.17 的实例：这条 overload 修复还在主干上，等版或自行打补丁。
References
- 1CLIProxyAPI v8.0.39 发行说明
github.com
- 2
- 3
- 4
- 5
- 6
- 7
- 8CLIProxyAPI issue #6873
github.com
- 9v8.0.39 的 usage_helpers.go 第 347–375 行
github.com
- 10
- 11
- 12v8.0.39 的 sdk/access/errors.go 第 79–92 行
github.com
- 13
- 14
- 15
- 16sub2api PR #8139
github.com
- 17Sub2API 0.2.17 发行说明
github.com
- 18sub2api issue #8239
github.com
- 19CLIProxyAPI issue #6876
github.com
- 20CLIProxyAPI issue #6879
github.com
- 21v8.0.39 的 handlers.go 第 606–612 行
github.com
- 22v8.0.39 的 config.example.yaml 第 42–48 行
github.com
- 23codex2api PR #817
github.com
- 24OpenAI 状态页事件接口
status.openai.com
- 25Anthropic 状态页摘要接口
status.anthropic.com
- 26Google Cloud 事故列表接口
status.cloud.google.com
- 27Codex Reset 追踪站
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.