Codex的额度单独购买

很多人用 Codex 写着写着额度就见底了，第一反应是「能不能单独买点额度补上」，不想为了多用几天再升一整档订阅。这篇就按这个场景走：先分清你手里是官方订阅还是中转站的按量通道，再看加购到底加在哪个计费口径上，最后给一份下单前的核对顺序。数字不写死，全部让你去站内对应页面按当时的价格自己量。

用 Codex 写代码写着写着额度见底，是很多人都会遇到的时刻。这时候第一反应通常是「能不能单独买点额度补上」，而不是为了多用几天再升一整档订阅。这个想法本身没错，但能不能实现，取决于你手里走的是官方订阅登录态，还是中转站的按量通道——这两条路的计费口径完全不一样，搞混了容易重复付费。

这篇按这个场景走：先分清你调用时用的是订阅登录态还是 API Key，再看「加购」到底加在哪个计费口径上，最后给一份下单前的核对顺序。所有涉及金额和额度的数字都不写死，你到站内对应页面按当时的价格和换算工具自己量，才不会被别人过时的截图带偏。

先分清：额度能不能单独加购，取决于你走的是哪条路

官方订阅档和按量额度是两套独立口径。订阅买的是固定的额度上限，一般不能把额度拆出来单买，想多用只能整档往上升；按量额度本来就是用多少算多少，不存在「加购」这个概念。所以问「能不能单独买额度」，先得确认你在哪套口径里。

判断方法很直接：看你调用时是走的订阅登录态，还是自己填的 Key。走 Key 的基本都是按量口径。但有一种情况要特别小心——Key 和订阅绑定在同一账号体系里，加购的余额可能被算进同一份额度池，两边互相消耗，这种必须实测一笔小额请求才能确认。

加购之后，钱是按什么算的

按量口径下，账单由三件事决定：计价单位、上下文长度怎么计入、缓存命中是否打折。这三项先对齐，再看总价才有意义。很多人只盯着单价，忽略了长上下文会把每轮的实际消耗推高，最后算出来的月度成本跟预期差很远。

计价单位

按输入输出分开计，还是合并成一项，直接决定你估算的方式

上下文长度

长对话或大文件场景下，同样一次任务消耗的额度会明显高于短请求

缓存命中

部分渠道对重复前缀有折扣，命中与否影响实际单价

余额有效期

充进去的余额是长期有效还是有周期限制，过期规则要提前看清

充值余额本身不会改变模型的调用规则，只改变你还能用多少次。所以「加购省不省钱」这个问题，答案取决于你的请求结构：短请求密集、缓存命中高的场景，加购的性价比明显更好；长上下文连续对话、每次都要重新喂大段材料的场景，加购能续命但很难便宜。

还有一点容易混淆：加购和升级订阅不是一回事。加购是按用付费、理论上没有上限的消耗；升级订阅是买到更高的固定额度上限。用量波动大的适合加购，用量稳定且长期偏高的，往往算下来升档更划算——具体差多少，到站内按量价格页和换算工具过一遍你的真实请求样本，别凭感觉估。

下单前的核对顺序

下面这五步是给「已经决定要加购」的人用的，顺序别乱，尤其别跳过验证环节直接充大额。

1. 确认口径先搞清楚你买的是额度包、余额充值，还是整档订阅升级。三者退款规则和有效期完全不同，买错类型比买贵更麻烦。
2. 量出现有基线用站内接口测速和成本计算器跑一遍你现在的真实请求，得到每千次调用的实际成本，这是后面判断划算不划算的基准。
3. 看清条款余额有没有有效期、能不能退、有没有最低充值门槛，这三条在付款前必须看到明确说明，没写清楚就先别付。
4. 小额验证先充最小可用金额，跑通一次真实任务，确认到账时间、扣费口径、余额显示都对得上，再考虑加大。
5. 分批放量确认无误后按月度用量分次充，不要一次压太多在单一渠道。渠道出问题时，余额越大越被动。

什么时候不该单独加购

加购不是默认答案，下面这几种情况，先停下来算另一笔账可能更合适。

• 用量已经稳定超过某一档订阅的固定上限：这种情况下加购的折算单价通常比整档订阅贵，该算的是升档而不是续余额
• 只是偶尔冲一波高峰：加购确实比升档合适，因为不用承担长期月费，用完就停
• 账号有共享或多人使用：加购余额容易被别人消耗，先确认权限划分和用量可见性，再决定要不要充
• 渠道本身不稳定或有过掉包记录：加购只会放大风险，先到站内可信任度检测页做核验，通过再考虑充值

还有一类情况容易被忽略：你的请求里有大量重复的系统提示或长文档前缀。这种结构如果走的是支持缓存折扣的渠道，实际单价可能比你按原价估算的低不少；反过来，如果渠道不支持或者缓存命中率低，加购的性价比会明显打折。同一笔用量，换个渠道结果可能完全不同，所以先跑样本再下结论。

最后提醒一句：加购解决的是「额度不够用」，不解决「用得不划算」。如果你的实际消耗大头来自超长上下文或者重复调用，先把请求结构优化一轮，往往比直接加购更有效。