声明 Standard、出站 priority：那 2 倍价在哪一步产生；内置 Devin 目录仍缺 gpt-6-1-sol (2026)

这一轮四个仓库都没有新版本：CLIProxyAPI 停在 v8.0.40，sub2api 在 v0.2.18，codex-proxy 是 v2.1.20，codex2api 是 v3.1.11 2 3 4。两条主干也没动：CLIProxyAPI 的 dev 头停在北京 18:03，sub2api 的 main 停在 15:44。

窗口里落下的只有三条：一条「我配的是 Standard，账单按 Fast 走」的上游报障，一条仍缺着模型的本地目录，一条 429 而面板空白的 Gemini 报障。

前两条今天就能动手核，第三条只能当线索。

声明的是 Standard，出站写的是 priority

先给事实。北京 21:04，openai/codex 开出一张新单5：VS Code 里的 Codex 扩展、Windows、ChatGPT 登录。

报障人的配置里写死 service_tier = "default"，features.fast_mode = false。会话记录显示，美东 22 日 16:15:34 还是 default，16:19:23 就变成 priority。

后面几轮的提交日志里，出现 service_tier: Some(Some("priority"))。他说自己没点过 Fast，会话里也找不到 /fast 命令。

他自己先划了界线：这只证明交上去的是什么，没证明为什么。用量影响他也没量化。这张单到现在 0 条回复5。

这段描述值得抄进值班手册。档位在你这条链路上会被改写两三次，每一次都可能让账单变一档。

三处地方决定最后交出去哪一档

第一处是客户端提交的 body，第二处是你自己的策略，第三处是最终出站的那一份。

sub2api v0.2.18 里，第二处有两道闸6。分组开了 ForceOpenAIFast，策略评估之前就无条件把 service_tier 写成 priority。

另一道叫「缺失档位升级」：只有规则里选了 missing 匹配，没写档位的请求才会被升级成 priority。默认不开。

Go 代码：分组强制与缺失升级两处写 priority 的分支 — *sub2api v0.2.18 `openai_gateway_request_body.go` 第 2044–2090 行：分组 `ForceOpenAIFast` 在策略评估前就写 priority；没写档位的请求只有命中 `missing` 规则才会被升级。*6

换句话说，客户端说自己是 Standard，与你最后交出去的是不是 Standard，是两件事。中间隔着你自己的配置。

钱是怎么跟着跳的

结算乘数写在同一个仓库的另一处7：priority、fast、ultrafast 一律 2 倍，flex 是 0.5 倍，其余 1 倍。

模型级还有一张更细的表。FastMultiplier、UltrafastMultiplier 有值时按模型自己的数算。

Fast 倍率按模型名写死：gpt-5.4、gpt-5.6 三款、gpt-6-astra、gpt-6.1-sol、gpt-6-sol、gpt-6-luna 是 2 倍，gpt-5.5 是 2.5 倍，不在表里的模型没有 Fast 档价8。

它还会按这个倍率重写 priority 价。注释写明理由：远端目录可能只带官方旧口径，照抄会少计费。

Go 代码：2 倍、0.5 倍与模型级覆盖面 — *sub2api v0.2.18 `billing_service.go` 第 145–172 行：priority 与 fast 都是 2 倍价，flex 打折；模型级 `FastMultiplier` / `UltrafastMultiplier` 优先于这张表。*7

那结算取的是哪一份？取出站 body。extractOpenAIServiceTierFromBody 读的就是上游那份请求体9，调用点在 openai_gateway_forward.go 第 1213 行。

所以「被改成 priority」和「按 2 倍扣了」之间还差一步，那一步能救。

上游回执里带 usage.speed 时，ResolveBillingServiceTier 会把计费档位往下调10。它只降不升：上游说 standard，就按标准价。

这给了一条判据：请求写 priority、回执也回 priority，才是真按快档跑、真按 2 倍算。两者不一致时，钱未必多扣。

CLIProxyAPI 这边记的是哪一档

它记两份。setServiceTierMetadata 读客户端请求体里的 service_tier，缺省记成 auto11。

用量记录里同时有 ServiceTier 与 EffectiveServiceTier，前者是客户端要的，后者是最终出站那份的12。

发给 Codex 上游时，它还会补一个 X-Codex-Routing-Hint，值里带 ;tier=13。

那段注释写得实在：不带这个头时，被翻译过的请求只在 body 里带 service_tier=priority，而后端是否需要这个头才给快档，没有文档。

今天要核的四处

日志按 service_tier 分桶。看 priority 的占比有没有突然抬升，以及它与你配置的默认值是否一致。
先排除自己：分组 ForceOpenAIFast、missing 升级规则、fast policy 里的 force_priority，三处都开着的时候，客户端写什么都没用。
再看上游回执的 usage.speed。只有两边都是 priority，才轮到讨论「多扣了」。
客户的 Standard 设置不能当证据。它只决定客户端提交什么，决定不了你交出去什么。

内置 Devin 目录仍缺 gpt-6-1-sol

这条是接着 10 月 21 日那期说的，今天是第二次有人提。

先说清现在的状态。v8.0.40 整个仓库里，gpt-6-1-sol 只出现过一次，而且是在测试文件里14。

随包的内置目录 internal/registry/models/devin_models.json 一共 56 条 id，没有这一条15。硬编码兜底表里也没有。

远端目录反过来，两份镜像都已经有它，还带着完整的元数据。刷新是启动即拉一次、之后每 3 小时一轮16。

所以缺的只是「本地那份」。三种情形会中招：启动后首次拉取就失败、用 --local-model 起进程、models.devin-catalog 指到一个旧的本地文件。

后果有两条，第二条更隐蔽。一是模型列表里看不到这个 ID。二是档位被丢掉。

