订阅还是按量付：算一次「每月每百万 token 到底多少钱」 · Skills

订阅制最大的问题是它不告诉你单价。20 美元一个月，你能用多少 token、每个 token 折多少钱，全靠猜。而 12 月起额度还要在 ChatGPT 和 Codex 之间共享，猜的空间更大了。

这件事可以算出来，而且不需要等官方公布任何数字——你自己用掉的量，加上公开的 API 单价，就够了。

第一步：拿到你自己真实的输入和输出 token 量（5 分钟）

这一步的关键是别只看总量。API 的输出单价比输入贵 4 到 5 倍，只记一个总数，算出来的混合价会偏得离谱。

三条取数路径，任选一条：

有 API key 的：直接在账单或用量的 usage 明细里拉 input_tokens 和 output_tokens 两列，取最近 30 天。这是最准的。
纯订阅、没有 API：ChatGPT 在 Settings → Usage 里给的是额度消耗，Claude 在 /usage 里给的是窗口内的用量。这两个数字口径不一定和 token 一一对应，能拿到近似值就够用，拿不到就跳到第三条。
都没有：装一个本地代理，把请求记成 JSONL（model、input_tokens、output_tokens、时间戳），跑一周。一周的样本外推一个月，误差在 20% 以内，足够做决策。

顺手记两个字段：月费（订阅实际支付金额）和额度利用率（你实际用掉的量 ÷ 额度上限）。第二个字段后面会决定结论翻不翻转。

第二步：跑脚本（5 分钟）

把三个数丢进去：月费、月度输入 token、月度输出 token，外加你在考虑的 API 的输入/输出单价。

// cost-per-mtok.mjs
// 用法：node cost-per-mtok.mjs
const cfg = {
  subMonthlyUsd: 200,        // 你的订阅月费
  inputTokens:   120_000_000, // 近 30 天输入 token
  outputTokens:   12_000_000, // 近 30 天输出 token
  api: {                     // 候选 API 的公开单价（美元/百万 token）
    name: "Sonnet 5.5",
    in: 2.0,
    out: 10.0,
  },
};

const { subMonthlyUsd, inputTokens: i, outputTokens: o, api } = cfg;
const total = i + o;

// API 在你这个输入/输出比例下的混合单价（美元/百万 token）
const blendedApi = (i / 1e6) * api.in + (o / 1e6) * api.out;
const blendedApiPerMtok = (blendedApi / total) * 1e6;

// 订阅的隐含单价：月费摊到同样这些 token 上
const subPerMtok = (subMonthlyUsd / total) * 1e6;

// 反向问题：这笔月费如果按 API 买，能买到多少 token？
const equivalentTokens = (subMonthlyUsd / blendedApiPerMtok) * 1e6;

const ratio = subPerMtok / blendedApiPerMtok;

console.log(`总 token       ${(total / 1e6).toFixed(1)}M（in ${(i / 1e6).toFixed(1)}M / out ${(o / 1e6).toFixed(1)}M）`);
console.log(`API 混合单价   $${blendedApiPerMtok.toFixed(3)} / 1M`);
console.log(`订阅隐含单价   $${subPerMtok.toFixed(3)} / 1M`);
console.log(`比值           ${ratio.toFixed(2)}`);
console.log(`月费折算 token ${(equivalentTokens / 1e6).toFixed(1)}M`);
console.log(ratio <= 0.8 ? "结论：留订阅"
  : ratio <= 1.2 ? "结论：双轨（订阅保底 + API 兜溢出）"
  : "结论：迁 API");

上面这组示例数（200 美元、1.2 亿输入、1200 万输出、Sonnet 5.5 的 2/10 美元）跑出来，API 混合价约 2.73 美元，订阅隐含价约 1.52 美元——比值 0.56，订阅明显划算。

注意这个比值对用量极其敏感：同样 200 美元，如果一个月只用掉一半（6600 万 token），订阅隐含价就涨到 3.03 美元，比值 1.11，落到双轨区。订阅划不划算，八成取决于你有没有把额度用满，而不是取决于模型单价。

第三步：三个阈值怎么用

比值 ≤ 0.8：订阅便宜近三成以上，留着。但每季度重算一次，因为额度口径会变。
0.8 < 比值 ≤ 1.2：双轨。订阅当保底和心智成本，把批量、可延迟的活丢给 API（Batch 还能再打 5 折）。
比值 > 1.2：迁 API。这个区间几乎只有一个成因——你付了固定月费，但没把额度用掉八成。

还有一个常被忽略的数：月费折算 token。如果它比你实际用量大很多，说明你在为闲置额度付钱——这时候该干的第一件事不是换 API，是降档。

怎么知道自己算对了（验收标准）

输入和输出 token 分开记，不是只记一个总数。只有总数的那份表，结论不可信。
用的是最近 30 天连续数据，不是某个忙周的峰值，也不是某个摸鱼周的低谷。
脚本里 API 单价是你当天从官方定价页抄的数字，不是三个月前的截图，也不是二手博客。
算出了 月费折算 token，并且和你的实际用量对比过一次。这两个数的差距，就是你在为闲置付的钱。
结论写成一句话加一个日期（例：2026-11-02 比值 0.56，留订阅，2027-02-02 复算）。没有日期的结论三个月后就没用了。

三个容易算错的坑

只看输入单价。 现在很多模型的输出价是输入的 4 到 5 倍。如果你的场景是长文生成、agent 多轮工具调用，输出占比可能过半，这时候用输入价做比较会高估 API 的便宜程度，得出”赶紧迁”的错误结论。

把额度上限当用量。 200 美元的档位写着每月多少额度，那是天花板，不是你的消耗。用天花板算出来的单价会漂亮得像广告。

忘了 credits 这条赛道。 额度用完可以直接买 credits 继续用。这笔钱不进月费，但进账单。算总成本的时候要把它加回月费里，否则订阅的性价比是虚的。

最后一句

这套算法的价值不在于得出”订阅好”或”API 好”，而在于它逼你把两件事说清楚：我一个月到底烧多少 token，以及我在为什么付钱。 额度池合并之后，第二件事会越来越难看清——账本自己得留着。