10/16 深夜速报：Claude 的伪装日期修复已进 dev、默认保留 7 天，发行版上仍只钉 1 小时；Devin 周额度耗尽只退避 8 秒
10 月 16 日北京 22:04 到 23:12 这 68 分钟里四个仓库都没发新版本：Claude 伪装日期的修复进了 CLIProxyAPI 的 dev、新配置默认把日期保留 7 天，而发行版上仍只钉 1 小时；同一窗口里 Devin 周额度耗尽后本地只退了 8 秒，已耗尽的凭证被反复选中。
北京 22:04（上一期刊出时刻）到 23:12 这 68 分钟里，四个仓库都没有发出新版本。
四个仓库的主干在本窗口也没有新提交。唯一落地的新代码在 CLIProxyAPI 的 dev 分支上：一笔提交，给 Claude 伪装用的日期钉住加了保留期。
今晚要当场拿定主意的是两件事。一件是这一版上偶发的大额缓存写入要不要当成故障去查——修它的提交已经进了 dev，四个发行版都不含。
另一件是号池里有没有 Devin 凭证必须现在停掉：周额度耗尽之后，本地只退了 8 秒就又把同一条凭证选了出去。
一、Claude 的日期钉住修复已进 dev：默认保留 7 天，发行版上仍只钉 1 小时
上一期报过报障 #6682：CLIProxyAPI 把 Claude 请求的伪装日期钉在会话上，这个钉住活在一小时 TTL 的 continuity 条目里。空闲超过一小时又跨过本地午夜之后，下一条请求会按当天日期重新钉一次，
messages[0] 的文本随之改变5。本窗口的新进展是这条报障的修复落地了。
CLIProxyAPI 的 dev 分支在北京 22:53 收进提交
7604d3df，把日期钉住从 continuity 条目里搬出来单独存6。提交说明写着三件事：加一个
session-date-pin-days 配置项、默认保留 7 天；把会话日期钉住独立于 continuity 状态存储，免得凭证切换或空闲间隔把它重新钉一次；再把调用方自己写在首条 user 消息里的当前日期提醒剥掉。末行是 Closes: #66826。这次改动横跨 12 个文件，+581/−266。
最要紧的是存储键。dev 上的
ClaudeSessionDatePinKey 只对 session ID 做一次 SHA-256，注释写明它是 credential-independent store key7。同一条会话换到另一张凭证上，仍然读得到同一份日期，不会因此重新钉一次。对照 v8.0.31，钉住还存在 continuity 条目里，键是
sha256(credential identity, session ID)，凭证一换键就换8。
internal/runtime/executor/helps/claude_diagnostics.go 第 121–167 行：第 124 行的 claudeSessionDatePin 与第 132 行的 datePins 是这次新加的那份独立存储，第 138–147 行的键只由 session ID 算出，第 151 行的 LookupClaudeSessionDatePin 按配置的保留期读回日期7配置项本身在
config.example.yaml 的 upstream.claude 段下，值是 session-date-pin-days: 7，注释写明默认 7，显式写 0 才退回旧的 continuity 作用域钉子（1 小时寿命）9。发行版里没有这笔改动。本刊在 v8.0.31 的
internal/config/config_types.go 里搜不到 session-date-pin-days，也搜不到 SessionDatePinDays11；主干上同名文件的 claudeDiagnosticsTTL 也仍是 1 小时12。所以 v8.0.31 上这条问题照旧。
今晚能做的有三件：把偶发的大额
cache_creation_input_tokens 认出来，不要当成上游故障去查；升到含这笔提交的版本之后不要写 session-date-pin-days: 0，写了就退回旧行为；把会话固定在一条凭证上的做法在这笔提交之后不再必要，在此之前也没有坏处。二、Devin 周额度耗尽，本地只退避 1/2/4/8 秒，凭证被反复选中
第二条报障 #6690 在北京 22:37 开出，open、0 评论、无标签，作者 Ivan0514Xu13。
环境是 v8.0.31、官方 Docker 镜像、流式请求，冷却开着（
disable-cooling: false）13。上游明确返回
failed_precondition: Your weekly usage quota has been exhausted.，代理把它归成 HTTP 429，却只对单个模型做指数退避，没有把整条凭证封到周额度重置13。报障人给的时刻表（北京时间，10 月 16 日）：15:37:09 起四次失败，冷却时长依次 1 秒、2 秒、4 秒、约 8 秒，都记在
devin/claude-opus-5-5 上13。冷却过期之后，同一条凭证又被选中给
devin/claude-haiku-5-5，17:47:23、17:47:25、17:47:30 三次全部同样失败13。人工停用这条凭证之前，累计 21 次调用报周额度耗尽13。
为什么没被封住，源码里能核到两处。第一处是错误怎么归类：v8.0.31 的
ParseDevinTrailerError 按错误码字符串分支，failed_precondition 且消息里含 quota / credit / acu / exhausted / limit 之一时返回 429，其余情况返回 40014。返回的是一个通用状态错误，没有带凭证级作用域。
internal/runtime/executor/helps/devin_wire.go 第 1008–1028 行：第 1016 行起是 failed_precondition 的分支，错误消息里出现 quota、credit、acu、exhausted、limit 中任意一个才归 429，其余归 400；归类到此为止，返回的是通用状态错误14第二处是这个作用域决定冷却范围。写冷却的代码给模型级状态记的是
Reason: "quota"，只有日志结果带 CredentialScope 时才把整条凭证标成 credential_quota，并把同一条凭证上的其它模型一起连坐15。选号时只认后一个：
isAuthBlockedForModel 里整条凭证的拦截条件是 auth.Quota.Exceeded && auth.Quota.Reason == "credential_quota"16。报障人写的期望是：上游明确报出账号级日或周额度耗尽时，对整条凭证跨模型冷却；有可用的额度重置时间戳就按它算；临时限流与容量错误仍走短退避；刷新后的上游状态确认恢复时可以提前放行13。
这条仍开着，没有修复 PR。本刊 10 月 15 日那期报过凭证级冷却写得太死的一例；这里的情形是错误压根没升到凭证级，冷却停在模型上。
今晚的处置：Devin 凭证一旦报出周额度耗尽，人工停用，别等冷却。这也解释了为什么号池里同一条凭证会在短时间里连着报同一句话。
三、Codex CLI 打到 Gemini 上会连撞两处：8192 的输出上限与一条被丢掉的压缩触发
sub2api PR #8164 在北京 22:52 开出，open、非 draft、
mergeable_state 为 unstable，13 个文件 +1246/−34，base 是 main，0 评论17。它修的是把 Codex CLI 的
/v1/responses 流量路由到 Antigravity / Gemini 模型（gemini-4-argon-*、gemini-3.8-flash-*）时的失败17。报障现象是两行：
Incomplete response returned, reason: max_output_tokens，以及 Error running remote compact task；上游诊断日志里是 HTTP 400 与 Requests ending with a model turn are not supported.17。第一处根因在输出上限。Codex 省略
max_output_tokens 时，ResponsesToAnthropicRequest 给 max_tokens 填的是 819218，convertClaudeGenerationConfig 又把它原样转成 generationConfig.maxOutputTokens19。Gemini 的推理模型把
thoughtsTokenCount 和可见输出放在同一个 maxOutputTokens 里，长思考轮次于是撞上 finishReason = MAX_TOKENS，Codex 随即发起远端压缩17。同一处还有第二个缺口：
newConfiguredCodexModelDescriptor 没有 gemini-* 分支，缺上游元数据快照时回落到 272,000 的默认上下文，而 Gemini 是 1,048,57620。第二处根因在压缩。Codex 的远端压缩 v2 发
POST /v1/responses（stream: true），历史以最后一条 assistant 消息结尾，后面跟一个 {"type": "compaction_trigger"}17。这张 PR 的改法有三块：省略
max_output_tokens 时用 64,000 的上限，显式值超过 64,000 也压到 64,000；给 gemini-* 设 1,048,576 的上下文与并行工具调用；识别压缩请求，把 compaction_trigger 换成一个总结用的 user 提示，再把摘要用 AES-256-GCM 封装成 type: "compaction" 的输出项发回，后续轮次自动解密还原17。它还没有合并。今晚的处置落在读者这边：把 Codex 打到 Gemini 的通道显式给出
max_output_tokens，别让它落到 8192 的兜底上；看到上面两行报错里的任意一行，先查输出上限，再查压缩。四、同一窗口里的短条目
CLIProxyAPI issue #6685 在北京 22:56 以 closed / not planned 关闭22。
维护者 luispater 在同一条上回答：
claude_device_profile.go 第 23 行现在是 claude-cli/2.1.280 (external, cli)，cc_version 由这个基线派生，2.1.63 只在测试夹具里22。他还补了一层上一期没有的材料：这个指纹是一整套按 2.1.280 量过的捆绑，包括 User-Agent、
@anthropic-ai/sdk 0.112.1、运行时 v26.3.0、beta 头与 helper 的请求形状；只把版本号改成 2.1.296 会得到一套自相矛盾的指纹，比一套自洽的旧指纹更容易被拒22。上一期登记的形态是本刊复核后认为该声称不成立；本期它被正式关掉，可以放下了。
CLIProxyAPI issue #6689 在北京 22:36 开出，open、0 评论23。
它要把静态的 Python 写文件提升成 Codex
apply_patch 的 Add File 段：现在的解析器认得 cat 与 tee 的 heredoc 和 fs.writeFile，python3 -c 与 python <<EOF 不认，用 write_text、write_bytes、open(..., "w").write() 写文件的模型调用会被当成 exec 原样转发给客户端23。这条是待办提案。sub2api issue #8163 在北京 22:27 开出，open、0 评论24。
它请求在 Composite 路由上给
target_platform=openai 与 target_platform=anthropic 加一个「允许兼容账号」开关，理由是现在选号做的是硬等值过滤，而 useMixed 这条混合调度只对 Antigravity 生效25。这条是功能请求，没有处置。sub2api PR #7704 在窗口内被更新，没有新评论26。
codex-proxy 与 codex2api 窗口内 0 条条目更新；codex-proxy 的预发布版仍没有占上
latest4。五、上游与额度侧
OpenAI 状态页本轮是全绿：All Systems Operational、活动事件 0 条27。
最近一条有记录的仍是 10 月 14 日那条 Compliance API 成本数据延迟，它已在 10 月 16 日 18:44 转正27。
Anthropic 状态页是 All Systems Operational，10 月 16 日一栏仍写着 No incidents reported today28。
Google Cloud 的事件列表仍是 7 条，最近一条仍是 10 月 8 日到 9 日的 Cloud Storage29。
Codex 重置追踪站上，今天（UTC）没有重置。最近一次已验证的全局重置在 33 小时前，即 10 月 15 日 06:13 UTC、北京 14:1330。
累计是 54 次全局、10 次 banked，节奏约每 4 天；counted 口径 24 小时 50%、48 小时 75%，公告区仍写着没有官方信号30。
另一个追踪站记最近一次为 10 月 15 日 04:55 UTC，自 2025 年 9 月以来 62 次，中位间隔 3.1 天，最长等了 68 天31。
官方开发者社区 Codex 分区窗口内新增一条，北京 23:09 发出，标题是「Sudden extreme reduction in remaining usage」，发帖人写自己当天还没用过、剩余额度就只剩 4%，取的是小时口径而不是周口径，并问有没有按会话、任务、自动化拆开的用量视图32。单条未验证，登记不展开。
Reddit 三个板块窗口内与额度沾边的只有 r/GeminiAI 一条问询，北京 22:25 发出，问 Google AI Plus 档的图片额度33；按收录口径不收。r/OpenAI 与 r/ClaudeAI 窗口内没有额度或风控条目。
六、未闭合项（下期继续跟，不作结论）
- CLIProxyAPI：本窗口登记 #6690、#6689，关闭 #6685，dev 收进
7604d3df；继续跟这笔提交什么时候切出发行版、#6690 有没有人接、#6689 有没有 PR，以及 #6682、#6687、#6688、#6686、#6681、#6683、#6679、#6680、#6676、#6677、#6515、#6675、#6605、#6669、#6670、#6661、#6667、#6659、#6671、#6673、#6625、#6603、#6500 - sub2api：本窗口登记 #8164、#8163，#7704 更新；继续跟 #8164 会不会合并，以及 #8161、#8160、#8157、#8158、#8159、#8155、#8151、#8139、#8135、#8136、#8142、#8143、#8146、#8147、#8127、#8125、#8123、#7962、#7398
- codex-proxy：本窗口 0 条；继续跟 v2.1.18 正式版会不会打上
latest - codex2api：本窗口 0 条；继续跟 #793
下期优先回看三条：
7604d3df 什么时候进发行版；#6690 有没有人接；#8164 会不会合并。References
- 1sub2api Releases
github.com
- 2CLIProxyAPI Releases
github.com
- 3codex2api Releases
github.com
- 4codex-proxy Releases
github.com
- 5CLIProxyAPI #6682
github.com
- 6提交 7604d3df
github.com
- 7claude_diagnostics.go（dev）第 118–170 行
github.com
- 8
- 9config.example.yaml（dev）
github.com
- 10config_types.go（dev）第 124–143 行
github.com
- 11config_types.go（v8.0.31）
github.com
- 12claude_diagnostics.go（main）
github.com
- 13CLIProxyAPI #6690
github.com
- 14devin_wire.go 第 972–1020 行
github.com
- 15conductor_cooldown.go 第 960–1020 行
github.com
- 16selector.go 第 820–845 行
github.com
- 17sub2api #8164
github.com
- 18
- 19
- 20
- 21
- 22CLIProxyAPI #6685
github.com
- 23CLIProxyAPI #6689
github.com
- 24sub2api #8163
github.com
- 25gateway_scheduling.go 第 1136 行
github.com
- 26sub2api #7704
github.com
- 27OpenAI Status
status.openai.com
- 28Claude Status
status.anthropic.com
- 29Google Cloud Status
status.cloud.google.com
- 30codex-reset.com
codex-reset.com
- 31opentherank
opentherank.com
- 32社区帖 1406982
community.openai.com
- 33r/GeminiAI 1x7hnu8
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.