你可能是这样卡住的：前阵子用着还行，这阵子感觉额度掉得快，或者中转站报价单上的数字和记忆里不一样，于是开始怀疑是不是官方涨价了、额度缩水了。这篇不给你一个「涨了」或「没涨」的结论，而是给你一套自己核对的办法：先分清是官方订阅额度、官方按量价、还是中转站报价这三件事，再按顺序去站内对应页面比一遍，最后判断变化落在哪一层、要不要调整用法。
你可能是这样卡住的：前阵子用 Codex 写代码还挺顺，这阵子感觉额度掉得比印象里快，或者某个中转站报价单上的数字跟记忆对不上，于是开始怀疑是不是官方涨价了、订阅额度缩水了。先说结论方向：这件事没法用一句「涨了」或「没涨」回答，因为大家嘴里的「价格」其实是三件不同的事，混在一起比永远比不出结果。
这篇给你一套自己核对的办法：先分清你问的是官方订阅额度、官方按量 Token 单价，还是中转站报价；再按顺序去站内对应页面拿当时的数字；最后判断变化落在哪一层，以及要不要改用法的。全程不依赖任何写死的数字，因为那些东西本来就会变。
先把三个「价格」分开，别混着问
「Codex 涨价了吗」这个问题之所以容易吵起来，是因为提问的人各自在看不同的东西。有人看的是订阅套餐里一个月能用多少，有人看的是 API 每百万 Token 多少钱，还有人看的是中转站报价单上那个倍率。这三层的调整节奏完全不同，跨层比较没有意义。
| 层级 | 你看到的数字是什么 | 谁在调它 |
|---|---|---|
| 官方订阅额度 | 套餐内的用量上限、重置周期、限速口径 | 官方，跟着套餐档位走 |
| 官方按量 Token 价 | 输入、输出、缓存命中各自的单价 | 官方，按模型和地区折算 |
| 中转站报价 | 倍率、分组、计价项、最低充值 | 各站点自己，跟着上游成本走 |
- 订阅额度是套餐内的用量上限，跟按量 Token 单价不是一回事，涨价可能只发生在其中一层
- 中转站报价是第三层，它跟着上游成本走，上游没动它也可能单独调，反之亦然
- 判断顺序永远是：先确认你问的是哪一层，再去对应页面拿当时的数字
- 拿两层的数字互相对照，得出的结论基本都是错的，这一点先记住
官方这一层怎么自己核
确认自己关心的是官方这一层之后，动作其实很简单：别用印象里的旧数字，直接去站内对应页面看当前的。订阅相关看编程套餐目录里 Codex 各档位的额度口径；按量相关看官方 API 价格页的模型单价。两个页面回答的是两个问题，别串着看。
- 先定位你问的是订阅还是按量如果你是包月用 Codex，关心的是额度够不够；如果你是按 Token 结算，关心的是单价。想清楚这一点再往下走，否则后面的对比全白做。
- 订阅侧看额度口径到编程套餐目录看 Codex 各档位当前的额度上限、重置方式和限速说明，注意口径是按次、按 Token 还是按小时，变了口径比变了数字更影响你。
- 按量侧看单价口径到官方 API 价格页看模型单价，重点区分输入、输出和缓存命中三种口径，缓存命中的单价通常和普通输入不是一回事。
- 按地区核对官方价是按地区折算的，到官方订阅地区价页面按你实际开卡的区核对，不同区之间的差异不小，拿别人的截图对不上很正常。
还有一种常见误判：官方其实没动，只是你的用量结构变了。上下文开得更大、重复请求更多、同一段代码来回问，这些都会让你感觉「额度掉得更快」，但去页面一看数字根本没变。所以核对的顺序是先看页面，再看自己的调用日志。
中转站这一层怎么核
如果你用的是中转站，那价格变化多半发生在这一层，而且它跟官方不一定同步。上游成本没动，站点也可能因为分组调整、限速策略或者运营需要单独改报价。所以核这一层的重点不是「官方涨没涨」，而是「这家站点最近有没有发过调价或分组调整的公告」。
- 到中转站目录和价格变动追踪页看近期有没有站点发过调价或分组调整的公告，公告比报价单本身更能说明意图
- 报价单上的倍率、分组、计价项要看列名含义，别只看一个总价，口径不同数字不可直接比
- 拿 Token 单价换算工具把「每百万 Token」和「每千 Token」折算成同一个单位再比，这一步能挡掉大半误判
- 同一家站点不同分组的价格可能不一样，先确认你实际走的是哪个分组
- 如果公告里写的是限速或分组调整而不是调价，那它回答的不是同一个问题，处理方式也不同
核对的时候顺带看一眼站点的可信度信息，比如计费口径是否透明、有没有明确的公告渠道。价格这件事上，说不清计价项的站点，比价格略高的站点更值得警惕，因为后者至少你知道自己付了多少。
确认变了以后，先动用法再动预算
确认价格或额度口径确实变了之后，第一反应不应该是马上换供应商，而是先看自己的用法有没有可压缩的空间。很多所谓的涨价，其实是用法问题被价格变化暴露了出来。按下面的顺序排查，成本最低的动作放前面。
- 先查是不是「假涨价」翻自己的调用记录，看是不是上下文开太大、重复请求变多、同一段代码反复贴。这类问题改配置就能解决，不用动预算。
- 再改调用方式单价确实上调时，优先缩短上下文、把简单任务切到更小的模型、能批处理就别逐条发。这些动作不改供应商也能降下来。
- 然后横向比同档位如果只是某一家的报价变了，到中转站目录和价格变动追踪页把同档位的几家拉出来比一轮，注意比的是折算后的同一单位。
- 最后才考虑迁移或调整预算前面几步都做完还是压力大，再决定是留下、换站点还是升档位。顺序反了的话，你会为本来能省下来的部分多付钱。
养一个能看出「脉络」的记录习惯
你真正想要的其实不是「现在多少钱」，而是「它是怎么变过来的」。这个脉络靠临时搜索是拼不出来的，得靠自己留痕。做法不复杂，但要坚持：每次充值或发现调价，花一分钟记一行。
- 记什么
- 当时的档位或分组、单价口径（按什么单位算）、来源是哪个页面，三样够了
- 什么时候记
- 每次充值、每次看到站点公告、每次自己改了模型或分组的时候
- 怎么用
- 隔一段时间回站内价格追踪页对一次，把记录和页面放一起看，才知道是短期波动还是口径真改了
- 公告怎么读
- 先分清是涨价、限速还是分组调整，三种情况的处理方式不一样，别一看到「调整」就当成涨价
价格变了不可怕，可怕的是你不知道它是哪一层变的、从什么时候开始变的。下一步先确认你自己关心的是订阅额度、官方按量价还是中转站报价，然后到站内对应页面拿当时的数字对一遍，比在群里问「涨了吗」有用得多。→
常见问题
Codex 订阅额度最近是不是变少了？
额度口径有没有调整，得看你订阅的那一档当前的官方说明，去站内编程套餐目录对应档位页对比你开通时的口径。更要先排除自身原因：上下文越开越大、重复请求、挂后台空跑，都会让额度「看起来」掉得更快，先查用量再怀疑官方。
Token 单价涨了，是不是必须换中转站？
不一定。先区分是官方按量价变了还是某家站点自己调价：前者所有渠道都会跟着动，换站没用；后者才是换的理由。而且换站之前，先试缩短上下文、切更便宜的模型档、减少无效重试，很多时候省下来的比换站多。
怎么知道一个站点报的价是不是「涨过」？
靠你自己留记录最稳：每次下单记下当时的档位、倍率口径和来源页面，隔段时间回站内价格变动追踪页对一次。没有历史记录时，只能横向比同期几家同档位的报价，再结合报价单的计价项口径判断，别拿不同口径的数字直接比。
