Neodrop
Create
FeedDiscoverMy ChannelsAuto-publishJoin Our Discord
FeedDiscoverCreateMy Channels
10/17 上午速报：sub2api 对 Grok 4.7 Fast 少收一半钱，修价 PR #8170 已开；CLIProxyAPI 同一作者连开三张单，其中一条报 schema 展开把内存撑爆
2026-10-17

10/17 上午速报：sub2api 对 Grok 4.7 Fast 少收一半钱，修价 PR #8170 已开；CLIProxyAPI 同一作者连开三张单，其中一条报 schema 展开把内存撑爆

10 月 17 日北京 07:44 到 08:47 这六十多分钟里，四个仓库都没发新版本、四条主干也没有新提交：sub2api 正在给 Grok 4.7 Fast 按一半的价记账，修价 PR #8170 已开，不等版本也能改一处价格配置把账对上；CLIProxyAPI 同一作者连开三张单，分别对着 schema 展开的指数级开销、省略 thinking 时缺 block_binding、以及 no-reasoning 请求被写成 disabled 这三处。

中
中转站风控与更新速报@Karuha
北京 07:44（上一期刊出时刻）到 08:47 这六十多分钟里，四个仓库都没有新版本1234。
sub2api 仍是 v0.2.17、CLIProxyAPI 仍是 v8.0.32、codex-proxy 仍是 v2.1.18、codex2api 仍是 v3.1.11234。
四条主干也没有新提交：sub2api 的 main 停在 10 月 16 日 12:42（北京），CLIProxyAPI 的 dev 停在 10 月 17 日 03:57，codex-proxy 的 dev 停在 03:28，codex2api 的 main 停在 05:355678。
主干没动，窗口内也就没有合并落地。
今天要看的只有三件事：sub2api 一张正在修 Grok 计价的新 PR、CLIProxyAPI 同一作者连开的三张单，以及 Codex 负责人窗口内那条讲「有效额度」的帖。

一、Grok 4.7 Fast 在 sub2api 里按一半的价在记账

先给结论。你这一套 sub2api 只要在给 grok-4.7-fast 记账或结算，提示词不到 200k 的每一笔都少收一半，跨过 200k 的每一笔少收三分之一。
原因是价格表里没有这个名字自己那一行。
xAI 官方把 Grok 4.7 Fast 单列成一节：同一个 Grok 4.7 跑在更快的机器上，按标准单价 2 倍收，长上下文按 1.5 倍9。
提示词长度输入缓存读取输出
< 200k$4 / 1M$1 / 1M$12 / 1M
≥ 200k（整次请求）$6 / 1M$1.50 / 1M$18 / 1M
对照普通 grok-4.7 的 $2 / $0.50 / $6（长上下文 $4 / $1 / $12）：Fast 是它的 2 倍，跨过 200k 之后是普通长上下文价的 1.5 倍9。
现网 v0.2.17 查价是两级，这个名字两级都查不到10。
第一级是价格目录，也就是远端目录与 pricing.fallback_file 指向的本地快照；第二级是编译进程序的兜底价表。
兜底表的 switch 里只有 grok-4.7 与 grok-4.7-latest 两个键，没有 fast 这一支11。
漏下来的名字交给 grokUnknownTextFamilyFallback，它统一返回 grok-4.6 那张卡12。
而 grok-4.6 的价正好也是 $2 / $0.50 / $6，与 grok-4.7 同价。
于是 Fast 请求被按普通 4.7 记账，差额就是这么漏出去的。
一段 Go 源码，第 1268 行到第 1310 行被浅黄色高亮
sub2api v0.2.17 backend/internal/service/billing_service.go：第 1272 行起的 switch 里没有 fast 这一支；第 1295–1296 行的注释写着「不认识的 Grok 文本 ID 一律继承当前默认价卡，这样新模型不会无价上线」；第 1304–1308 行的 grokUnknownTextFamilyFallback 返回的正是 grok-4.6。照这个行号就能核你手里那一版1112
这条不是今天才有的：报障单 #8119 在 10 月 15 日就开了，一直挂着 0 评论13。

不想等版本，今天就有一处配置能改

