很多人挑 AI 编辑器时盯着一行订阅价就下判断，结果用起来才发现真正花钱的是调用额度、超量规则和自备 API 的部分。这篇不替你选，只给一套能自己跑的算法：先把两边的计费口径对齐，再拿你自己的日用量套进去，最后核对当初看的价格是不是过期了。适合已经试过其中一边、准备定下来的人。
很多人挑 AI 编辑器时，习惯先看一行订阅价，然后凭这行数字下判断。真用起来才发现，花钱的大头往往不在那行标签上，而在套餐里到底包含了什么、超出之后按什么规则加价、以及有多少活儿得自己接 API 去做。这三个变量一组合，两边的实际成本曲线可能完全反过来。
这篇不替你选，只给一套能自己跑出来的算法：先把两边的计费口径对齐，再看清自己每天到底用掉多少，然后折算成同一个单位、按自己的真实用量套一遍月成本，最后核对当初看到的价格是不是已经过期。适合已经试过其中一边、准备定下来的人。
先别比价格标签，先对齐两边到底在卖什么
同一个数字摆在两个产品页上，含义可能完全不一样。有的订阅把编辑器功能和模型调用打包在一起卖，额度用完再谈加价；有的订阅只买工具本身，调用得你自己接 key 按量付。这两种结构下，订阅价高低根本不能直接横着比。
- 固定月费
- 不管用多少都要付的那一笔，通常对应编辑器功能本身
- 额度内调用
- 套餐里已经包含的对话或补全次数，超了才开始另算
- 额度外规则
- 超出后是禁用到下个周期、还是按量加价、还是可以切自备 key
- 自备 API
- 工具不提供调用，由你接某家官方接口，按那家的口径付费
什么情况下不适用：如果你基本只用补全、几乎不跑长对话式的改代码任务，两边的差距会被压得很平，下面这套算法对你的参考价值不大，直接按手感挑就行。
- 先确认模型调用是不是含在订阅里，别默认两边结构一样
- 再确认额度是按次数、按时长还是按某种折算单位计
- 最后确认额度外是断供、加价还是允许自备 key，这三条决定了重用户的真实成本
- 把口径不同的部分单独标出来，别硬凑成一个数
把自己的用量先列出来，不然比什么都是空的
两边价格谁高谁低，取决于你一天用掉多少。没有用量数据就去比套餐，等于拿别人的体重买自己的鞋。花一周把这几个量记下来，比看十篇对比文都管用。
- 补全：每天触发多少次、每次大概多长，是不是长时间挂着
- 对话式改代码：每天开几轮，每轮平均问几遍才收敛
- 上下文体量：一次任务大概要带多少文件、多少历史对话进去
- 返工率：有多少轮是你重新描述需求才得到想要的结果，这部分也算钱
刚上手没数据，就拿一周的真实日志估，别用感觉。会话记录如果散在各处，可以借站内工具把它整理成一份可读清单，对着清单数比凭记忆记靠谱得多。
把两边的额度折算成同一个单位再比
两边的套餐描述可能一个写次数、一个写时长，看着都对不上。这时候要做的是尽量还原成同一个单位——要么是 token，要么是单次任务量。还原不了的就老老实实标成口径不明，别硬换算。
| 原始口径 | 怎么还原 | 还原不了怎么办 |
|---|---|---|
| 每月若干次请求 | 统计你自己一次请求的平均 token，乘回去 | 把平均值当区间处理，别当定值 |
| 每月若干小时 | 按你每小时大概跑几轮、每轮多大上下文折算 | 标为口径不明，决策时给折扣 |
| 按积分或点数 | 先查积分和用量的换算说明 | 查不到就单独列一栏风险 |
| 不限量但有公平使用条款 | 看有没有并发和频次限制 | 当作软上限，按重度档估 |
单次或单位量的价格，可以去站内的换算工具里按当时的数字对一遍，别拿几个月前看到的数直接套。换算完把两边的结果并排放在一张表上，口径不明的项目单独标色。
按自己的用量套一遍月成本
把口径对齐之后，就可以套一个简单的式子：月成本等于固定月费，加上超出额度部分按量折算的费用，加上自备 API 的调用费，再加上可能的汇率和支付手续费。这个式子不复杂，难的是每一项都要用自己的数，不是用别人的数。
- 分三档建场景按每天几轮、半天在用、全天长上下文跑三个档位，分别估各自的调用量，别只算一个平均档
- 套式子算一遍每一档分别算固定月费加超量折算加自备调用加手续费，得出两条成本曲线
- 找交叉点看两条曲线在哪个用量区间交叉，那个点才是你该关心的，不是订阅价本身谁低
- 留出误差带把口径不明的部分按上限和下限各算一次，得到一个区间而不是一个点
外币订阅的汇率成本常被忽略，付的时候按当时汇率走，续费时可能又变了一次。所在地区的价格口径，去站内的套餐页核一遍，别只记住订阅价那个数。
比价比的不是标签上的数字，是你自己的用量套进去之后那条曲线。
额度重置和超量规则，是最容易算漏的一笔
额度过期不累积、按周期重置，意味着两头都会吃亏：用不满的部分白白浪费，用超的部分按加价档走。很多人只算了超支那一头，忘了闲置那一头也是成本。
判断标准很简单：先看你的用量是贴着额度线波动，还是离额度线很远。贴着线波动的，重置规则影响很大；远低于额度的，这笔基本可以忽略。
| 用量位置 | 重置规则的影响 | 该怎么做 |
|---|---|---|
| 长期远低于额度 | 几乎为零 | 别为额度买大套餐 |
| 贴着额度线波动 | 很大，两头都可能踩 | 按波动上限估，别按平均值 |
| 长期超出额度 | 看超量是加价还是断供 | 允许自备 key 的一方优势会放大 |
| 用量季节性波动 | 按旺季上限估 | 淡季闲置的成本要算进去 |
不适用的情况：如果你的用量恰好稳稳卡在额度下面一点点、每个月都差不多，重置规则对你的影响几乎为零，可以跳过这一节直接看自备 API 那条路。
自备 API 这条路值不值得走
自备 API 看起来单价更透明，但你要自己承担调试接口、处理失败重试、优化上下文长度的活。这些时间不是零成本，只是从账单换成了工时。如果这些活你本来就在干，那成本确实低；如果你指望工具帮你兜底，那省心的部分是有价的。
- 用量明显超过订阅额度，且超得比较稳定，自备才有明显优势
- 你能把无效调用压住，比如不让整仓库无脑塞进上下文
- 你愿意维护 key、重试逻辑和失败兜底，不会因为接口抽风就停工
- 反过来，用量在额度内、又要省心，就别为了低单价去接一堆线
要接哪家、按什么口径算单价和失败重试，去站内的官方 API 资料和编码套餐页对一遍当时的数字，再决定这条线值不值得自己搭。
下单前必须核对的四项
前面几步算出的都是估算，下单前还得把几个容易过期的数字核一遍。价格和额度经常调，凭记忆下判断最容易翻车。
- 核当前订阅价与额度去站内对应的订阅页看当时的数字，别用记忆里的价，截图或记下来备查
- 核汇率与地区价去站内套餐页确认自己所在区的计价口径，外币项按当前汇率估
- 核隐性规则失败重试算不算额度、并发有没有上限，看站内关于重试计费的说明
- 记账并回填把上面几步的数字整理成一张表，一个月后拿真实账单回填，看偏差出在哪
这套流程跑完，你会发现决定划算与否的从来不是订阅价本身，而是你的用量结构跟哪边的计费方式更贴合。用量轻、任务短的人，两边差别很小；用量重、上下文长、又愿意自己搭线的人，差别主要落在超量规则和自备路线上。
下一步把两边的当前价格和额度口径并排核一遍，再拿自己记了一周的用量套进去算；站内的价格追踪和套餐对比页能帮你确认当时的数字，别用旧价下判断。→常见问题
只看月费能不能判断哪个划算？
基本不能。月费只是固定那一块，真正拉开差距的是额度外的计费方式、额度过期是否作废、以及能不能切自备 API。建议先按自己的日用量把三档成本都算一遍，再看两边的曲线的交叉点在哪，而不是比标签价。
用量很小的人该怎么选？
如果你每天只是补全为主、偶尔问几句，两边的成本差距会被压得很小，这时候更该看的是额度过期规则和切自备 API 的方便程度，而不是省那几块钱。用量小的人可以先看哪边免费或低价档能覆盖日常。
自备 API 一定比订阅便宜吗？
不一定。自备 API 的单价通常更低，但你要自己处理上下文裁剪、失败重试和调试，这些都会吃掉时间。只有当你的调用量明显超过订阅额度、且能把无效调用压下来时，自备才会真正省钱，否则订阅的固定费买的是省心。
怎么知道自己的用量到底在哪个档？
先记一周的真实记录，按天列补全次数、对话轮数和平均上下文长度，再换算成 token 或任务数。如果连一周数据都没有，可以先按轻度、中度、重度各算一版，等有账单再回填修正，不要凭感觉定档。
额度用完了继续用会不会很贵？
看两边的超量规则。有的会把超量按更高的档位计费，有的直接限制你继续用、只能自己接 API。下单前一定把这部分规则读清楚，尤其是额度过期是否清零、超量是否自动扣费，这两条影响最大。
