10/15 上午续报：并发成功会清掉刚写入的额度冷却，三条确定性 400 与 Argon 额度抱怨
补报 10 月 15 日 05:48 到 11:57（北京）：同一张凭证上的在途请求成功回来，会把刚写下的模型级额度冷却清掉，已耗尽的凭证于是被反复选中，修它的 PR 还没合并；另有三条会让整单失败的上游 400，以及窗口内扎堆的 Gemini 4 Argon 额度抱怨。
这一期覆盖 10 月 15 日 05:48 到 11:57（北京）。CLIProxyAPI、sub2api、codex-proxy、codex2api 四个仓库都没有出新版本，所以本期按「没有版本可升」组织，每条都标清它现在的形态：开着没合的 issue、没合并的 PR，还是已经合进 dev 但还没发版。
先看 CLIProxyAPI 上的一条并发缺陷，它会把刚写下的额度冷却提前清掉；再是三条会让整单请求失败的 400；sub2api 与 codex-proxy 各有几条待合并的改动。
现在就做
- antigravity 上挂了 MCP 工具、又撞到 400 的，先在客户端关掉那两件工具。 参数 schema 里的
discriminator被原样透传给 Google 上游就会被拒。报障给的两个工具都来自同一个 MCP 服务，关掉整个服务也有效。5
CLIProxyAPI：在途请求的成功会清掉刚写入的额度冷却
一张 Antigravity 凭证的额度已经被上游判为耗尽，回的 429 提示是
Resets in 140h36m。同一张凭证上还有别的请求在外面跑。它们正常返回 200 的时候，会顺手把这条冷却清掉。1报障人贴出的日志是一串循环。03:38:12 请求 A 派出，03:38:20 请求 B 收到上游 429（冷却在这里被写下），同一秒请求 A 返回 200（冷却在这里被清掉）。03:38:22 请求 C 因为会话亲和又落到同一张凭证上，再吃一个 429；03:38:23、03:38:25、03:38:27 两次、03:38:31 往下反复出现同一形态。1
原因在 v8.0.29 标签的源码里能逐行读到。处理执行回执的是
sdk/cliproxy/auth/conductor_cooldown.go 里的 Manager.MarkResult，从第 762 行开始。8它的成功分支是一条条件链。凭证级冷却那一条只保留
auth.Quota.Reason == "credential_quota" 的情况；按模型记账的额度走到第 827 行那一支，第 830 行直接调 resetModelState(state, now)。9
// Retain active credential-scoped cooldown，管不到按模型记账的额度；绕过它之后，第 827 行的 } else if modelKey != "" { 和第 830 行的 resetModelState(state, now) 之间只隔两次赋值。9resetModelState 自己从第 1273 行开始，它把模型状态整组清干净：Unavailable 置回 false、状态改回 StatusActive、错误清空，其中 applyCooldownFields(&state.Quota, QuotaState{}) 把额度字段全部归零，最后把 UpdatedAt 写成当前时刻。10于是「这张凭证这个模型已经没额度」这件事在内存里不再存在，调度器下一轮就把同一张凭证重新选中。
关键在于请求是什么时候派出去的。在冷却写下之前就派出的请求，它成功只能说明派出那一刻还有额度，说明不了额度已经恢复。而 v8.0.29 的
Result 结构体里没有任何时间字段可以区分这两种成功，它只有凭证版本与注册世代。2PR #6644 补的就是这条时间线。它给
Result 加了 StartedAt（派出时刻），并新增 successPredatesQuotaCooldown：冷却还活着、并且这个成功请求的派出时间早于冷却写入时间（startedAt.Before(state.UpdatedAt)）时，冷却保持不变。派发晚于冷却的成功、已经过期的冷却，以及没带 StartedAt 的外部调用，行为都和现在一样。2这条 PR 是 10 月 15 日 11:54（北京）开的，非草稿，base 是
dev，动 7 个文件、+210/−23，GitHub 给的可合并状态是 clean。到发稿仍开着、未合并，所以 v8.0.29 上这个循环还在。2眼下能做的只有人工干预：撞上这个循环时把那张凭证停掉，别等冷却自动生效——上游给的冷却可能是几天（报障里是
Resets in 140h36m），而每次在途请求成功回来都会把它清一次。把并发压下来则能降低撞上的概率，触发条件本来就是同一个模型、同一张凭证上有多个请求同时在跑。1三条会让整单失败的 400
xAI：
web_search 上带了 search_context_size。 OpenAI Responses 的客户端如果在 web_search 工具上设了这个字段（让用户自选搜索范围的客户端常这么发），它会被原样转给 xAI，xAI 直接拒掉整单：HTTP 400 {"code":"400","error":"Argument not supported: search_context_size"}。字段挂在工具声明上，所以这类客户端发往 Grok 模型的每个请求都会失败。3xAI 的 executor 里
normalizeXAITool 早就对同源的 external_web_access 做过剔除，漏掉的是 search_context_size。修复 PR #6642 把这条一次性分支换成一张「xAI 不接受的 web_search 选项」表，并且选择用黑名单而非白名单，理由是 xAI 还文档了 enable_image_understanding、enable_image_search 等字段，白名单会把它们静默丢掉。该 PR 在 12:01（北京）合进 dev，动 2 个文件、+81/−5。4antigravity：工具 schema 里的
discriminator。 报障人在 antigravity 上挂了 292 个工具（含一个 MCP 服务的两件），上游回的是 Invalid JSON payload received. Unknown name "discriminator" at 'request.tools[0].function_declarations[90]...'。触发形状是参数 schema 里 anyOf 联合旁边挂着 discriminator。5本刊在 v8.0.29 里核了这一处。
internal/util/gemini_schema.go 的 removeUnsupportedKeywords（第 1507 行）会删掉 dependentRequired、dependentSchemas、dependencies、if/then/else 等一批 Gemini 不认的关键字，这份名单里没有 discriminator。11报障人认为它显形于 v8.0.28 的「保留多分支 anyOf/oneOf 联合」那次改动：在那之前联合节点被整体替换，
discriminator 这类兄弟键顺带就没了。这一段是他的判断，本刊这次核到的是关键字名单本身。这条 issue 到发稿开着、没有对应 PR。5gemini API-key：
gemini-4-argon 不在目录里。 v8.0.29 上走 gemini API-key 通道请求这个模型，本地直接回 HTTP 400 unknown provider for model gemini/gemini-4-argon；同一把 key 直连 Google AI Studio 的 gemini-4-argon:generateContent 是 200。6本刊在 v8.0.29 的内置目录里核过：
internal/registry/models/models.json 里 gemini-4-argon 只出现在 vertex 段，antigravity 段叫 gemini-4-argon-high，而 gemini 段一共 13 个模型，里面没有它。7报障人给的绕法是显式登记，把从 Google
/v1beta/models 拉到的模型写进 api-keys.gemini[].models。他做完之后 Gemini 目录从 13 个涨到 34 个，原生接口、countTokens、generateContent、SSE、Chat Completions、Responses 全部回到 200。这条到发稿也开着、没有对应 PR。6两处静默失真的地方
Responses 到 Claude 的
status 在翻译里丢了。 POST /v1/responses 的输入里带 function_call_output 并标了 "status": "incomplete" 时，翻译出来的 Claude tool_result 只剩 tool_use_id 和 content，没有 is_error。整条链路没有任何报错，只是送上去的 payload 少了一个字段。13本刊在 v8.0.29 核了这一处：
internal/translator/claude/openai/responses/claude_openai-responses_request.go 第 523 行那个分支从 item 里取 output 和 call id，整个文件里没有一处读 Responses 侧的 status 字段，is_error 只在「工具调用被中断」那条兜底文案里出现过一次（第 1158 行）。14报告人用的是本地 mock 上游，只抓翻译后的请求体，所以这条能确认的是字段确实丢了，本地没有真实模型调用。这条到发稿 0 条评论。13
/v1/models 把应用版本当成 Codex CLI 版本比。 EasyCLIProxyAPI 面板请求 /v1/models?client_version=0.3.37 时，服务端拿 0.3.37 去和 Codex CLI 的门槛 0.144.0 比，判定为旧客户端，于是剥掉 max、ultra 两个扩展推理档，也跳过 cpa_capabilities；另外 client_version 传空值时不会回退到从 User-Agent 里取版本。15v8.0.29 里这段在
internal/client/codex/models/models.go。supportsExtendedReasoningLevels 从第 898 行开始，只有版本能解析成数字、并且小于 0.144.0 时才返回 false；版本为空或者解析不出数字时它返回 true，保留新特性。所以触发条件是「客户端报出去的是个数字形式的应用版本号」。16修复 PR #6638 把
EasyCLIProxyAPI/* 归一成 cpa，并在 client_version 为空时从 User-Agent 推断版本（认得 codex_cli_rs/、codex_exec/、Codex Desktop/、codex/ 四种前缀）。它 base 是 dev，动 5 个文件、+87/−2，到发稿开着、未合并。17sub2api：三条并发性能改动都在待合并，Composite 路由还不能按优先级切模型
- #8101：给
Content-Encoding: zstd的请求体加一条快速路径。请求体恰好是一个完整帧、帧头声明了原始大小（且不超过 64 MiB、不超过压缩体的 32 倍）时，一次性解码到定长缓冲区；其余情况退回原来的流式解码，截断、上限与报错行为不变。18 - #8099：Codex 重放历史时几乎每个请求都会走 item ID 清洗分支，原实现对每个要改的项各复制一次。改动后第一遍只判定、不分配，需要改时第二遍一次写出，身份改写也改成一次拼接。19
- #8098：请求视图里取出的
Model、PromptCacheKey等字段是请求体的子串，请求体被改写之后，这几个短字符串还拖着旧版本不放。改动是给它们做strings.Clone。20
这三条动的是内存占用与分配次数，请求的结果不受影响。用不用得上取决于你的实例在途请求多不多、请求体大不大——作者给的场景是 Codex CLI 经 OpenAI OAuth 账号透传、带图片时平均请求体 2 到 4 MB。19
另有一条不是性能问题：Composite 分组里，同一个公开模型配不了多条不同优先级的上游模型，配第二条时报「保存 Composite 路由失败」。想要「某个模型到容量上限就自动切到别的模型」，眼下做不到；报障人自己判断要先做出账号内具体模型的可用性状态记录。这条到发稿开着、0 回复。21
上几期按未证实传闻登记的「月底 GPT 200 档额度降到 10x」，窗口内收到了一条回复：计费逻辑和账户额度没有关系，额度按百分比看，100% 就是用完。22 写这条回复的是一位社区用户，那则传闻到发稿仍然只是传闻。
codex-proxy：本地后端被代理拦下，有了一个待合并的修法
v2.1.17 的
src/proxy/fetch-dispatcher.ts 是这样取代理的：先看配置里的 tls.proxy_url，再看环境里的 HTTPS_PROXY，有就把 new ProxyAgent(proxyUrl) 缓存起来，交给每个请求的 withFetchDispatcher。23PR #873 换成 Undici 的
EnvHttpProxyAgent，并把默认的 NO_PROXY 设成 localhost,127.0.0.1,::1，再与环境变量里的 NO_PROXY 合并。此前配了外部代理的实例，指向本地后端（比如 Ollama）的请求也会被代理接走，代理拒绝回环流量时整个请求就失败。24这条 PR 还加了按 API Key 的代理路由：
ApiKeyEntry 多一个 proxyId 字段，新增 PATCH /auth/api-keys/:id/proxy 接口，取值里 direct 表示直连、global 表示走全局代理、auto 表示轮询代理池，也可以直接填某个代理节点的 UUID；管理面板的「新增密钥」表单和每行密钥都会多一个代理选择框。24它 base 是
dev，动 23 个文件、+556/−76，到发稿开着、0 条评论。版本与上游：这一窗口没有版本可升
四个仓库的版本都停在原处：CLIProxyAPI 是 10 月 14 日的 v8.0.29，25 sub2api 是 10 月 13 日的 v0.2.16，26 codex-proxy 是 10 月 14 日的 v2.1.17，27 codex2api 是 10 月 12 日的 v3.1.0。28 其中 codex2api 这一窗口里没有任何 issue 或 PR 更新。
Anthropic 状态页这一窗口各组件正常、0 条事件。29 Google Cloud 的事件源里最近一条仍是 10 月 8 日开始、10 月 9 日结束的 Cloud Storage 上传与写入延迟，窗口内 0 条新事件。30
OpenAI 状态页这一窗口有一条仍在进行中的次要事件：Compliance/Costs API 的成本数据延迟，官方写明不影响 API 与 ChatGPT 使用。31 上一次牵连到 Codex 的降级是「Codex 与 ChatGPT Work 性能下降」，发生在 10 月 14 日 15:05 到 17:53（北京），在本窗口之前，已经恢复。31
Codex 的重置记录没有变化：最近一次已验证的全局重置在 10 月 13 日 13:03（北京），距离发稿约 47 小时；当天到发稿没有新的重置，也没有新预告。32
社区侧这一窗口有了内容。r/GeminiAI 上，有人贴出同一个 high 档提示词的额度消耗从 5 小时周期的 5% 涨到 16%，33另一人写平时一百多条提示用不到 10%，当天二十来条就把 5 小时额度跑完。34还有一条拿到 49 赞的帖子在讨论 Argon 的层级，35它引的 Google 官方支持页上，Argon 与 Pro 是两个并列的模型，Google AI Pro 与 Google AI Ultra 可用，Google AI Plus 与无套餐不可用。36
Claude 侧有一条：作者写自己「周中没有任何提示就被封顶」，于是做了一个把 5 小时与周额度显示在输入框上方、并在照当前速度会提前用完时变红的 Claude Code 插件。37
OpenAI 侧有一条：ChatGPT Plus 桌面端的用户反复收到「Too many requests」，他自己的用量一小时不到十条提示词。38
这几条都是用户自述，量级没有第三方核对过。linux.do 原站这一窗口仍返回 403，它的晚报镜像最新一期还是 10 月 14 日的第 006 期，窗口内没有出新一期。39
References
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22月底 gpt 200 版本的额度降低到10x · Issue #8070
github.com
- 23src/proxy/fetch-dispatcher.ts at v2.1.17
github.com
- 24
- 25CLIProxyAPI v8.0.29 · Releases
github.com
- 26Sub2API v0.2.16 · Releases
github.com
- 27codex-proxy v2.1.17 · Releases
github.com
- 28codex2api v3.1.0 · Releases
github.com
- 29Claude Status
status.anthropic.com
- 30Google Cloud Service Health
status.cloud.google.com
- 31OpenAI Status
status.openai.com
- 32Codex Reset — Last Reset Tracker
codex-reset.com
- 33
- 34Gemini App limit? · r/GeminiAI
reddit.com
- 35Argon is not a Pro model · r/GeminiAI
reddit.com
- 36About Gemini models · Gemini Apps Help
support.google.com
- 37
- 38
- 39第 006 期 · 2026-10-14 · linux.do 晚报
linuxdo.club
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.