"要不要干脆改用 API,别订阅了?" —— 只要团队开始把 Claude 接进产品或内部工具,这个问题迟早会被问出来。诚实的答案是:取决于你的用量形态,而不是哪个方案听起来更便宜。这篇文章给你一套自己就能算的框架,不需要知道当前具体的每 token 价格——因为价格会变,应该永远以实时数据源为准,而不是抄一篇博客里的数字。
两种完全不同的计费模式
订阅(浏览器里或聊天 App 里用的那种)是固定周期费用,买断一份用量额度——用量大的用户往往还会遇到软上限、限流或"公平使用"节流。不管你当天发了 5 条消息还是 50 条,扣的钱都一样。
API 则是按量计费:按一次请求实际消耗的 token 数扣费,不多不少。一个搭建规范的网关,计费流程通常是这样:
- 请求进来时,网关先按估算值做一次预扣。
- 上游模型返回结果后,系统按上游报告的真实 token 用量结算。
- 如果上游调用失败,预扣的额度会自动退回——没跑完的请求不会扣你钱。
即使你从不打开账单面板,也值得弄清楚这三步逻辑,因为正是它让 API 计费能做到真正跟用量成正比,而不是一个黑箱。Apiko 全链路走的就是这套机制,也正因如此,下面的成本对比才有意义:你拿到的数字就是实际扣费的数字,不是需要盲目相信的估算。
自己动手算一笔账
与其纠结"到底哪个更便宜",不如回答关于自己用量的三个问题:
1. 一次典型请求要消耗多少 token?
Token 数取决于你的 prompt 长度(包括系统提示词和每次重新发送的对话历史)加上响应长度。一次简短的问答可能只有几百 token;而把一整份文档塞进上下文,或要求输出很长的结构化结果,可能轻松跑到几万 token。如果你还不清楚这个数字,最省事的办法是拿几个真实请求跑一遍 Playground 或日志代理,把返回结果里的 usage 字段读出来——大多数兼容 OpenAI 协议的 API 都会在响应里带上 prompt_tokens 和 completion_tokens,流式响应也可以要求在最后一个 chunk 里带上同样的数字(见下面的代码示例)。
2. 一个计费周期里你实际会发起多少次请求?
要具体:是"开发者写代码时一天调用 Claude 十来次",还是"每来一张工单就自动触发一次调用,7×24 小时不停"?订阅模式更适合第一种——用量平稳、节奏由人来把控、很少碰到上限。按量计费则完全没有上限的概念,成本纯粹跟用量走,这更适合突发的、难以预测的,或者高频自动化的场景——否则你只能猜哪个订阅档位够用。
3. 你能接受多少"闲置也要付费"的成本?
订阅不管你用不用都要交钱——包括没人碰它的那些日子、新功能的试用期,或者一个项目收尾之后的长尾时间。按量计费天生没有闲置成本:一个月零调用,那个月账单就是零。如果你的用量是间歇性的(上线周、演示、内部工具偶尔用几次),光是这一点差异往往就足以抵消掉每 token 价格上的差距。
一个简单的决策公式
把上面三个答案代进这个粗略公式:
预估月度成本 ≈ (平均输入 token + 平均输出 token) × 月请求数 × 每 token 单价
你不需要今天就知道每 token 单价——这个变量恰恰应该来自实时、当前的价格源,而不是靠记忆或猜测,因为 token 定价会随时间和模型不断变化。拿到你自己的 token 数和请求数估算之后,代入实时价格表里的当前数字,再跟订阅的固定月费比一比。如果算出来的估算值明显低于订阅价,按量计费的 API 在成本上更划算;如果你的用量足够大、足够稳定,估算值超过了订阅费,那就该评估一下订阅(或更高用量的商务方案)。
更适合选 API 的情形:
- 用量是自动化的、突发的,或者难以预测
- 需要按请求核算成本(给客户计费、跟踪项目预算)
- 还在评估或做原型,不想先押上一笔固定月费
- 想要一个能横跨多个模型使用的余额,而不是绑死在单一产品上的订阅
更适合选订阅的情形:
- 单人使用,日常交互用量平稳,稳稳落在套餐软上限以内
- 你更看重固定账单的可预期性,而不是按量计费
- 完全不需要程序化接入
从 API 里读出真实用量
如果你要为上面的公式估算 token 数,最好显式请求用量数据,从响应里直接读出来,而不是靠猜。开启流式输出时,带上 stream_options.include_usage,这样最后一个 chunk 就会附带用于计费的真实 token 数:
curl {GATEWAY_BASE_URL}/chat/completions \
-H "Authorization: Bearer $APIKO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "claude-sonnet-4-5-20250929",
"messages": [{"role": "user", "content": "Summarize this in two sentences: ..."}],
"stream": true,
"stream_options": {"include_usage": true}
}'
把 {GATEWAY_BASE_URL} 换成你部署的网关地址。拿几批有代表性的请求跑一遍,把返回的 prompt_tokens 和 completion_tokens 取平均,你就有了代入上面公式的真实数字,不用再靠猜。如果网关还支持导出用量日志(CSV、按请求算成本、可按日期筛选),这一步会更省事——直接拉一周的真实流量算平均值,不用手工抽样。
别猜价格——去查实时数据
不管你最后用哪套框架,唯一不该硬编码的就是当前的每 token 价格。服务商会调整定价、新增模型档位、修改上下文窗口限制,任何写进文档或博客的数字,从落笔那一刻起就已经开始过时。在敲定任何估算之前,先从实时数据源拉一次当前价格。
如果你想直接拿 Apiko 算一遍,pricing 页面 展示了目录里每个模型的实时每 token 费率,模型目录 列出了当前可用的模型——两者都直接读自计费系统所用的同一份数据,所以你看到的就是实际会扣费的数字。如果你还在观望,新账号注册即送试用额度,无需绑卡,可以先跑一批真实请求、读一遍真实的 usage 数字,再决定选哪种模式。注册 直接体验,或者如果你的 token 估算已经算好了,直接去 pricing 对照实时价格表。