你在挑 Codex 中转站时，多半会遇到这种场面：几家报价单长得不一样，有的写倍率，有的写包月，有的只给一个模糊区间，看半天也不知道哪家实际更贵。这篇不报具体数字，只给一套对比口径和排查顺序，让你拿自己的真实用量去套，能把不同站点的费用摊到同一张表上。数字类的东西，一律去站内对应页面看当时的值。
你在挑 Codex 中转站时，多半会遇到这种场面：几家报价单长得不一样，有的写倍率，有的写包月，有的只给一个模糊区间，看半天也不知道哪家实际更贵。这不是你不懂行，是大家的口径本来就不统一。同一段代码审查，在甲站按 token 算、在乙站按次数算、在丙站包月封顶，横向比较几乎没有意义。
这篇不报任何具体数字，只给一套对比口径和排查顺序。你拿自己的真实用量去套，就能把不同站点的费用摊到同一张表上。凡是需要看价格、倍率、状态的地方，一律到站内对应页面核对当时的值，别拿截图和口头承诺当依据。
先把计费单位对齐，再谈贵不贵
计费单位不对齐，后面的比较全是白费力。中转站常见的三种口径——按 token 倍率、按次或按请求、按包月额度——之间不能直接比大小，就像拿重量跟体积比。动手前先做一件事：确定你要用的那个模型是哪一档倍率，再决定用哪把尺子量。
- 记下官方基准价先到官方页面看当期按量单价，把它当成所有倍率的基准尺。中转站的倍率只有对照这个数才有意义，否则你不知道它相对官方是贵还是便宜。
- 确认自己的调用形态长上下文、频繁重试、带工具循环的调用，用按次计费会严重失真，优先看按量口径。调用次数少但单次很重的场景，按次反而可能更友好。
- 换算到同一口径用站内的换算工具把你的月消耗折算成金额，三家的口径都换成同一个数再摆在一起，表格自然就出来了。
看懂报价单上的费用区间是怎么来的
报价单上的区间不是随便写的。下限通常对应低倍率分组、缓存命中或批量折扣，上限对应默认分组或高峰时段。中间的差距，多数时候是分组差异，不是同一档在浮动涨价。所以你要问的不是「区间多大」，而是「每一档分别适用于谁」。
| 区间位置 | 常见对应条件 | 你该确认的事 |
|---|---|---|
| 区间下限 | 低倍率分组、缓存命中、批量折扣 | 你的调用能不能命中这个条件 |
| 区间中段 | 默认分组的常规时段 | 你的主要用量是否落在这里 |
| 区间上限 | 高峰时段、高倍率分组、加价功能 | 峰值时段的调用占比有多少 |
| 只给单一数字 | 未说明分组或分档条件 | 按最坏情况估预算更稳 |
- 把你要用的模型在哪个分组找出来，不同分组的倍率可能差出一大截，先定位再比总价。
- 分组名字看不懂，就到站内 API 分类导航和分组说明页对照，别自己猜。
- 报价单只给笼统区间、不给分档条件的，按上限估预算，留出余量。
- 同一家站点的区间若频繁变动，把当期截图连同页面一起保存，后面排查有据可依。
用「单任务成本」代替「单价」做决策
倍率再低，跑一个任务的实际花费也可能高，因为隐性消耗藏在重试、超长上下文和被限速后重跑里。所以做决策时，与其纠结单价，不如挑一个你真实会跑的任务——一次代码审查、一次批量重构——在几家站点各跑一遍，记住消耗和花费，换算成每次任务多少钱。
| 观察项 | 说明 | 异常时怎么查 |
|---|---|---|
| 单任务消耗量 | 同类任务三到五次取中位数 | 样本太少就先补几次再判断 |
| 单任务花费 | 按你实际用到的分组折算 | 偏差大就回看分组是否选错 |
| 重试与重跑次数 | 次数多说明连接或限速有问题 | 对照站内状态页看当期表现 |
| 响应稳定性 | 忽快忽慢会影响总耗时成本 | 连续几天不稳的站点按短期预算处理 |
- 任务成本明显偏低的站点，先别急着下单，去看当期状态和雷达页，低到不合理的要查原因。
- 单次任务的样本太小，建议同类任务跑三到五次取中位数，避免被一次偶然的快速响应误导。
- 把每次任务的花费记在一个固定表格里，累积一个月，比任何报价单都贴近你的真实支出。
- 同一任务在不同站点的耗时也记下来，换算成时间来算人时成本，有时比省钱更重要。
额度、有效期和结算方式也要算进成本
包月额度的折算关键在「用不用得完」。用不完，等于单价被动抬高；用得完，才谈得上划算。充值余额有没有有效期、能不能结转、超额之后按什么口径计费，这三条直接决定你的实际月支出，不能只看面值。团队共用一个额度时，人均成本要按实际并发占用估，不是简单除以人数。
- 额度结转
- 本月没用完的部分能否留到下月，直接决定包月是否划算。
- 超额计费
- 超出额度后按什么口径继续扣，是隐形支出的大头。
- 并发占用
- 多人共用时按峰值同时调用估，人均不是简单平均。
- 用量波动
- 集中赶项目的几周和平时差别大，波动大更适合按量口径。
- 用量波动大、集中在某些周的，按量口径通常比包月更可控，不会为闲置期付费。
- 稳定日更、额度基本能用满的，包月更省心，也更容易做预算。
- 结算方式若涉及预充和余额，去站内条款说明页核对有效期与退款规则，别只看首页宣传。
- 团队场景建议按人头预估并发峰值，再乘以你实际用到的分组倍率，别用平均值拍脑袋。
这套比法什么时候不适用
这套方法解决的是「同类需求下怎么横向比」，不是万能的。下面几种情况，硬套反而会误导决策，早点识别出来能省不少时间。
- 只做一次性小额试用、跑通流程就走的，没必要精细折算，打通链路比省钱重要。
- 对数据合规、审计有硬要求的场景，价格不该是第一排序项，先过合规再谈费用。
- 上游渠道本身不稳定、经常限速或调整分组的站点，任何静态费用对比都会很快失效，建议只按短期预算处理。
- 只想找一个「绝对最低价」、不看自己用量的诉求，这篇帮不上；价格低到异常，通常有别的代价在等着。
费用对比的终点不是找出最便宜的那家，而是找出你这套用量下最不容易翻车的那家。下一步拿你的真实月用量套一遍上面的口径，再去站内费用追踪与站点目录核对当期数字，两组数据放一起才是可用的结论。→
常见问题
Codex 中转站的费用一般怎么表示？
多数站点用「倍率 × 官方单价」的方式表示，也有按次计费和包月额度两种。前者的关键是你用的模型落在哪个分组，后者的关键是额度能不能用完。具体倍数和金额请到站内对应页面对照当期数据，报价单变化比文章快。
倍率低的站点是不是一定更便宜？
不一定。倍率低但分组受限、上下文上限小、重试多的话，单任务实际花费可能更高。而且倍率低往往对应非官方渠道，稳定性和模型一致性要单独验证。建议用单任务成本横向跑一遍，再看站点当期状态页的表现，别只看一个数字。
包月和按量，Codex 场景该选哪个？
看用量是否稳定。每天都跑固定几轮代码任务的，包月能把上限锁住；用量集中在赶项目那几周、平时几乎不调的，按量更不容易浪费。可以先按量跑一个月，拿真实消耗去套包月额度，看折算下来是剩还是亏，再决定换不换。
