interactions 的用量账又被挑错；AI Studio 段里始终没有 Argon
interactions 的用量合并被一张单反向挑战、自动评审又把那张单打回，本期给出偏差算例与三步自查；另报 AI Studio 段的模型表里始终没有 Gemini 4 Argon，以及确认凭证类型的三步。
北京 02:47 到 05:12，两小时二十五分钟。四个仓库没有一个发新版，主干也没有一笔新提交。
窗口里动过的只有 CLIProxyAPI 的七条、sub2api 的两条，全都停在评审或关闭动作上。
值得今晚动手核的只有两件，都不在版本号上。
一件是 interactions 的用量账：上一期本刊说那张单不用等，这个判断要更正。另一件是 AI Studio 段的模型表里始终没有 Gemini 4 Argon，而报障单已经被关掉了。
一、用量账：三方各说一套，还没定
上一期的原话是「PR #6926 可以不用等了」，理由是它与维护者那笔 8289ec4c 重复。
它不是重复，是反对。
三方的主张并排放着看，差别很清楚：
- 发行版 v8.0.41：interactions 继续走合并。
- 补丁作者：interactions 发的是累计快照，合并不该发生，一行改成整份替换。
- 自动评审：整份替换会把早期分段里的输入与缓存清成 0，账更糟；该改的是合并逻辑本身。
评审的原话是「replaces the whole buffered detail」，说这样会让已发布的记录把更早的输入与缓存桶清成 0，并可能让归一化后的拆分不自洽。
只有这一条走合并
internal/runtime/executor/helps/plugin_executor_usage.go 第 64–84 行：第 68 行与第 80 行，gemini 与 antigravity 都是 buffer.Observe，整份覆盖；第 74 行，interactions 与 interactions-response 走 ObserveMergedStreamUsage，与旧值合并。3这一段决定了影响面。核心执行器、原生 Gemini 与 Vertex、Antigravity 都不走这段。
会走到的只有一种组合：插件执行器，加上 interactions 或 interactions-response 作为下游协议。
合并会把旧值搬回来
if 的意思是「新快照里这个桶是 0，就拿上一份的旧值补上」；第 203–205 行只把总量往上抬，从不往下调。4按这段推一遍就明白。
先来一份
input 100、cache_read 20、total 100；最后一份是 input 100、cache_read 0、output 30、reasoning 0、total 130，也就是上游把缓存与思考都澄清成 0。合并之后，cache_read 被补回 20、reasoning 被补回旧值，总量被判成 140。上游说 130，本地记 140。
补丁作者新加的四条用例里，第四条正是这一组。5
plugin_executor_usage_test.go 第 24–34 行：第 30 行那条 case 叫 authoritative zero buckets，初值 140、末值 130。前三条是完整快照正常合并的情形，与现实现一致。反过来那半边也成立：一次流如果被上游拆成两段（先给输入，后给输出且不带输入字段），合并是对的、整份替换是错的。P1 指的就是这一半。
影响面与三步自查
- 受影响的是插件执行器，加 interactions / interactions-response 下游协议。
- 动的是本地 usage 记录与计费明细；不动上游额度，也不参与封号与限流判定。
- v8.0.41 相对 v8.0.40 改的是「按快照自己的口径重算拆分」；回填旧值那七个
if，两版都在。6
自查三步：
- 挑一条 interactions 流式响应，把带
usage的行全留下，取最后一份完整快照。 - 与面板上这一条的
cache_read、reasoning、total三个字段比。 - 本地大于快照就是命中，按快照手改这一条，或整批按快照重算。
要不要等这张单：它 2 文件 +53/−1，mergeable clean，但 P1 没解、作者还没回。到发稿，主干与发行版都没动，今晚不会有版本把它改掉。
二、AI Studio 段里始终没有 Argon
#6728 是十月十七号开的，标题直白：Gemini 4 Argon unavailable through AI Studio。7
正文只有一句：Google 把 Argon 开给了 Pro 订阅，但 CLIProxyAPI 里这个模型不见了；以前只有付费 API 或 Ultra 时它是在的。
北京 10-24 04:46:59，这张单关了。关的人是报障人自己，没有维护者回复、没有关联提交、没有标签。
关单不等于修好。v8.0.41 随包的模型表与两份远端镜像都核过：
| 目录段 | 条数 | 含 gemini-4-argon | 对应哪类凭证 |
|---|---|---|---|
| aistudio | 15 | 否 | AI Studio 通道 |
| gemini | 14 | 是 | Gemini API key |
| vertex | 21 | 是 | Vertex |
| antigravity | 11 | 是（high 档） | Antigravity |
sdk/cliproxy/service_models.go 第 92–132 行：constant.Gemini 走 GetGeminiModels（第 93 行），"vertex" 走 Vertex 表（第 116 行），"aistudio" 走 GetAIStudioModels（第 129 行）。同一个模型名在不同凭证下能不能被列出来，由这里决定。10所以「AI Studio 用不了 Argon」只对一类凭证成立。
用 AI Studio API key（类型 gemini）的实例，模型表里是有
gemini-4-argon 的；列不出来的，是 aistudio 那类通道。还有一条常被忽略：模型目录每三小时从远端拉一次，某个模型进表不需要发版。11
三步：
- 先确认你在用哪类凭证，管理面
/v8/management/credentials看 provider 与 type。 - 要 Argon 就走 gemini 或 vertex；antigravity 那边是 high 档。
- 手上只有 aistudio 通道：这张单已经关了、表里也没有，别把它写进可售清单。
三、窗口里的其余动作
| 条目 | 时间（北京） | 现在的状态 | 要不要动 |
|---|---|---|---|
| #6928 Home 模式目录缺档位元数据 | 02:47 开 | open，0 评论 | 不用 |
| #6901 Codex 客户端识别快照（PR） | 04:28 更新 | open | 不用 |
| #6927 Z.ai OAuth（PR） | 02:43 开、02:49 关 | 未合并，28 文件 | 不用 |
| #6715 / #6893 | 未变 | open | 不用 |
| sub2api #4834 | 04:13 关 | 作者自关、未合并 | 不用 |
#6928 值得记一笔，因为它接着上一期那条。12
上一期报的 #6914 是 Home 模式的
/v1beta/models 缺 inputTokenLimit，v8.0.41 补上了；这张单说的是同一处目录还缺速度档位的元数据。具体表现：Home 模式下客户端列不出「这条路由支持哪一档速度」，翻译层认的 Claude Fast 因此没法被发现。开单的是 JustYannicc，与 #6926 的 BichengWang、#6925 的 Willxup 都不是同一人。
sub2api 那张 #4834 是七月提的架构清理，137 笔提交、744 个文件、+25265/−31260，全程只有 CLA 机器人的一条评论。15
北京 04:13:01 它由作者本人关闭、未合并。含义很具体：那批删代码不会落地，别把那批清理当成下个版本的预期。
四、四仓这一窗口
| 仓库 | 当前版本 | 发布（北京） | 本窗口 |
|---|---|---|---|
| CLIProxyAPI | v8.0.41 16 | 10-24 02:25 | 零新版本；两单关闭、两张 PR 未合 |
| sub2api | v0.2.18 17 | 10-23 15:44 | 零新版本；#4834 关闭未合 |
| codex-proxy | v2.1.20 18 | 10-23 03:56 | 零条目 |
| codex2api | v3.1.1 19 | 10-17 05:46 | 零条目 |
CLIProxyAPI 的
main 与 dev 都停在 18:18:56Z，也就是 v8.0.41 自己那笔。下一个版本还没开始。五、上游与社区：这一窗口没有新信号
三家状态页窗口内都没有新事件。
OpenAI 全绿，25 个组件都在 operational；最近一条还是 10-23 中午的客服响应延迟，北京 11:41 到 13:58，已恢复。20
Anthropic 全绿，最近一条是 10-22 的 Connectors 错误升高，北京 11:50 到 16:07。21
Google Cloud 八条，最近一条仍是 10-22 的 europe-west 故障，最后更新北京 10-23 00:19。22
Codex 重置这件事，这窗口有一条要说。
Tibo 在 10-23 12:47（北京）发帖：Landing tomorrow before 10am PST together with a small ship。23
发帖时他那边是太平洋时间 10-22 晚上九点四十七分，所以「明天上午十点」落在 10-23 17:00 UTC，也就是北京 10-24 01:00；按字面 PST 算是 02:00。
到发稿，这两个时点都已过去四小时以上。
追踪站上的读数没变：今天 UTC 还没有重置，最近一次已验证的全局重置是 10-22 17:10 UTC，约 28 小时前；累计 57 次、10 次 banked、节奏约每两天。24
它的 feed 里
newest_post_at 仍是 10-23 04:47:34Z，也就是上面那条，窗口内没有新帖。25上一期把截止算成 10-25，那是把「明天」挂在 UTC 的 10-23 上；按发帖人所在的太平洋时间，明天是 10-23。同措辞的上一次就是这样落地的：10-22 的承诺在 17:10Z 兑现，比 10am PT 晚十分钟。
opentherank 仍是 65 次、中位 3 天、最长 68 天，更新停在 10-23。26
社区侧没有额度风控类的新东西。OpenAI 开发者社区的 Codex 分区最新话题是北京 04:26 的「Unavailable chats by not being able to load this chat」，与额度无关。27
r/GeminiAI 窗口里有两条与额度相关。
一条是北京 02:53 的抱怨帖，说 TPU 越强、付费用户配额反而越低，155 分、39 条评论，没有可核的读数。28
另一条是 04:49 的单人自测：同一个画图提示，Flash 两档各用掉不超过 1%，Pro 用掉 4%、Argon 用掉 3%。29 一人一次、未复现，但当个方向可以。
六、还没闭合的
#6926 的 P1 谁来回：要么作者改，要么维护者把合并逻辑改成保留分段。
Argon 在 aistudio 段补不补；不补的话，这条通道该在文档里写死「不支持」。
下一版什么时候来：两个分支都还停在 v8.0.41 那笔提交上。
Codex 那条承诺已经过点而未见新的全局重置，下一句解释或下一次重置，是目前唯一能继续对账的东西。
References
- 1PR #6926
github.com
- 2那次评审的摘要
github.com
- 3同文件第 64–84 行
github.com
- 4同文件第 163–205 行
github.com
- 5补丁分支的测试用例
github.com
- 6v8.0.40 的同一段
github.com
- 7#6728
github.com
- 8v8.0.41 的 aistudio 段
github.com
- 9远端目录
raw.githubusercontent.com
- 10同文件第 92–132 行
github.com
- 11目录刷新周期
github.com
- 12#6928
github.com
- 13#6901
github.com
- 14#6927
github.com
- 15#4834
github.com
- 16v8.0.41
github.com
- 17Sub2API 0.2.18
github.com
- 18v2.1.20
github.com
- 19v3.1.1
github.com
- 20OpenAI 状态
status.openai.com
- 21Anthropic 状态
status.anthropic.com
- 22Google Cloud 状态
status.cloud.google.com
- 23那条帖
x.com
- 24codex-reset 首页
codex-reset.com
- 25codex-reset 的事件接口
codex-reset.com
- 26opentherank
opentherank.com
- 27Codex 分区
community.openai.com
- 28那条帖
reddit.com
- 29那条自测
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.