重置落在北京时间明天凌晨；auth 目录读不到一次，全部文件凭据会退出轮转
Tibo 给出 Codex 重置的落地时间，同一小时 CLIProxyAPI 在六秒里连开六张单；本篇给出今晚要做的三件事、每条的源码位置，以及 sub2api 两条新单的判读。
北京时间 14:55，Tibo 在 X 上给了这一小时最有用的一个时间点：今天是重置日，重置在明天上午十点（太平洋时间）之前落地。
十一分钟之后，CLIProxyAPI 的 issue 列表里多了六张单，都开在 15:06:51 到 15:06:57 之间，作者是同一个人。
窗口从上一期发稿的 14:09 起，到发稿时约 70 分钟。四个仓库没有新版本，主干也没有新提交。
重置落在北京时间明天凌晨
两条帖相隔 32 秒。1
第一条原文是
Day 17/ Bet you thought we forgot, but no, it's reset day today.，后面顺带提醒去拿 Daybreak Blue 的访问权限。第二条只有一句：Lands tomorrow before 10am PST.2折算北京时间有两个坑。帖发在北京 14:55，太平洋当时还是 10 月 21 日 23:55，用的是夏令时（UTC−7）。
所以「明天上午十点」指太平洋 10 月 22 日 10 点，对应北京时间 10 月 23 日凌晨 1 点；按 PST 字面算（UTC−8）是凌晨 2 点。
今晚到明天凌晨这段时间，付费账号的上限会刷新一次。
追踪站还没记到这一次。页面写今日 UTC 尚未重置，最近一次已验证的全局重置仍是 10 月 20 日 06:33（北京 14:33），约两天前。3
同页记 56 次全局重置、10 次 banked，节奏约每两天一次。这条帖已经被它标成 strong signal。
重置是渐进落地的。 从帖出来到额度真的刷新，中间是十分钟到几小时；刷新后看 Settings → Usage 或 CLI 的
/status。本地冷却不会跟着上游一起消失。 被标成凭证级额度的凭证，在
NextRecoverAt 之前不进候选集。4一次成功回执也不会清掉这层冷却。5
banked reset 要自己领。 它不自动刷新任何窗口，要进 Settings → Usage 确认，每张都有自己的到期时间。
六张单里今晚该看的那张：目录读不到，全部文件凭据一起下线
#6870 的标题把话说完了：全量扫描读不到 auth 目录时，会把每一个文件凭据注销。7
源头在这一句。
os.ReadDir 失败时，合成器返回空切片加 nil error，注释写的是「目录不存在不算错误」。8
CLIProxyAPI v8.0.38
internal/watcher/synthesizer/file.go 第 33–43 行：os.ReadDir 失败走 return out, nil，返回值分不出「目录空了」与「目录读不到」。空切片到了下层就成了权威结论。全量扫描里没出现的 ID，直接派发删除。9
触发条件是 EACCES、EIO、EMFILE 这类目录级失败。全量扫描在每次配置重载时都会跑一遍。
也就是说，改一次配置，恰好那几秒目录不可读，就够让所有 OAuth 凭证一起退出轮转。挂载卷权限变化、fd 用满、I/O 错误都能造出这几秒。
今天能做的有三条：auth-dir 放本地盘，别放在会抖的挂载卷上；把
nofile 提上去；改完配置核一遍凭据列表有没有少。目录恢复可读之后，下一次扫描会把它们重新加载回来。#6806 修的是单文件读失败那条，目录级这条还开着。
SIWC 凭证被判不适格，网关当成请求的错
use_siwc 的 Codex 凭证，遇到上游回 403、error.code 是 subscription_sharing_user_not_eligible、type 是 invalid_request_error，会被判成请求本身的错。判成请求级的结果是：不换号，也不冷却，同一张凭证反复吃同一个 403。
判定在
IsRequestFault 里。模型不存在那条已经单独放行，10 第 109 行紧接着是通用的 hasRequestFaultBody，而 invalid_request_error 同时在码表和类型表里。
CLIProxyAPI v8.0.38
internal/clienterror/client_error.go 第 96–121 行：第 106 行只把 model_not_found 排除在请求级之外，第 109 行的通用判定里没有凭证级分支，SIWC 那两个码因此落进「请求的错」。PR #6866 加了一张凭证码表，把
subscription_sharing_user_not_eligible 与 subscription_sharing_invalid_user 划出去。11测试里留了一条反例：
subscription_sharing_unsupported_capability 仍算请求级，它确实是请求带了上游不支持的能力。这张 PR 14:31:50 开出，base dev，open，单笔提交，还没有评审。
今天看到 SIWC 凭证回这两个码，就手动停用或降权那张凭证。它不会自己换到下一张。
另外四条：区域主机名、搜索空结果、400 缺少错误码、两处竞争
us-central1 这类区域没问题，写 us 或 eu 的凭证会被打到不存在的主机上。把 location 改成具体区域或 global 即可。内置 web_search 与客户端工具同组时，搜索被一个空结果顶掉。 Claude 在同一并行组里既调 web_search 又调客户端工具，会先以
tool_use 停下，搜索还没跑。14下一轮再补一个
content: [] 的 web_search_tool_result，上游接受，搜索因此永不执行，模型按 0 结果回答。再下一轮，同一个 srvtoolu_ id 会带着两份结果出现。今天让内置 web_search 单独占一轮，别和客户端工具放进同一个并行组。
流已开始后上游回 400，错误里没有码。 打开 keepalive 之后 SSE 头已经发出，Claude 此时回 400
prompt is too long，代理只能发 response.failed，response.error 里没有 code。16Codex 只认
context_length_exceeded 才触发上下文压缩，未知码按可重试处理，于是它反复重试一个永远不会成功的请求。上一期写的 #6862 是另一条：那条是
stop_reason: model_context_window_exceeded 被翻错，这条是上游直接回 400。两处竞争。 #6871 是 OAuth 登录的 goroutine 不持
h.mu 读 h.cfg，与配置保存撞车；18 #6872 是 -race 下会挂的一个分配计数测试，同一处代码在不开竞态检测时稳定通过。19这两条今晚都不用动，知道 CI 会红就行。
sub2api：Grok 的结束标记被拼进正文，客户端还会原样回放
#8291 的现象很短：Grok 账号服务
/v1/messages 时，客户端存下的正文末尾会多出 </content>；同一会话再走几轮，还会带上 <div class="turn-content assistant"> 这种壳。20同一个账号走 Chat Completions 桥没有这个现象，所以问题出在 Anthropic 桥的拼法上。
原因在补尾巴的那段。只要
output_text.done 的文本以已发出的内容为前缀，框架就把多出来的部分当漏掉的文字再发一遍。21
sub2api v0.2.17
backend/internal/pkg/apicompat/responses_to_anthropic.go 第 461–482 行：第 478 行只判断是否为前缀，第 481 行把 text[len(delivered):] 当新文本发出去，Grok 的结束标记就是这样进正文的。伤害是累积的：客户端把带壳的正文存进历史，下一轮原样发回，壳再被复制一份，prompt 跟着变长。
今天同一账号改走 chat completions，或者清掉已有会话里的
</content> 与那层 div 壳。修复 PR #8292 在 14:29:45 开出，未合并。22账号并发度设成 1，仍然报并发上限
#8294 的报障很直接：账号只开了并发度 1，还是回
Concurrency limit exceeded for account, please retry later；报障人的推断是多个 codex 实例被识别成了多个。23这句话和这个码是本地出的，码名
gateway_concurrency_limit。24账号槽按账号 ID 计，每个请求生成一个 requestID，请求结束才释放。25
所以先查本地这一层：是不是还有别的请求占着这一格，或者上一个进程崩溃时没释放。
指纹收敛改的是另一层：发给上游的 installation_id、session_id、thread_id。26
sub2api v0.2.17
backend/internal/service/openai_codex_fingerprint.go 第 228–258 行：installation_id 与 session_id 是账号级常量，thread_id 按客户端 session 派生——收敛管的是上游看到几个实例，跟本地并发记账是两回事。而且它默认关着，只有账号 extra 里显式开启才生效。27
排查顺序：先看本地槽有没有漏，再确认该账号开了收敛没有。两件事不在一层，混着查会绕远。
顺带一条：#8293 想把 composite 路由的跨厂商 reasoning 重放隔离开，并给出显式的分组与账号目标，4 笔提交，未合并。28
四仓与上游：零新版本，两处降级还挂着
四个仓库窗口内都没有新版本：CLIProxyAPI v8.0.38、sub2api v0.2.17、codex-proxy v2.1.20-beta.0543eaa、codex2api v3.1.1；主干也没有新提交。codex-proxy 与 codex2api 窗口内 0 条。
OpenAI 仍是 Partial System Degradation，Responses 与 Conversations 都标降级；事件从北京 10:42 转 monitoring 之后没有新更新。29
Anthropic 的 Connectors 事件开在北京 11:50，状态 investigating，到发稿只有一条更新。30
Google Cloud 状态页首条还是 10 月 20 日 europe-west2 那条，当天已结束。31
今天能做的三件事
重置落地之后再解冷却。 上游刷新不清本地凭证级冷却；重置之后跑一次
routing/cooldown/reset，带上 auth_index。改配置前确认 auth 目录可读。 目录读不到一次，全部文件凭据会一起退出轮转。
SIWC 凭证回 403 就手动换。
subscription_sharing_user_not_eligible 现在不会自己轮换。References
- 1Tibo 的帖：今天是重置日
x.com
- 2Tibo 的跟帖：明天上午十点前落地
x.com
- 3codex-reset.com 首页
codex-reset.com
- 4CLIProxyAPI v8.0.38 selector.go 第 836 行
github.com
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23Codex 指纹收敛 应该是完全失效了~（sub2api issue 8294）
github.com
- 24
- 25
- 26
- 27
- 28
- 29
- 30Elevated errors affecting Connectors（status.claude.com）
status.claude.com
- 31Multiple Products 事件（Google Cloud 状态页）
status.cloud.google.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.