今天的 Codex 周额度值多少？

它不是说你的账户里有 $1,884。

我们的做法是：先看一次标准任务实际消耗了多少 Codex 周额度，再把这次任务的模型用量按照公开 API 价格折算成成本，最后按完整 100% 周额度反推一个整周估值。

所以 $1,884 表示的是：按照这套测试条件和消耗关系，一整周 Codex 额度大约相当于 $1,884 的同等 API 用量。

它不是订阅价格、账户余额、退款金额，也不保证一定能完成多少真实工作。

先计算周额度已用比例的差值。已用比例从 40.0% 变成 40.5%，消耗的是 0.5 个百分点，也就是完整额度的 0.005。这里不能直接把 0.5 当作完整额度的比例，也不能计算成相对于 40.0% 的增长率。

然后，将每种 Token 的数量乘以适用的每百万 Token 价格，再相加。计价规则区分非缓存输入、缓存输入和输出时，记录也必须分开。如果输入总量已经包含缓存输入，需要先扣除缓存部分，再计算非缓存输入费用，避免同一批 Token 被重复计价。

最后，用 API 折算成本除以消耗的完整周额度比例。单独收费的工具需要说明是否纳入计算；如果某个模型或用量类别没有可比的公开 API 价格，应保留为无法估算，而不是悄悄套用其他模型的价格。

比较模型时，只换模型，其他条件尽量保持一致。

包括任务、套餐、推理等级、仓库版本、起始上下文、启用工具和运行方式。这就是“同一个任务，同一套设置，只换模型”的前提。

测试需要重复运行，并保留各次观测以及失败、排除的原因。缓存与非缓存运行应有区分，不能无说明地混合。

比较 Plus、Pro 5x 和 Pro 20x 时，需要固定模型、任务、推理等级和其他测试条件，只改变套餐。

官方倍率和实测倍率是两个不同概念：前者来自 OpenAI 公布的套餐关系，后者来自我们在统一测试条件下得到的测量结果。实测倍率需要明确参照套餐，不能仅凭套餐名称得出结论。

7 天对比使用的是今天和恰好 7 个自然日前的数据。30 天对比使用的是今天和恰好 30 个自然日前的数据。这不是过去 7 天或 30 天的平均值。这里的“今天”指最新记录日期；包含首尾两端时，完整的 7 天区间有 8 个每日数据点，30 天区间有 31 个。

变化金额等于今天的估值减去比较日期的估值；变化百分比等于这个差额除以比较日期的估值，再乘以 100。首页顶部使用 Pro 20x 的 30 天变化，与图表默认视图使用同一组数据。切换图表套餐或时间范围，只更新曲线和下方摘要，不改变首页顶部的 30 天变化。套餐表则分别比较各套餐自己的七日前数据。

所选区间期末高于期初时，曲线显示绿色；低于期初显示红色；相同则为中性色。平滑连线经过原始数据点，但连线中间不是新增的实测数据。纵轴会根据所选数据调整，并保留边距与最小跨度，因此判断变化时，应同时看坐标数值和金额差，不能只看曲线倾斜程度。

任务长度、上下文增长、模型、推理设置、缓存命中率以及额度读数精度，都可能影响一次测试中 Token 与周额度消耗之间的关系。读数差值很小时，少量误差放大到整周后，也会明显影响估值。

我们只比较同一个周额度周期里的有效数据。

如果中间发生额度重置，新的周期会从重置后重新计算，不会把重置前后的读数直接连在一起比较。

某一天没有可靠的实测数据，图表就会留空，不会用估算值补齐。

如果公开 API 价格发生变化，新的测量会按照当时生效的价格进行折算；历史结果则保留原来的价格口径。如果提供按新价格重新计算的历史数据，会明确标注为：

按当前 API 价格重新折算

因此，美元估值发生变化时，需要同时看额度消耗和 API 价格：估值变化不一定代表 Codex 周额度本身发生了变化。

页面显示的更新时间，以最近一次完成的实测为准。

要核对一条结果，最重要的是能看清：

• 什么时候测的、测的是哪个套餐；
• 用了什么模型、推理等级和标准任务；
• 任务前后分别用了多少周额度；
• 这次任务实际用了多少 Token；
• 按什么 API 价格进行折算；
• 最后这个周额度估值是怎么算出来的。