同一个文件名换上新号，旧号的冷却跟了进来——维护者说这是用法问题
CLIProxyAPI 维护者把「改写凭证文件会继承旧运行态」判成用法问题、明确不修；本期给出会继承的六类状态与正确的换号顺序，并核清 sub2api 会话内切模型被 429 的三处缺口。
北京 16:55，CLIProxyAPI 的维护者关掉了一张开了四小时的报告，理由是「用法问题」。
被关掉的是 #6908：同一个凭证文件被原地改成另一个号之后，新号会继承旧号的冷却与报错。修复提案 #6853 还开着，但维护者已明确不动这块。
所以：如果你换号的方式是覆盖同一个文件名，那个号现在正带着上一个号的状态在跑。这一条在你手上的 v8.0.40 里就成立。
同一小时还有一条同类型的。sub2api 上有人报告：在同一个会话里从 gpt-5.6-sol 切到 gemini，账号被 Google 429 并进了冷却。
旧会话里的身份，跟着请求走了出去。
两件事方向相反，起因一样：东西换了，跟着它的那份旧状态没换。
一、维护者把这张单判成了用法问题
读一眼 v8.0.40 的那段就能认出来。
isFileSnapshot 分支里，下面这些字段被无条件从旧对象搬到新对象：- 状态类：
Status、StatusMessage、Unavailable、NextRetryAfter、LastError。 - 额度类：
Quota的ObservedAt与Signals。 - 模型与序号：
ModelStates、cooldownRecordedSeq。3
问题在于，这段只认「这是同一个凭证 ID 的文件快照」，不认「这还是不是同一个凭证」。凭证 ID 由相对路径派生，文件名不变，ID 就不变。
isFileSnapshot 分支：第 399–400 行无条件搬 Unavailable 与 NextRetryAfter，第 405–407 行连额度快照与观测时刻一起搬。(CLIProxyAPI v8.0.40 conductor_lifecycle.go)按报障人逐类测出来的清单，六种改法都会把旧状态带过去：
- 换 provider（一个带 429 冷却的 claude 文件被改读成 codex）：冷却与额度原样留下。
- 同 provider 换新 token（非 401 的刷新失败后重登）：瞬时刷新失败留下，
credential_quota冷却留到恢复时刻。 - Codex 换
account_id但 OAuth token 不变：失败留下，而且CredentialsChanged看不见这次变化。 - Vertex 换服务账号或项目：失败留下；两个不同的畸形服务账号还会被判成相等。
- 插件凭证身份只存在
StorageJSON里：storage 轮换后失败留下。只差一个大于 2^53 的 64 位数的两份 storage，会被判成相等。 - 旧账号被拒过的
RejectedAccessToken：token 字符串一样，就由新账号继承。
还有一类更隐蔽：旧号发出去的请求迟到返回。
CredentialVersion 在同 token 换号时不会前进。isStaleExecutionResult 又只比对 access token，对得上就收。于是一个换号前发出的 401 迟到落地，会把新号标成不可用。换 provider 时，旧 provider 的迟到 429 会落到新 provider 头上。
报障人在
dev 的 d946c4fb 上用 go test -race 跑了 #6853 里的 18 个用例，14 个失败。他也写明了没验证的部分：生产环境多久遇上一次、Linux 与 Docker、全量套件都没跑。
维护者的答复很干脆：
Because the credential lifecycle is file-based, each credential file is expected to maintain a stable user identity and state … If you need to reuse the same credential filename, please delete the existing credential file and any associated state files first before creating the new one. This is considered a usage issue and there are currently no plans to address it.
这条答复发出两秒后，单据就被关成 not planned。
翻成运维动作就三步。
- 不要原地覆盖同一路径来换号。
- 要复用文件名，先删凭证文件，再删它的关联状态文件。
- 做不到就换个文件名或换个子目录，ID 跟着路径走。
「关联状态文件」在这一版里具体是
.cds。它按 auth 文件的相对路径生成，同名换扩展名。4只有开启
routing.cooldown.save-cooldown-status 才写盘，默认 false 时冷却只在内存里。5也就是说，只删
.cds 不够。内存里的
Unavailable、NextRetryAfter 与额度快照，照样会在下一次文件事件里被搬过去。删凭证文件本身，才会让这条 ID 退出运行时状态。二、旧会话的身份，跟着请求走进了 Gemini
sub2api 上 16:44 开了一张单。
触发条件很简单：在同一个会话里，把模型从 gpt-5.6-sol 换成 gemini-4-argon-medium，账号就直接 429、进冷却。6
报告把原因指向一处：请求里的
instructions / system 还留着上一轮的身份句。原句是
You are Codex, a coding agent based on GPT-5。历史消息的格式问题已经被兼容层洗掉了，身份句没洗。
我在 v0.2.18 的整包里核了三处，都对得上。
第一处，
codexGPTIdentityPatterns 存在，正则也写对了，但它只服务 /models 下发的模板，不在转发路径上。更要紧的是它旁边那段注释。
项目自己写着：Antigravity 后端遇到带「GPT-5」身份的 Codex 提示词，会回
429 RESOURCE_EXHAUSTED，并把账号带进限流冷却。7
codexInstructionsTemplateForModel 只在下发模型清单时套这两个正则。(sub2api v0.2.18 openai_codex_models_service.go)第二处，走
claude-* 的 buildSystemInstruction 只做了 Claude 身份的清洗。第 352 行与第 368 行都是
neutralizeClaudeIdentity(stripClaudeAttribution(...))。两处都只洗 Claude，没碰 GPT 身份。8第三处，走
gemini-* 的分支连 Claude 身份都不洗。buildAntigravityCompatGeminiBody 先调 convertClaudeMessagesToGeminiGenerateContent。之后紧跟的
injectIdentityPatchToGeminiRequest 只往开头插一段 Antigravity 身份。遇到已有身份它就整段返回，从不删除任何东西。11
第 271 行判定
gemini-*，第 272 行转换、第 281 行才补身份：这一段调用顺序里没有「洗掉上一轮身份」这一步。(sub2api v0.2.18 antigravity_gateway_compat.go)冷却多久，报障人写的是 60 秒，代码里的兜底是 30 秒。
antigravityDefaultRateLimitDuration 就是 30 秒。它能被上游返回的 retryDelay 顶高，也能被
gateway.antigravity_fallback_cooldown_minutes 与环境变量覆盖。12429 先落模型级：解析出最终模型名就只停这个模型，解析不到才退回账号级。所以你看到「整个账号红了」和「只是这个模型红了」，是两种不同结果。
现在能做的有两件。
一是让用户开新会话，或让客户端重新拉一次
/models 拿到干净的 instructions。这条能立刻止血，但治不了客户端缓存。二是按上面三处补清洗，把 GPT 身份正则也接到转发路径上。
需要说清的是，这张单的正文像是 AI 助手代写的排查稿，末尾还在问「需要我现在把这个修复加上吗」。
三处缺口与那段注释我逐条核过，是真的。「他这次就是被这个触发的」这一句，得用你自己的日志确认。
三、四张单：要改的配置在被谁改
四仓这一小时都没有新版本：CLIProxyAPI 还是 v8.0.40，sub2api 还是 v0.2.18，codex-proxy 与 codex2api 连条目都没动。
变化全在 CLIProxyAPI：开了四张单、关了一张，dev 上还落了 compat 区的两笔修复。
#6916 额度快照改用响应接收时刻。 现在的快照用的是请求完成时刻。并发请求乱序完成时，先发出、后收到的旧读数会盖掉新读数，利用率与观测时间一起失真。13
修法是把接收时刻与响应头一起原子读出来，遇到更旧的观测就丢掉。
对照现行代码能看出缺口在哪。
requestmeta 里的响应头容器只存了头，没有时间。要动什么：不用改配置。要看的是面板上那个利用率——长请求多、并发高的站，把它当参考值，别当准绳。
#6918 用量天花板。 新增
routing.usage-ceiling：weekly-percent 默认 80，short-window-percent 默认 90。凭证里写 usage_ceiling 可以逐项覆盖，填 0 关闭。16超过且未到重置时刻，就在本地记一条凭证级 429，
Retry-After 直接写恢复时间，请求不发上游。全池都被顶住时，客户端拿到的是 429。它读的正是 #6916 要修的那份被动快照。两份一起上才准；只上这一份，遇到乱序完成会提前把号摘下来。
字段名像秘密（token、secret、password、api key 之类）才封，用 AES-256-GCM。
字段名当附加数据，所以值挪到别的字段就打不开。
三个行为要记住：
- 关掉开关不会把密文写回明文，那些号会一直跳过到重新登录。
- 存在加密文件却缺密钥，启动直接停。
- 与 Postgres、对象存储、git 存储不能同时开。
容器没有 keyring，只能用环境变量或密钥文件。这张单现在
mergeable_state 是 dirty，需要先 rebase。#6920 模型清单补 token 上限。 就是 10-23 上午 #6914 那个坑：Home 模式下
/v1beta/models 少了 inputTokenLimit 与 outputTokenLimit。18它让 standalone 模式回落到
ContextLength，Home 模式把解码后的两个值序列化出去。取不到就省略，不编默认值。#6917 Decisions API 的 OAuth 权限问询，16:25 开，到发稿没有回复。19
它问的是 Codex OAuth 凭证能不能调
POST /v1/decisions，并要求把「路由没实现」与「OAuth 无权限」分开报。#6860 关了但没合。 「容量换号前先把 metadata 缓冲下来」，2 个文件 +65/−2，16:16 关成未合并。20
dev 上还有两笔值得记。
这两条正好补上一处判断。#6897 与 #6898 的外部补丁被翻译层路径守卫挡在门外，但守卫只拦外部 PR。
同一个洞，维护者自己十分钟就落了两笔——它们现在只在 dev，v8.0.40 里没有。
四、上游读数本身也在漂
三家状态页这一小时都安静。
OpenAI 全组件 operational。最近一条事件是「客户支持响应延迟」，03:41 到 05:58（北京 11:41 到 13:58）已恢复。23
额度侧两站的读数还是各记各的。
codex-reset 记「今日 UTC 尚未重置」。最近一次已验证全局重置是 16 小时前，即北京 10-23 01:10。
累计 57 次、银行存着 10 次，节奏约每两天一次。26
opentherank 记 65 次、中位间隔 3 天、最长 68 天。27
codex-reset 的雷达还挂着一条四小时前的承诺。Tibo 说重置在 10-23 10AM PT 之前，也就是北京 10-24 01:00。
这条上一期就写过，现在只剩执行与否。
Google 自己的两个官方分区，这一小时没有与额度相关的新帖。今天早些时候有三条本刊此前没覆盖，补在这里，时间都标清楚。
- 09:50（北京），一位付费 Ultra 用户：Gemini 与 Claude/GPT 两组周额度同时掉到 0%。模型选择器里的 5 小时额度却还显示 100% 与 98%。28
- 12:02，另一位 Ultra 用户：账号被判
ineligible for higher limits、卡在 Starter Quota。换第二台机器重装依旧。29 - 09:50，一位 Pro 用户引用 Google FAQ：把 agy 包进第三方 agent 或应用，在消费级计划不受支持，官方建议改用 API key。30
对中转站来说，前两条是上游账本自己在漂。你面板上的 auto-pause 与用量天花板，都建在这份读数上。
第三条是政策底座，不是技术问题：消费级订阅转给第三方 agent 用，官方的立场写在不支持那一栏。
今天可以先做的三件事
第一，翻一遍换号记录。凡是覆盖同一个文件名的，删掉凭证文件重新建，别只删
.cds。第二，遇到「同一会话里切模型就 429」的报障，先让他开新会话止血，再决定要不要按那三处打补丁。
第三，等 #6918 与 #6916 一起进版，再开用量天花板。单开一份，读数不可靠时会把账号提前摘下来。
References
- 1CLIProxyAPI #6908：改写后的凭证文件会继承旧凭据的运行态
github.com
- 2
- 3
- 4v8.0.40 cooldown_state.go：每个凭证一个 .cds
github.com
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13CLIProxyAPI #6916
github.com
- 14v8.0.40 quota_signals.go 第 37–50 行
github.com
- 15
- 16CLIProxyAPI #6918
github.com
- 17CLIProxyAPI #6919
github.com
- 18CLIProxyAPI #6920
github.com
- 19CLIProxyAPI #6917
github.com
- 20CLIProxyAPI #6860
github.com
- 21
- 22
- 23OpenAI 状态页
status.openai.com
- 24Anthropic 状态页
status.anthropic.com
- 25Google Cloud 事件列表
status.cloud.google.com
- 26codex-reset
codex-reset.com
- 27opentherank
opentherank.com
- 28Antigravity 分区：Ultra 两组周额度同时归零
discuss.ai.google.dev
- 29Antigravity 分区：Ultra 有效却被判无更高限额资格
discuss.ai.google.dev
- 30Antigravity 分区：付费 Pro 用户希望允许第三方 agent 使用订阅
discuss.ai.google.dev
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.