codex每周额度多少美元

很多人拿到 Codex 的每周额度，只看到一堆百分比或点数，却不知道它到底等于多少美元的调用量，选型时没法跟按量计费的 API 放在一起比。这篇不讲死数字，只讲折算该拿哪几个量、按什么顺序算、哪些情况下这个折算会失真，以及算完之后怎么落到选套餐的动作上。

拿到 Codex 的每周额度时，多数人看到的只是一串百分比或点数，没法直接跟按量计费的 API 放一起比。要判断订阅值不值，你得先把这份额度翻译成一个统一的单位——美元等值的调用量，再拿它跟月费做除法。这篇只讲折算链路：该采集哪几个量、按什么顺序算、哪些前提会让结果失真，以及算完之后怎么落到选套餐的动作上。

先说一个前提：折算结果永远是估算。它依赖你当时的单价、你任务的实际输入输出比、以及你真正跑掉的量。所以下面的步骤给的是算法骨架，具体数字一律到站内价格页面核对当期值，而不是记一个死数。

先分清「额度」的三种计量口径

动手折算前，第一件事是确认你的额度到底按哪种口径发。按请求次数、按点数积分、按 token 上限，这三种的折算方式完全不同，套错一步后面全错。

按 token 上限

最接近美元换算的一类，直接拿 token 数乘当期单价即可，误差主要来自输入输出比

按点数或积分

需要先用你自己历史任务的单次消耗，反推出一个「一点约等于多少 token」的经验值，再进下一步

按请求次数

最不适合折成美元，长短任务被一视同仁，只能先用平均单次 token 消耗做粗略估

• 先看订阅页与额度页说明，确认计量单位与重置周期，窗口长度不统一就直接折算会对不上
• 同一账号在不同档位、不同客户端下口径可能不同，别拿 A 档的换算比例去套 B 档
• 把观察到的额度、周期、单位记下来，后面每一步都建立在这个记录上

折算成美元的四个步骤

下面是一套可复用的顺序，每一步都有明确的产出物，做完一步再进下一步，中间不要跳。

1. Step 1 统一成 token 数把额度记录成「一个周期内可用多少 token」。是 token 就直接抄；是点数就除以你自己反推的点数到 token 比例；是次数就乘以你历史任务的单次平均 token 消耗。验证方法：拿这个数字去解释你上周实际跑掉的量，量级对不上就说明比例估歪了。
2. Step 2 取当期单价到站内价格页面核对官方按量计费的当期数字，输入和输出分开取，别用记忆里的旧值。产出物是一张两列小表：输入单价、输出单价。
3. Step 3 按真实输入输出比加权统计你最近一批任务的输入 token 与输出 token 比例，用它把两个单价合成一个加权单价。代码类任务的输出占比通常高于对话类，默认一比一会算出偏低或偏高的结果。
4. Step 4 得到美元等值再除月费token 数乘加权单价，得到这个周期的美元等值；再拿订阅月费除以它，得到每付一份钱拿到多少等值调用量。产出物是一个可以横向对比的比值。

什么情况下这套折算不适用

这套算法在「用量接近额度上限、口径统一、汇率和折扣简单」时比较准。以下几种情况会让结果失真，遇到时别硬套。

• 额度按请求次数封顶：长任务短任务同等计数，折算出的美元值会系统性偏高或偏低，只能当上限看
• 实际消耗远低于额度上限：算出来的是「潜在价值」，不是你真实拿到的价值，应改用实际用量重算
• 跨区订阅、外币结算、渠道折扣：实际付出与官方标价不一致，先把所有数字统一到同一个支付口径再比
• 额度有分类限制（比如只覆盖某类模型或某类任务）：不能简单乘总单价，要按受限部分单独折算

如果你的情况命中其中两条以上，建议先别下结论，改用「实际用量折算法」：只统计真正跑掉的 token，乘当期单价，跟月费比。这个数更保守，但更接近你真实的账面。

算完之后怎么用它做选型

折算出来的数字本身不是结论，结论来自它和按量方案的横向对照。把两种方式放进同一张表，比较的是同一个任务集合下的花费，而不是两个不同场景。

判断标准只有一条：以你真实跑掉的量为分子，以你实际付出为分母，比值高的一边胜出。如果你的账算出来两边差不多，那就优先选可随时停、可随时切的那一边，避免被周期绑住。