Devin 按占位档位跑、Kimi 并发 403 仍停十分钟，本期零发版
这一小时四个中转项目都没有发版：Claude 的逐轮思考档位被读成顶层占位值，日志会错、Devin 模型会真的按最低档跑；Kimi 并发 403 仍停十分钟，改成五秒的补丁还没合。本期给出今晚能做的两处绕法与其余两条的等待状态。
北京 11-04 凌晨这一小时，四个仓库都没有发版，主干也没有新提交：CLIProxyAPI 停在 v8.0.53，sub2api 停在 v0.2.19，codex-proxy 与 codex2api 各停在 v2.1.23 与 v3.1.2。所以今晚没有「该升哪个版本」这个问题。
真正落在窗口里的只有三处动静：两条问题单指向同一件事——Claude 的逐轮 effort 指令被读成了顶层的占位值，其中一条只是日志错，另一条会让 Devin 真的跑错档、多花钱；一张配套补丁把 Kimi 并发 403 的冷却从十分钟压到五秒；还有一张缓存读价的补丁在刚才（北京 01:16）收到了作者回复。
前两条都需要你在十分钟内判断一次「我会不会中」，第三条只影响关掉远端价目同步的实例。
先做一次交集自检
| 你在跑什么 | 会踩到的现象 | 错在哪一层 | 今晚 |
|---|---|---|---|
带 mid-conversation-output-config-2026-07-01 beta 的 Claude 请求 | 用量日志里 reasoning_effort 是顶层那个值 | 只错记录 | 不用动，等 #7236 |
devin/ 前缀的 Claude 模型（如 devin/claude-opus-5-5） | 每条都按 low 档跑、按 low 档计费 | 错在执行与成本 | 现在就能绕 |
| Kimi 号并发打满 | 一次 403 让该账号停十分钟 | 错在状态 | 今晚只能压并发或手动解冻 |
| 关掉或拉不到远端价目同步 | Sonnet 5.5 缓存读按 $0.20/MTok 计 | 错在计费 | 现在就能改 |
一、顶层那个 effort 值只是占位符
新版 Anthropic 允许在对话中途改思考档位：客户端会发一条
role=system 的消息，带上 output_config.effort。为了让 prompt cache 不失效，发这条指令的客户端会把顶层 output_config.effort 钉成一个固定值——报障人自己用的 pi 客户端就把它固定成 low1。于是顶层那个值不再是用户的真实意图，只是占位符。而 CLIProxyAPI 现在两处都只看它。
记录侧：只错日志。 用量记录走
extractClaudeConfigFromGetter，函数只从请求体顶层读 output_config.effort，不遍历 messages2。后果是你的用量面板里每条请求的档位都写成 low，按档位做的统计和告警会一起失真。
internal/thinking/apply.go 第 821–842 行：第 826–827 行判完 thinking.type 之后，只取顶层 output_config.effort，没有任何遍历 messages 的分支2但实际思考强度不受影响：请求原样发上去，上游按逐轮指令执行。这条的边界很清楚——报障人把非法档位塞进指令时，上游直接回了
messages.1.output_config.effort: Input should be 'low', 'medium', 'high', 'xhigh' or 'max'，说明执行侧读的确实是那条指令1。别把这条写成「思考档位也错了」。执行侧：真的选错档。
devin/ 前缀的模型走的是另一条翻译链。copyClaudeThinkingToInteractionsDoc 先把 thinking.type 映射进 generation_config.thinking_level，随后只有顶层 output_config.effort 能改写这个字段3。逐轮指令所在的那条 system 消息在翻译时被整条跳过，指令里的档位根本没进上游请求。
thinking.type 写 thinking_level，第 91–92 行再用顶层 output_config.effort 覆盖，覆盖顺序决定了顶层占位值永远赢3今晚的绕法有两个，都不用等发版。 要么把顶层
output_config.effort 直接写成你真正想要的档位（代价是 prompt cache 可能失效），要么用模型后缀，写成 devin/claude-opus-5-5(high)——后缀在解析时优先级高于传入的 level。这两条报障人都实测过4。在等的补丁： #7236 新加了一个
ClaudeEffortDirective 函数，倒序遍历 messages，取最后一条带 output_config.effort 的 system 消息；用量侧与 Devin 侧都改成优先用它5。
internal/thinking/claude_effort_directive.go 全文 47 行：第 26–37 行遍历 messages 并让后出现的值覆盖前一个，第 38 行返回最后一条；注释第 16 行写明「客户端为了让 prompt cache 保持稳定会钉住顶层值」6这张单的状态：开于北京 00:53，截至现在仍是 open、非 draft、可合并（clean），5 个文件 +175/−1，单笔提交5。它刻意只改
internal/thinking 与 Devin 执行器、不碰 internal/translator——后者的改动会被仓库的路径守卫直接拒掉，这也是这类修复经常绕道的原因。二、Kimi 并发 403：从十分钟改成五秒，但还没合
上一期写过 Kimi 的并发 403 会触发账号级停调7。当时那个十分钟不是设置项，是代码里的常量：
handleCNProviderConcurrencyLimit403 直接用 openAI403CooldownMinutesDefault 算出停调截止时间，写进账号级临时不可调度8。
handleCNProviderConcurrencyLimit403 用同一个常量算截止时间，再调 setCNProviderTempUnschedulable 写账号级停调——整段没有任何读取设置的分支8这里有个必须说清的坑：今天在面板里把 429 冷却改成几秒，对这条 403 无效。 429 兜底冷却（默认 5 秒、可设 1–7200 秒、可关）走的是另一条函数，与上面这段常量互不相干9。改设置不会让 Kimi 账号少停九分多钟。
补丁 #8503 做的正是把两者接起来：改调
apply429FallbackRateLimit，于是停调时长变成 429 冷却那个值，默认 5 秒；仍然返回「需要换号」，不会把并发打满的请求硬留在同一张凭证上重试10。4 个文件 +180/−14，开于北京 00:44，open、可合并（clean），Fixes #8502，而 #8502 本身还开着、零评论7。今晚能做的还是老三样： 降并发或加号；已经把号停掉的，用
GET/DELETE /api/v1/admin/accounts/{id}/temp-unschedulable 手动解冻，不必等那十分钟11。合并之后再来那一波并发，才会变成「停五秒、换号继续」。三、Sonnet 5.5 的缓存读，兜底价还是两倍
这一条不是今晚新出的，是一张 10-27 就开着的补丁在北京 01:16 收到了作者回复。既然它落在窗口里，顺手清一下会踩到的人。
官方价目上，Sonnet 5.5 的缓存读是 $0.10/MTok，缓存写 $2.50/MTok，输入 $2、输出 $1012。而 sub2api v0.2.19 的两处兜底价都是 0.2e-6，也就是 $0.20/MTok——两倍：随包的内置价目表里这么写，
pricing_service.go 里按模型族匹配的硬编码兜底也这么写13。
谁真的会多付： 只有拉不到远端价目的实例。默认配置下
pricing.remote_url 指向上游价目仓库，启动时拉一次、之后每十分钟比对一次哈希，远端主分支现在已经是 $0.10，所以正常跑着的实例会自己纠正过来14。断网、内网隔离、或手动关掉同步的实例，才会一直按两倍计。今晚就能改，不用等发版： 用
pricing.override_file 给 claude-sonnet-5-5 的 cache_read_input_token_cost 写 1e-7，覆盖文件优先级最高；改完按内容哈希自动重载，不用重启。顺手在日志里搜一次 [Pricing]，看同步到底有没有跑成功——作者也是让对不上的人先贴这段日志14。版本位与上游
- CLIProxyAPI v8.0.53，发布于北京 11-03 20:24；HEAD、main、dev 与标签同一个提交，主干上零新提交15。
- sub2api v0.2.19，发布于北京 10-28 18:16；主干最近一次合并是 11-02 11:17，窗口内无新提交16。
- codex-proxy v2.1.23（北京 11-03 19:49）17、codex2api v3.1.2（北京 10-28 04:39）18，两者窗口内均无新条目。
- 上游三处都安静：OpenAI 状态页最近一条事故是「ChatGPT 文件上传报错」，北京 11-03 08:47 开始、13:40 已恢复，在窗口之前19；Anthropic 与 GCP 窗口内无新事件2021。
- 额度重置还是没动静：codex-reset 的最近一条承诺停在 11-02 23:51（北京），信号标记为未激活，最近一次经验证的重置仍是 10-2822；opentherank 记 71 次重置、中位间隔 2.9 天23。官方 Codex 分区窗口内没有新帖，最新一条是窗口前的容量抱怨24。
今晚只动两件
Devin 那条现在就能绕，改顶层 effort 或加模型后缀，改完拿一条请求去核对用量里的档位。Kimi 那条今晚靠压并发与手动解冻，别指望面板里的 429 冷却设置。剩下两条都在等合并：#7236 一旦落地，日志与 Devin 选档会同时正常；#8503 落地后，下一次并发打满只会停五秒。
References
- 1
- 2apply.go v8.0.53 第 821-842 行
github.com
- 3
- 4
- 5
- 6
- 7Bug：Kimi 并发上限 403 被当成账号故障停调
github.com
- 8
- 9ratelimit_service.go v0.2.19 第 76-94 行
github.com
- 10
- 11routes/admin.go v0.2.19 临时停调解冻接口
github.com
- 12Claude 官方价目
claude.com
- 13pricing_service.go v0.2.19 第 147-158 行
github.com
- 14
- 15CLIProxyAPI v8.0.53
github.com
- 16sub2api v0.2.19
github.com
- 17codex-proxy v2.1.23
github.com
- 18codex2api v3.1.2
github.com
- 19File upload errors in ChatGPT
status.openai.com
- 20Anthropic 状态页
status.anthropic.com
- 21Google Cloud 事故列表
status.cloud.google.com
- 22codex-reset
codex-reset.com
- 23opentherank codex reset
opentherank.com
- 24OpenAI 开发者社区 Codex 分区
community.openai.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.