real-api-pricing 是一个把「订阅月费 ÷ 实际可用 token」算成真实 API 单价，并按各榜单画出帕累托前沿的开源定价项目。2026-10-03，它的决策记录里只加了一句话——Factory Droid 的 30 天滚动窗 = 2 × 7 天窗——却让 Droid 全部 28 个数据点的月额度减半、单价翻倍，六个榜单的前沿点随之换人。本文带你完整拆解这次裁定：从本机实测的疑点信号，到三步算术，再到前沿图上的连锁反应。

🔍 先看背景：为什么「1 月 = 4 周」对 Droid 不成立

项目的通用口径很简单：订阅额度按饱和使用折算，默认 1 个月 = 4 周（见 CONVENTIONS.md 第 2 节）。2026-09-29，维护者在本机实测了 Droid Max（$200/月）跑 Claude Opus 5.5：7 天滚动窗从 1% 用到 9%（8 个百分点），累计 72,166,562 个 token，按 Opus 5.5 标价折成段 worth $42.34，套用通用公式「周 worth × 4 周」得到50.52 亿 token/月。

但这里埋了一个隐患：Droid 官方有5h / 7 天 / 30 天三个独立滚动窗，而样本只约束了 7 天窗。当时记录就明确写道——「30 天窗若小于 4× 周池，实际月可用会低于本值」（证据文件 droid-opus55-max-round1-2026-09-29.json）。

随后两个信号让「×4 周」站不住了：

1. 社区口述对不上：Droid Pro（$20/月）用户跑 Opus 5.5 估算出周 ≈$45、月 ≈$160 的等价 API 消耗（droid-pro-opus55-community-round1-2026-09-29.json）。月值只约为周值的 3.56 倍，而不是 4 倍——说明 30 天窗大概率比 4 周池小。
2. 实测交叉验证同向：本机实测 Max 的月 worth ÷ 官方 10× 倍率，比 Pro 帖主的估算高约 33%，同样指向「30 天窗 < 4× 周池」。

📊 裁定详解：30 天窗 = 2× 周，三步算术

2026-10-03，维护者裁定（原文见 DECISIONS.md 首条）：Droid 月额度 = 周 worth × 2，作为 Droid 专用例外，不改通用 ×4 周。落到数字上：

三步算术以 Max × Opus 5.5 为例：段 worth$42.34 ÷ 8%得周 worth $529.24，× 2得月 $1,058.45 list-worth，再 ÷ Anthropic 档混合价$0.419/MTok= 25.26 亿/月。整数读数敏感性（Δpp∈[7,9]）对应 22.46 ~ 28.87 亿。

两个细节体现裁定的严谨：

• Pro 行换了证据锚：帖主口述月值 $160（≈周值 3.56×）与「2× 周」不符，不采；改用周 $45 × 2 = $90 折算。
• 26 个派生行按同倍率随动：Droid Max 同池的 26 个模型（Fable 5.1、GPT-6 Luna、Grok 4.7、DeepSeek V4.1 Flash 等）全部按 官方模型倍率表 减半，不单独调整任何一行。

📈 连锁反应：为什么说「前沿点全部换人」

帕累托前沿的选点规则是：只要存在另一个点同时更便宜且分数更高，当前点就被支配、掉出前沿。Droid 的月额度减半后，单价全部翻倍，最直接的后果就是它在图上向右（更贵）平移了一格。

DECISIONS.md 原文记录了影响范围：AA Intelligence、AA TB4、Code Arena、Agent Arena、AA Coding Agent、OpenDesign Arena 六个榜单的前沿点变化——Droid Max 的 GPT-6 Luna、GLM-5.3 Flash、Claude Fable 5.1 等点单价翻倍后，部分被OpenCode Go、Command Code GOAT、GLM Coding Pro 国区闲时、Claude Max 20x这些更便宜的点取代。

以 AA Coding Agent 榜为例，裁定后的前沿前两位变成了：第 1 位 Command Code GOAT × DeepSeek V4 Flash（$10/月），第 2 位 Droid Max × GPT-6 Luna（$200/月、101.04 亿 token/月，倍率 0.04× 使其成为池内最"划算"的模型）——Droid 靠 Luna 这一个点保住了前沿席位，其余派生行则出局。

🗂 怎么读这份决策记录：从证据文件到出图

这个仓库的规矩是：改数只能改 scripts/build_adopted.py，改完必须在 DECISIONS.md 同步记一笔（旧值 → 新值 → 依据 → 未采来源）。整条链路是：

1. 证据落盘：所有原始观察（面板截图读数、token 分拆、标价、交叉验证）按日期存进data/research/，本次裁定的两份证据文件自 09-29 起一字未动，变的只是口径；
2. 采用值生成：build_adopted.py输出 data/adopted.csv，每行带decision_note列写明取舍理由，data/conventions.json的updatedAt推进到 2026-10-03；
3. 重算与出图：scripts/compute.py 重算派生点，绘图脚本重新生成charts/下全部双语图表，CI 会逐文件比对防止漏更新（流程见 BUILD.md）。

💡 三个可以带走的结论

• 口径是裁定，不是默认值。「1 月 = 4 周」只是缺少厂商定义时的假设；一旦证据（社区口述 + 本机实测）指向别的值，就要裁定修正，哪怕只影响一家。
• 例外不污染全局。Droid 改 ×2 之后，通用 ×4 周原样保留，Kimi 的「月池 = 5× 周」也原样保留——每个例外都写清了适用范围。
• 每个数字可追溯。从前沿图上的任何一个点，都能反向追到adopted.csv的decision_note，再到data/research/里带日期的证据文件——这正是 README.md 所说的「核心资产是 X 轴数据的可信度」。

想复现全部图表？按 BUILD.md 的顺序跑一遍脚本即可；想查其他案例，charts/en/frontier/ 下每榜都附有完整的前沿表文本，可直接对照阅读。