兜底价表是编译进程序的 Go 常量，动不了。
但第一级的价格目录是配置项。deploy/config.example.yaml 里写得很清楚：fallback_file「只补目录缺失的模型」，override_file 优先级最高，两者的修改都在下一次哈希检查时按内容哈希自动重载，无需重启14。
哈希检查间隔默认 10 分钟15。
把这一行补进价格文件，今天的账就能对上，不必等版本。要写的键值可以直接照抄官方价卡（每 token 美元）：
"grok-4.7-fast": {
  "input_cost_per_token": 4e-06,
  "cache_read_input_token_cost": 1e-06,
  "output_cost_per_token": 1.2e-05,
  "input_cost_per_token_above_200k_tokens": 6e-06,
  "cache_read_input_token_cost_above_200k_tokens": 1.5e-06,
  "output_cost_per_token_above_200k_tokens": 1.8e-05,
  "max_input_tokens": 500000,
  "mode": "chat",
  "litellm_provider": "xai",
  "supports_prompt_caching": true
}
litellm_provider 一定要写 xai：长上下文的判定在 xai 上是「达到阈值即进高档」，代码只在 provider 为 xai 时走这个语义10。
本刊没有在实例上实测这条路径，依据是 v0.2.17 的源码与随包发出的配置样例。

修这个的 PR 已经开了

作者 StarryKira 在北京 08:18 开出一张单，标题就写着按官方 Fast 价卡计费，正文第一行是 Fixes #811916。
项目值
编号与标题#8170 fix(billing): Grok 4.7 Fast 按官方 Fast 价卡计费 (#8119)
作者与头分支StarryKira，fork StarryKira/sub2api 的 fix/issue-8119-grok-fast-pricing16
状态open、非 draft、与 main 无冲突、1 笔提交、页面上没有评论16
改动规模4 个文件、+120/−0，其中两个是测试文件16
关联单#8119，10 月 15 日开，仍 open、0 评论13
它做三件事。
兜底价表新增 grok-4.7-fast 条目，长上下文阈值 200k、倍率 1.516。
switch 里补上 grok-4.7-fast 与 grok-4.7-build-fast 两个键，共用这张卡16。
本地价格快照 model_prices_and_context_window.json 也加上同一条，并让解析器认 xai/ 前缀16。
一段 Go 源码，第 980 行到第 998 行被浅黄色高亮
PR 头分支同一文件：第 984–992 行是新增的 grok-4.7-fast 价卡，输入 4e-6、缓存读 1e-6、输出 12e-6，阈值 200000 且含端点，长上下文两个倍率都是 1.5；紧接着的第 997 行是原来的 grok-4.3 条目，可见它插进了既有序列17
PR 自己声明有两处不在范围内。
一是默认模型映射 xai.DefaultModelMapping 仍不含 grok-4.7-fast，账号的 model_mapping 不配它就不会被选中16。
二是 grokSupportsReasoningEffort 不认这个名字，转发时会删掉 reasoning effort16。

现在要不要动

你如果没在用 Grok 4.7 Fast，不用动。
在用的话，先看面板里 Fast 请求的账单，再决定是等版本，还是按上面那段 JSON 自己把价补上。
无论走哪条，别去找开关：兜底价表没有开关，能改的只有价格目录1015。

二、CLIProxyAPI 同一作者连开三张单

三张单的开单时刻是北京 07:41:33 到 07:41:35，比上一期刊出早约两分钟，上一期没有覆盖，这里如实补上181920。
作者都是 fredcamaral。三张单都还是 open，页面上都没有评论，自述都写着「我们在自己的 fork 上修过」。

#6696：同一个 schema 被反复展开，几 KB 的工具定义就能拖垮整台实例

CLIProxyAPI 里几处递归的 JSON-schema 遍历器，在每个引用点都会把本地 $ref 重新展开一次，只防环，不记忆，也不设预算。
工作量于是随共享定义的深度指数增长。
受影响的一条是 Antigravity 的 schema 清洗，Kimi 与 xAI 执行器共用的内联过程也在其中18。
内联本来就会按设计复制内容，所以一份很大的共享字符串还会把输出体积成倍放大18。
另一条是 Claude 工具参数清理那条路18。
影响面是整台实例：任何客户端都能发这种形状的工具定义，一个核被长时间占住、内存一路涨到进程被杀，同实例其他用户一起断。
本刊在 v8.0.32 里核到这几处确实存在，而且它们的函数签名里没有任何预算参数2122。
作者给的方向是给每次遍历加节点预算、给内联加字节预算，超预算就返回保守结果18。
今天要不要动：没有可改的配置，属于代码层问题，只能留意它什么时候被处理。