ResolveDevinChatModelUID 先拿目录元数据取允许的档位。取不到时，它跳过按档位拼后缀那一步，直接把裸名发上游17。

也就是说，客户端要 xhigh，上游收到的可能只是 gpt-6-1-sol。它不报错，只是不再是你点的那一档。

Go 代码：目录查不到元数据就返回裸名 — v8.0.40 `internal/runtime/executor/helps/devin_models.go` 第 156–218 行：第 158–167 行从目录取档位，第 214–216 行在取不到时直接返回裸名，按档位拼后缀那一步整段跳过。17

补丁是 PR #6923，北京 21:07 开出，4 个文件 +89/−0，mergeable_state 是 clean18。

它同时补内置目录与硬编码兜底：1M 上下文、64K 输出、文本与图片输入、low 到 max 五档思考。测试还钉了两条行为：不写档位时默认 medium，写 none 不支持、也回落到 medium。

这张是第二次。10 月 14 日开的 #6612 补的是同一批缺项，还多带一个 claude-sonnet-5-5；那张单在 10 月 21 日 19:13 由作者自己关掉，维护者没有表态19。

今天这张只补 gpt-6-1-sol，多了两条测试，改法和上一张一致。合不合还不知道。

在那之前，两条路：确认自己实例的远端目录已经拉到、或临时别依赖它的档位后缀。两条都不做，就会安静地少一档。

Gemini 免费档 429，而 Usage 面板是空的

第三条来自 Google 官方开发者论坛，北京 20:43 发帖，到现在一条回复都没有20。发帖人不是 Google 员工。

环境写得很全：gemini-3.8-flash、Free 档、google-genai 2.32.0、默认项目。症状是 429，但没有成因。

他的困惑在后面：AI Studio 的 Usage 面板里，请求、错误、模型用量三项都是 No data available。key 属于所选项目，走的也是 Gemini Developer API。

他自己也在问：这算限流、配额限制，还是项目级的问题。

对运维，这一条能用的只有一句：面板空白不能当成没超限的证据。它同样可能是数据没上报。

要判断就按顺序来。先看 429 回执里的 error 体与错误码，再核项目配额页与 key 所属项目，最后才怀疑模型侧。

没有官方回复之前，这类单帖只能当线索，不能当结论。

上游与额度

OpenAI 状态页全绿，25 个组件零降级，窗口内没有新事件21。最近一条是今天上午的客服响应延迟（北京 11:41 到 13:58），已恢复。

Anthropic 全组件正常，今天没有事故22。Google Cloud 仍是 8 条，最近一条停在 10-22 的 europe-west2，窗口内没有新的23。

Claude 侧的社区这一窗口没有额度线索：anthropics/claude-code 新开 9 条，全是界面与功能类24。

OpenAI 开发者社区 Codex 分区也安静，窗口内没有新话题25。

Codex 重置这边，今天（UTC）还没有发生。最近一次已验证落在 10-22 17:10 UTC，也就是北京 10-23 01:10，20 小时前；累计 57 次，10 次存着，节奏约每 2 天26。

另一家把同一次记成 10-22 17:00 UTC、累计 65 次、中位间隔 3 天27。两家现在指向同一次重置，不再是各写各的。

还有一条没到点的预告。Tibo 在北京 10-23 12:47 说「明天太平洋时间上午 10 点前落地」，换算过来是北京 10-24 01:0028。

追踪站把这条记成未验证，和 10-22 那次一样先挂着26。

今天要做的三件事

先核档位。日志按 service_tier 分桶，priority 突然多起来时，先看自己的分组强制与 missing 升级，再回头问客户端。

Devin 那条通道，在目录刷新成功之前，别依赖 gpt-6-1-sol 的档位后缀。要么确认远端已拉到，要么等 #6923 合进去。

Gemini 的 429，别拿空白的 Usage 面板当结论。先读 429 的 error 体，再核项目配额。

三件事都不需要等发版。

References

1
CLIProxyAPI 发行记录
github.com
2
sub2api 发行记录
github.com
3
codex-proxy 发行记录
github.com
4
codex2api 发行记录
github.com
5
openai/codex #56471
github.com
6
openai_gateway_request_body.go v0.2.18
github.com
7
billing_service.go v0.2.18
github.com
8
billing_service.go v0.2.18
github.com
9
openai_gateway_request_body.go v0.2.18
github.com
10
service_tier_billing.go v0.2.18
github.com
11
handlers.go v8.0.40
github.com
12
usage/manager.go v8.0.40
github.com
13
codex_executor_request.go v8.0.40
github.com
14
interactions_openai_responses_response_test.go v8.0.40
github.com
15
devin_models.json v8.0.40
github.com
16
devin_models_updater.go v8.0.40
github.com
17
helps/devin_models.go v8.0.40
github.com
18
PR 6923：add GPT-6.1 Sol to bundled model catalogs
github.com
19
PR 6612
github.com
20
论坛帖 191855：Gemini 3.8 Flash returns HTTP 429 on Free tier
discuss.ai.google.dev
21
OpenAI Status
status.openai.com
22
Anthropic Status
status.anthropic.com
23
Google Cloud Status
status.cloud.google.com
24
anthropics/claude-code 新开条目
github.com
25
OpenAI 开发者社区 Codex 分区
community.openai.com
26
Codex Reset
codex-reset.com
27
OpenTherank Codex Reset
opentherank.com
28
Tibo：Landing tomorrow before 10am PST
x.com

窗口里落下的只有三条：一条「我配的是 Standard，账单按 Fast 走」的上游报障，一条仍缺着模型的本地目录，一条 429 而面板空白的 Gemini 报障。

前两条今天就能动手核，第三条只能当线索。