Pro 100/200/500 三档额度今日翻倍；丢 mcp__ 前缀那条，补丁和两张单全被关掉
四仓零发版的一小时里，上游把 Pro 三档额度翻倍、Codex 侧 Pro 200 保持不变，丢 mcp__ 前缀的补丁与两张单全部关闭，上期的 WebSocket 请求体滞留已进 dev。
窗口从北京 10-30 00:23 到 01:29（UTC 16:23–17:29）。四个仓库这一小时都没有新版本，主干上只多了一次合并。
| 仓库 | 当前版本 | 发行页最后变动（北京） |
|---|---|---|
| CLIProxyAPI | v8.0.47 | 10-29 08:32 1 |
| sub2api | 0.2.19 | 10-28 18:16 2 |
| codex-proxy | v2.1.21 | 10-28 04:48 3 |
| codex2api | v3.1.2 | 10-28 04:40 4 |
这一小时有四件事要记：
- 上游把 Pro 三档的额度翻了一倍，北京 00:56 官宣，当天生效。
- 丢
mcp__前缀这条路被彻底关掉：补丁先被作者自己关掉，新单再被判 not planned。 - 上期那条 WebSocket 请求体滞留已经进了 dev，等下一个 tag。
- 插件凭据的按需刷新开出一张近六千行的补丁，作者的测试结论要读完整句才知道能不能碰。
Pro 三档额度翻倍，Codex 侧 Pro 200 保持不变
北京 00:56，Codex 与 ChatGPT 的负责人 Tibo 在 X 上发了一条，开头的口径是「Day 25/」：
We are doubling all usage limits for all Pro 100/200/500 tiers and Business Premium, effective today.
同一段里补了三句：Pro 200 的额度不再下调，所以 Work 与 Codex 的用量保持不变；dot 的扩展额度继续提供；dot 的用量仍然与默认额度分开计算 5。
对中转站来说，要动的只有一类数字。按百分比设的阈值不用改：额度翻倍之后，用量比例的读数仍按比例换算，
codex_5h_*、codex_7d_* 那套判定照旧生效。按绝对额度或并发数算的容量预算要按新上限重算一遍。号池里如果有 Pro 200 的 Codex 账号，别把这一档算进翻倍：官方原话只说不再下调它的额度，用量保持不变。
这件事与「重置」是两回事。追踪站今天仍写着今日 UTC 没有重置，最近一次已验证的全局重置在 35 小时前（北京 10-28 14:35），累计 61 次、还有 10 次没用掉 6。
丢 mcp__ 前缀：补丁先被作者关掉，新单再被判 not planned
这条路本刊 10-28 那期写过：Claude OAuth 的伪装路径上，工具名会被改写成
mcp__<虚拟服务名>__<插入词>_<原工具名>，模型偶尔只吐回后半截。这一小时里，它的四个节点全部落定。- 10-22 11:08，同源的旧单 #6848 被维护者 luispater 关成 not planned，理由是上游模型输出漂移 7。
- 10-29 02:25，外部贡献者开出补丁 PR #7085，做法是按语义后缀唯一匹配，把无前缀的名字还原回去 8。
- 10-29 07:20，这张补丁被作者本人关掉，没留说明；随后头分支被删除，自动评审里那两条未解 P2 就此作废。
- 10-30 00:05 开出 #7107，报障更细；00:22 维护者再答一次，标记 not planned 关闭 9。
维护者这次的措辞把理由说全了：完整名字一直写在发给上游的
tools 与消息块里，mcp__<server>__ 这一段就是命名空间的边界，用来区分「为这次请求临时分配的虚拟 MCP 别名」与「客户端自己声明的无前缀工具名」。因此官方不打算为无前缀的工具调用补回退。
代码这一版没动。还原函数从第 2407 行开始，先查完全匹配表，第 2416 行取
mcp__ 之后的服务名，第 2417–2419 行判定服务名不在已知表里就直接返回空名与 false，这一段没有任何日志 10。今晚的三条路，按代价从低到高：
- 关掉伪装。 配置项
upstream.claude.disable-claude-cloak-mode: true，或在凭证 JSON 里写cloak_mode: never。别名改写整段不跑，丢前缀这一类随之消失；代价是 Claude Code 伪装一起停用，上游能看到的客户端特征变多 12。 - 把名字缩短。 别名是三段拼出来的长串，插入词还是 BIP-39 词表里的词，模型逐字抄写时更容易掉前半截。这条是本刊从拼装规则推的，没有对照数据。
- 客户端兜底。 看到
Tool X not found. Did you mean Y?就重启这一轮会话。报障人写过，那个假名字会被喂回对话历史，继续污染后面的轮次 13。
上期的 WebSocket 请求体滞留已经进 dev
北京 00:42，PR #7106 合进 dev，6 个文件 +361/−3，合并提交
8dfb45d2 14。dev 的头就是这一笔；发行 tag、main 与 v8.0.47 还是同一个提交 90c447d3 15。判断你手上的实例修没修，看它跑的提交是不是
8dfb45d2 之后。没有就是上期描述的形态：一条 WebSocket 连接最多持 32 MiB 的请求体副本，连接活多久留多久。插件按需刷新：#7108 开了，还不到能上的时候
北京 00:52 开出的 PR #7108，59 个文件 +5882/−148，base 是 dev，三笔提交，说明里写着
Closes #6653 16。它补的是插件凭据的一个死角：令牌过期时，选号在原生插件执行之前就把这个账号拒掉，插件自己没机会在第一次请求前刷新 17。契约是
AuthData.RefreshPolicy 加 schema-9 的 "on-demand"，不写这个字段就保持旧行为；只对「有物理文件的原生插件凭据」逐账号开启。先说不能上的理由，也要读完整句。作者写的是：受影响八个包的
go test -race 通过；全量 go test ./... 与 -race 仍然是红的，而这些失败在干净的 dev 基线上同样复现 16。也就是说，红的部分在这张补丁之前就红着。今晚要用的是现成的那个接口：
POST /v8/management/credentials/refresh，配合 GET /v8/management/credentials 看每条凭据的 status 与 unavailable 18。
server_management_v8.go 第 42–58 行：第 45–52 行是凭据的增删查改与刷新，第 52 行的 POST /credentials/refresh 就是今晚能手工触发的那条。18Claude 的工具失败被当成成功：#6838 重基
Claude 的
tool_result 带 is_error: true 时，转成 Gemini 请求会把这个语义整个丢掉。v8.0.47 在 case "tool_result" 里无条件写 functionResponse.response.result，没有 error 分支 19。于是一次「权限拒绝」到了模型那边，就是一次普通返回。模型按成功继续往下推，你看到的是它在同一条走不通的路径上反复重试。
result 的骨架，第 182–186 行按原始 JSON 与纯文本二选一写入，全程没有 error 字段。19补丁在北京 00:43 重基，4 个文件 +147/−6，唯一一笔提交的作者时间是 16:33。改法只有一条：字面布尔
true 才发 functionResponse.response.error，省略、false、null、字符串与数字都保持原来的成功语义 20。它的范围只到 Gemini。同版本的 Antigravity 译层里同样搜不到
is_error 21，走 Antigravity 的那条路这次不在补丁里。今晚的判据与处置：客户端显示工具失败、模型下一步却像拿到了成功结果，就先怀疑这一层。依赖工具失败语义的分组，把 Claude 请求留在 Claude 侧，暂时别转到 Gemini 或 Antigravity。
sub2api：监控探针的补丁来了
上期报过的那条——渠道监控对只开
/v1/responses 的 Grok 上游必然报红——现在有了补丁。PR #8422，15 个文件 +214/−41，Fixes #8413，默认仍走 Chat Completions，只是允许把 Responses 选上，编辑监控时也会保留所选协议 22。mergeable 状态是 unstable，还没有评审。同一小时里 sub2api 另开了一张 Creem 支付的补丁（39 个文件 +1665/−11）23，以及一张 5 月 12 日就开着的旧单被重推（Redis TLS 与 Bedrock 路由）24。这两条与升级动作无关，只作登记。
上游与社区
- OpenAI 状态页 All Systems Operational，组件没有降级项 25。
- Anthropic 最近一条事件在北京 10-29 00:19 到 04:05，影响 Google Calendar 连接器，已恢复 26。
- Google Cloud 8 条在架记录，最新一条最后更新于北京 10-28 08:38 27。
- 重置追踪：今日 UTC 没有重置，最近一次已验证的全局重置在 35 小时前，累计 61 次、10 次未用 6。
- r/OpenAI 有两条帖子讲这次额度调整。一条标题「Usage doubled!」，北京 01:04 发出，42 分、10 条评论，正文只有一句「Aka..usage is what it used to be.」 28；另一条「Usage limits going back to normal and not halved」，01:08 发出，5 分、6 条评论 29。两条都是用户自述，没有截图或对照数据；它们讲的是同一次调整的两面，一处在翻倍，一处不再下调。
今晚可做的
- 现在就能改：伪装开关（要接受伪装失效）、按绝对额度算的容量预算、插件凭据的手工刷新。
- 等发版：WebSocket 请求体滞留（等
8dfb45d2之后的 tag）、Gemini 工具失败语义（等 #6838）。 - 只需记录：额度翻倍（百分比阈值不动）、sub2api 的监控探针补丁、Creem 支付接入。
References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5@thsottiaux 的公告帖
x.com
- 6codex-reset.com
codex-reset.com
- 7issue #6848
github.com
- 8PR #7085
github.com
- 9issue #7107 的关单评论
github.com
- 10claude_executor_request.go 第 2407–2419 行
github.com
- 11claude_executor_execute.go 第 214 行
github.com
- 12config.example.yaml 第 459–471 行
github.com
- 13issue #7107
github.com
- 14PR #7106
github.com
- 15v8.0.47...dev 的差异
github.com
- 16PR #7108
github.com
- 17issue #6653
github.com
- 18server_management_v8.go 第 44–56 行
github.com
- 19gemini_claude_request.go 第 163–190 行
github.com
- 20PR #6838
github.com
- 21antigravity_claude_request.go
github.com
- 22PR #8422
github.com
- 23PR #8423
github.com
- 24PR #2420
github.com
- 25OpenAI Status 摘要
status.openai.com
- 26Anthropic Status 事件列表
status.anthropic.com
- 27Google Cloud Status 事故列表
status.cloud.google.com
- 28Usage doubled!
reddit.com
- 29
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.