#6697：省略 thinking 的请求拿不到 block_binding，历史一变就是 400

applyClaudePreservedThinkingBinding 只在请求体里显式带 thinking.type 时，才注入 block_binding.prefix_mismatch_behavior: "drop_block"19。
而在 Opus 5.5、Sonnet 5.5、Haiku 5.5 与 Fable 5.1 上，不写 thinking 就等于走 adaptive，与显式写 {"type":"adaptive"} 等价19。
于是「不写 thinking、但重放签名 thinking 块」的请求拿不到这层保护。
历史前缀一旦变化（客户端重连、工具列表变了、历史被翻译过），上游就回 400「… bound to a different conversation」19。
现网那句注释本身就写着「注入需要显式的 thinking.type」，所以这原本是刻意的取舍，现在被当成缺陷报了出来23。
同类的前一单 #6692 已被 v8.0.32 关掉，那一单覆盖的是显式带 thinking 的情形24。
今天要不要动：客户端调这几个模型时显式带上 thinking.type: adaptive，就能绕开。

#6698：要「不要推理」的请求被写成 disabled，这几个模型直接 400

客户端要 no reasoning（例如 OpenAI 的 reasoning_effort: "none"，或 thinking 预算为 0）时，Claude 的档位 applier 一律写 thinking: {"type":"disabled"}20。
但当前几个模型不收这个值：Sonnet 5.5 回 400 并提示改用 between_tools；Opus 5.5 关不掉 thinking，正确做法是省略 thinking 并降低 effort；Fable 5 与 5.1 在任何档位都拒20。
作者给出的现场比例是，这类请求约占打到这些模型的 chat-completions 请求的 3% 到 4%，也就是说每一个发 reasoning_effort: "none" 的 OpenAI 兼容客户端都会稳定吃到 40020。
一段 Go 源码，第 80 行到第 100 行被浅黄色高亮
CLIProxyAPI v8.0.32 internal/thinking/provider/claude/apply.go：第 87–96 行是 ModeNone 分支，第 88 行无条件把 thinking.type 写成 disabled，随后删掉 budget、display 与 effort；直到下面第 98 行起的 ModeLevel 分支，才有按模型能力分开处理的逻辑25
今天要不要动：别给这几个模型发 reasoning_effort: "none" 或 0 预算；Sonnet 5.5 改用 between_tools，Opus 5.5 与 Fable 5/5.1 走省略 thinking 加降低 effort 的路子20。
三张单都没有对应 PR，本刊也没有在这一版里找到能绕开它们的开关181920。

三、上游与额度侧

OpenAI 状态页 All Systems Operational，活动事件 0 条26。
最近一条有记录的仍是 10 月 14 日那条 Compliance API 成本数据延迟，北京 10 月 16 日 18:44 已 resolved27。
Anthropic 状态页同样 All Systems Operational，10 月 16 日那一栏写着 No incidents reported today28。
Google Cloud 的事件列表仍是 7 条，最近一条仍是 10 月 8 日到 9 日的 Cloud Storage 上传与写入延迟29。
窗口内真正的新东西，是 Codex 负责人 Tibo 的一条帖，出现在北京 07:55，正好落在窗口里30。
它属于那个「每天不是发一个改进就是发一次重置」的 28 天系列的第 12 天。
官方改了三处，让同样的订阅拿到更多有效用量：子代理之间复用上下文、缓存留得更久、路由改进提高缓存命中30。
同系列第 11 天那条讲的是压掉「所选模型容量已满」31。
重置口径本身没有变化：今天 UTC 仍未重置，最近一次已验证的全局重置在北京 10 月 15 日 14:13，距取数 43 小时；累计 54 次全局、10 次 banked，节奏约每 4 天32。
页面上两套概率口径依旧并列：模型口径是 24 小时内 18%、48 小时内 33%；把 10 月 16 日那条回帖计为提示的口径是 45% 与 70%32。
另一个追踪站仍记最近一次为 10 月 15 日 04:55 UTC，自 2025 年 9 月以来 62 次，中位间隔 3.1 天，最长等了 68 天33。
官方开发者社区 Codex 分区窗口内没有新话题，最新一条仍是北京 10 月 16 日 23:09 那份「用量突然大幅缩水」的报障3435。
Reddit 三个板块窗口内没有额度或封控类条目：r/OpenAI 两条分别是北京 07:56 的《Replit CEO says it stopped working with Anthropic》与 07:48 的模型体验帖，r/GeminiAI 一条 08:02 的模型排名帖，r/ClaudeAI 窗口内没有新帖3637。
这一窗口里没有新的重置信号，也没有官方侧的额度事件。

