v8.0.36 与 v8.0.37 的三笔改动，19 分钟里被同一位报障人开了四张单；sub2api 把国产限频当成窗口耗尽
v8.0.36 与 v8.0.37 那三笔改动各自带出的问题，被同一位报障人在 19 分钟里逐条交回；本篇给出四张单的触发条件、今天能改的键，以及 sub2api 把国产限频当成窗口耗尽时怎么解冻。
三个结论先放前面。
第一，CLIProxyAPI 在北京时间今天 11:22 到 11:41 之间新开四张单，作者是同一个人 fredcamaral，下文说的报障人就是他。四张单都在讲「上一轮改完的地方又出问题了」。1234
第二，四张单指向三笔已经发出去的改动：v8.0.36 的 aadb34f9 与 20c9095c、v8.0.37 的 06fd5b8b。三条分别落在 v8.0.36 起的两处与 v8.0.37 起的一处，今天跑 v8.0.36 到 v8.0.38 的实例都在其中至少一条的影响面里。
第三，四张单全部还是 open，一笔都没进任何 tag。等下一版解决不了今天的账。
一条 400 把已经生成的回答连 usage 一起吞掉
非流式的症状：客户端收到 HTTP 400，body 里
error.type 是 invalid_request_error、error.code 是 context_length_exceeded。已经生成的文本、工具调用和 usage 一起消失。流式的症状是另一种：文本分片照常发出去，随后一个 error 事件，没有
finish_reason，也没有末尾那条 usage。OpenAI 的 SDK 在流里收到 error 就直接抛错，已经流出去的内容多数调用方接不住。上游那头照常计费。代理自己记下了用量，客户端的成本统计却少一笔；客户端若原样重试，等于再付一整窗输出。
Anthropic 把这条
stop_reason 写在成功响应里，处理方式是「按截断对待」。5 OpenAI 那边，context_length_exceeded 指的是输入塞不进窗口、请求在生成前就被拒。1触发条件很具体：Chat 客户端不传
max_tokens 时，翻译器按模型的输出上限注入一个值。6 长对话里输入加这个上限超过窗口，Claude 就以这条原因停下。
v8.0.38
internal/translator/claude/openai/chat-completions/claude_openai_response.go 第 261–263 行：message_delta 一认出这条终止原因就返回 error 对象，第 265 行的 finish_reason 分支因此走不到。这套分支由 aadb34f9 带进 v8.0.36；v8.0.35 的同名文件里还没有它。7
executor 侧还有第二道：拿到这个 error 体后按
context_length_exceeded 改写成 HTTP 400。8今天能绕过去：客户端显式带
max_tokens 或 max_completion_tokens，让 Claude 先撞输出上限。那条原因映射成 finish_reason: length，文本与 usage 都保住。报障人十九分钟后的追加评论里补了一处同路径的旧毛病：映射改对之后，非流式响应若在工具调用中途被截断，
finish_reason 仍然是 tool_calls，因为那段代码只要收集到工具调用就写 tool_calls。他给了补丁：
toolCallsCount > 0 之外再加一个 finishReason != "length" 的判断。这处毛病在 max_tokens 上早就存在，改映射时顺手带上。同一个终止原因，在 Responses 侧被标成「失败」
这里回的是
response.failed，status 写 failed，error.code 还是 context_length_exceeded。输出项与 usage 都还在信封里，状态却说这条响应失败了。2OpenAI 遇到同一情形的说法不同：
status: incomplete，incomplete_details.reason 写 max_output_tokens。本刊核过 Anthropic 文档那句「按截断对待」，两种协议对同一件事的口径差着一整个状态字段。
v8.0.38
internal/translator/claude/openai/responses/claude_openai-responses_response.go 第 203–205 行构造错误对象，第 223–229 行先把它判成 response.failed，incomplete 那一支轮不到。差别落在钱上。Codex 收到
response.failed 加这个 code 会当成上下文满，提示用户开新线程，信封里的 usage 丢掉；收到 response.incomplete 它会记下 usage。2WebSocket 那条路更早就踩过：本刊 10 月 21 日写过，转发层不把
response.failed 当终局，一条正常结束的流被记成 408 断连。今天没有配置项可改，只能等 #6862 被接。SSE 客户端若只看
status，会把自己已经拿到的输出当成失败丢掉。cloak_mode: never 把指纹头改回硬编码那一套
这是四张单里唯一与风控直接相关的。报障人给了一张对照表，配置基线 2.2.0、调用方 2.2.5。
auto 模式下，上行 UA 是 2.2.5、包版本 0.128.0。同一请求换成 never，上行变成 claude-cli/2.1.280、包版本 0.112.1。body 里的
cc_version 仍是 2.2.5.179。3函数里那次复检因此按硬编码的 2.1.280 基线做，没用运维配的
claude-header-defaults。配置基线在 2.2.x、客户端也在 2.2.x 时，第一次检测通过、第二次不通过，落进未确认分支。未确认分支做的事是把五个指纹头一起换成硬编码常量。body 原样透传，计费块还写着调用方的 2.2.5。
上游看到的是「一个自称 2.1.280 的客户端，带着 2.2.5 的计费块」。头体不一致正是 #6812 要修的那件事，这次修复自己又造了一遍。
v8.0.38
internal/runtime/executor/claude_executor_request.go 第 1629–1630 行的 never 分支传 nil；同一函数第 1643 行的通用分支传的是 cfg。影响范围是 v8.0.36 到 v8.0.38，由 20c9095c 引入。本刊 10 月 21 日把那笔提交记成 v8.0.36 的收尾之一，今天它成了第 3 条。
今天能改：把
cloak_mode: never、cloak.mode: never 与全局 disable-claude-cloak-mode: true 这三处去掉。auto 已经能保留确认客户端的头，对照表第一行就是证据。11请求级 401 规则判得太晚，只带 access token 的凭证被永久拉黑
tryRefreshAfterUnauthorized 在 conductor_execution.go 第 607 行先跑，matchRequestScopedErrorAction 到第 642 行才判。12中间那一步已经把失败的 token 记成被拒。13 报障人 bisect 到 v8.0.37 的 06fd5b8b：从那笔起，这行标记不再先看凭证有没有 refresh token。
后果只落在一种凭证上：只有 access token 的。token 被记成被拒之后，后续请求直接回
auth_unavailable，一次上游都没打出去。4可达条件写在配置里：你给 401 配过请求级规则。
oauth-request-scoped-errors、每个 key 的 request-scoped-errors、凭证 metadata 的 request_scoped_errors 三处都算，动作 stop 与 continue 都中。规则本意是「这个 401 是这条请求的问题，别冷却凭证」。结果凭证被拉黑，规则到得太晚。
重启进程会清掉，因为这个字段本来就不落盘。15
报障人自己划了边界：没有规则命中的 401 照旧判成 token 死了，那种处置他认为是对的。
四张单的共同点
这四张单都在修上一轮修过的地方。aadb34f9 是 v8.0.36 为 #6800 写的，20c9095c 同一天为 #6812 写的，06fd5b8b 是 v8.0.37 的 SIWC 只读状态提交。
三笔进发行版时都带着「已经改好了」的语气。两天后，同一个人把它们的反面逐条交回来。
这四张单的质量很高：复现步骤、精确到行、测试怎么改，还有能在自己 fork 上跑通的 diff。合并速度却要看维护者。
所以今天按上面四条绕，别把「等下一版」当方案。
sub2api 把国产 Coding Plan 的限频当成窗口耗尽
智谱的 Coding Plan 除滚动窗口额度，还有一层请求频率限制。额度只用 12% 与 4% 时，一次并发突发就能收到错误码 1302 加一句「您的账户已达到速率限制，请您控制请求频率」。16
sub2api 收到 429 后走
applyCNProviderReactive429：第一步认余额不足文案，第二步对 Coding Plan 一律冷却到配额快照里最早的未来窗口重置点。17频率限制在这条路上与额度耗尽同一个命。冷却终点是 5h 窗口还是周窗口，取快照里更早的那个。
v0.2.17
backend/internal/service/ratelimit_cn_providers.go 第 291–295 行：注释写着「429 多由 5h 窗口触发，取较早点避免过度停调」，代码里没有任何按文案或按已用比例区分的分支。报障人做了 8 次线上实测，全是纯频控，触发时 5h 用量 12%、周用量 4%。其中两条：10-20 16:18 触发、冷到 20:42，4 小时 24 分；10-21 20:39 触发、冷到次日 01:29，4 小时 50 分。最短一次 1 小时 23 分，期间唯一的恢复手段是手动清除错误。16
PR 的做法是先分类再降级，两道护栏都过了才走默认的秒级冷却（默认 5 秒，管理端可配 1 到 7200 秒）。
第一道在响应体上：出现「额度」「已用尽」「用完」「quota」「usage limit」「insufficient」「balance」任何一个词，就不算频控。第二道在快照上：任一窗口到 90%，或快照缺失，仍按窗口冷却。
这样真实耗尽不会被降级成秒级冷却，代价是快照最多滞后一个探测周期（默认 10 分钟）。
PR 还开着，v0.2.17 里没有这段。今天能做的两条：面板上调
POST /api/v1/admin/accounts/:id/clear-error，或 DELETE /api/v1/admin/accounts/:id/temp-unschedulable 解冻。18另一条是把这类账号的并发压到上游限频以下，多号分摊。上游的限频是秒级的事，挂一小时是本地自己的判断。
四仓与上游现状
| 仓库 | 当前版本 | 主干头（北京） | 窗口内条目 |
|---|---|---|---|
| CLIProxyAPI | v8.0.38 | dev 10-22 10:56、main 10-21 23:04 | #6861、#6862、#6863、#6865、#6864 |
| sub2api | v0.2.17 | main 10-22 10:33 | #8286 |
| codex-proxy | v2.1.20-beta.0543eaa | dev 10-21 09:58 | 0 |
| codex2api | v3.1.1 | main 10-21 01:01 | 0 |
窗口里还有一张 CLIProxyAPI 的功能请求：#6864 想让选号按请求协议对齐同协议上游。23
例子是 DeepSeek 同一个模型给了 Responses、Anthropic Messages、Chat Completions 三个官方端点，接成三个 provider 后希望
/v1/responses 优先打 Responses 那个。默认关闭，无实现。上游那条事件还挂着。OpenAI 的「ChatGPT conversion failures in India, Japan and Korea. And Response API errors」于北京 10:18 开出，10:42 转 monitoring，至今未恢复。
两个组件仍标着降级：Responses 与 Conversations。24
Claude 状态页全绿，最近一次事件是 Fable 5 降级，今天凌晨 04:29 已恢复。25 Google Cloud 最新一条仍是 10 月 20 日 europe-west2 的多服务中断。26
重置信号：今天 UTC 还没重置，最近一次已验证的全局重置在 45 小时前（北京 10 月 20 日 14:33），累计 56 次、10 张存着，24 小时概率 22%、48 小时 39%。27
今天要做的三件事
- 查
cloak_mode: never与disable-claude-cloak-mode: true。有就改回auto，改完抓一条 Claude 请求确认上行 UA 与 body 的cc_version是同一个版本。 - 给走 Claude 通道的 Chat 客户端补
max_tokens，或在payload.override里压一个更小的值。补完拿一条长对话试，确认截断时拿到的是finish_reason: length与 usage。 - 搜一遍请求级错误规则里的
status: 401。有就去掉，已经中招的凭证靠重启进程解，别指望cooldown/reset。
References
- 1
- 2#6862 Responses 侧把同一条终止原因标成 failed
github.com
- 3#6863 cloak_mode never 按硬编码基线校验确认客户端
github.com
- 4#6865 请求级 401 规则在刷新之后才判
github.com
- 5Stop reasons and fallback
platform.claude.com
- 6
- 7v8.0.35 的同名文件
github.com
- 8
- 9
- 10
- 11
- 12
- 13
- 14ResetQuota 实现（v8.0.38）
github.com
- 15
- 16
- 17
- 18admin 路由（v0.2.17）
github.com
- 19CLIProxyAPI 发行版
github.com
- 20sub2api 发行版
github.com
- 21codex-proxy 发行版
github.com
- 22codex2api 发行版
github.com
- 23
- 24OpenAI 状态事件 01M5GPE9C4E19HE461P8JAMYXD
status.openai.com
- 25Claude Status
status.anthropic.com
- 26Google Cloud incidents
status.cloud.google.com
- 27codex-reset.com
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.