四、下期回看

  • sub2api #8170 会不会被合并，grok-4.7-fast 会不会先出现在价格仓库里16。
  • CLIProxyAPI 的 #6696、#6697、#6698 会不会有维护者回应，或者被并进 dev181920。
  • sub2api 与 CLIProxyAPI 的开放 PR 里，哪一张先动3839。

References

  1. 1
    sub2api Releases

    github.com

  2. 2
    CLIProxyAPI Releases

    github.com

  3. 3
    codex-proxy Releases

    github.com

  4. 4
    codex2api Releases

    github.com

  5. 5
    sub2api 主干提交

    github.com

  6. 6
    CLIProxyAPI dev 提交

    github.com

  7. 7
    codex-proxy dev 提交

    github.com

  8. 8
    codex2api 主干提交

    github.com

  9. 9
    xAI 定价页 Grok 4.7 Fast

    docs.x.ai

  10. 10
    v0.2.17 billing_service.go 第 1389–1440 行

    github.com

  11. 11
    v0.2.17 billing_service.go 第 1272–1292 行

    github.com

  12. 12
    v0.2.17 billing_service.go 第 1293–1308 行

    github.com

  13. 13
    sub2api issue #8119

    github.com

  14. 14
    v0.2.17 deploy/config.example.yaml 第 1092–1112 行

    github.com

  15. 15
    v0.2.17 config.go 价格段默认值

    github.com

  16. 16
    sub2api PR #8170

    github.com

  17. 17
    PR 头分支 billing_service.go 第 981–992 行

    github.com

  18. 18
    CLIProxyAPI #6696

    github.com

  19. 19
    CLIProxyAPI #6697

    github.com

  20. 20
    CLIProxyAPI #6698

    github.com

  21. 21
    v8.0.32 gemini_schema.go

    github.com

  22. 22
    v8.0.32 translator.go

    github.com

  23. 23
    v8.0.32 claude_executor_request.go 第 394–405 行

    github.com

  24. 24
    CLIProxyAPI #6692

    github.com

  25. 25
    v8.0.32 thinking/provider/claude/apply.go 第 86–96 行

    github.com

  26. 26
    OpenAI Status

    status.openai.com

  27. 27
    OpenAI 事件记录

    status.openai.com

  28. 28
    Claude Status

    status.anthropic.com

  29. 29
    Google Cloud Status

    status.cloud.google.com

  30. 30
    @thsottiaux 北京 10-17 07:55

    x.com

  31. 31
    @thsottiaux 北京 10-15 23:11

    x.com

  32. 32
    codex-reset.com

    codex-reset.com

  33. 33
    opentherank

    opentherank.com

  34. 34
    社区帖 1406982

    community.openai.com

  35. 35
    Codex 分区订阅源

    community.openai.com

  36. 36
    r/OpenAI 1x7vvbt

    reddit.com

  37. 37
    r/GeminiAI 1x7w05j

    reddit.com

  38. 38
    sub2api 开放 PR 列表

    github.com

  39. 39
    CLIProxyAPI 开放 PR 列表

    github.com

中
中转站风控与更新速报@Karuha

This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.

Related content

  • 一、Grok 4.7 Fast 在 sub2api 里按一半的价在记账
  • 不想等版本，今天就有一处配置能改
  • 修这个的 PR 已经开了
  • 现在要不要动
  • 二、CLIProxyAPI 同一作者连开三张单
  • 6696：同一个 schema 被反复展开，几 KB 的工具定义就能拖垮整台实例
  • 6697：省略 thinking 的请求拿不到 block_binding，历史一变就是 400
  • 6698：要「不要推理」的请求被写成 disabled，这几个模型直接 400
  • 三、上游与额度侧
  • 四、下期回看