Codex 额度怎么控制：记住 10%、12%、15% 三个数字就够了

最近使用 Codex 比较频繁，我一直想弄清楚一个问题：

5 小时额度和一周额度之间，究竟是什么关系？

如果只看 Codex 界面，会同时看到两组数字：

• 5 小时剩余额度；
• 一周剩余额度。

两套限制同时存在，很容易把事情想复杂。

实际上，我真正需要的并不是精确计算每一次请求消耗了多少，而是找到一套足够简单的判断规则。这样以后打开 Codex，看一眼界面中的数字，就知道自己这一轮是不是用得太快、今天是不是已经差不多该停了。

2026 年 8 月 26 日，我正好在第一周的第一个 5 小时周期中连续截了三张图，可以拿来做一次实际估算。

第一次记录：5 小时用了 31%，周额度用了 5%

第一张截图中：

• 5 小时剩余：69%
• 一周剩余：95%

也就是：

• 5 小时额度已经使用 31%
• 一周额度已经使用 5%

如果按照这个消耗比例推算，把整个 5 小时额度全部使用完，大约会消耗：

5 ÷ 31 × 100% ≈ 16.1%

也就是大约 16% 的周额度。

第二次记录：结果已经接近 15%

第二张截图中：

• 5 小时剩余：53%
• 一周剩余：93%

换算成已经使用：

• 5 小时使用 47%
• 一周使用 7%

继续按照相同比例推算：

7 ÷ 47 × 100% ≈ 14.9%

这一次得到的结果已经非常接近：

一个完整 5 小时额度 ≈ 15% 周额度。

第三次记录：再次验证约 15%

第三张截图已经接近这个 5 小时周期的尾声：

• 5 小时剩余：14%
• 一周剩余：87%

也就是已经使用：

• 5 小时额度 86%
• 一周额度 13%

再次计算：

13 ÷ 86 × 100% ≈ 15.1%

三个时间点分别得到：

• 约 16.1%
• 约 14.9%
• 约 15.1%

虽然 Codex 界面中的百分比只显示整数，本身就存在一定的取整误差，但三个结果已经非常接近。

所以没有必要继续追求小数点后的精度。

我后续直接采用：

一个完整的 5 小时额度，大约相当于一周总额度的 15%。

为什么统一用「周额度」来判断

一开始我也考虑过类似这样的说法：

“每天尽量使用一个 5 小时额度的多少百分比。”

后来发现这种表达反而增加了理解成本。

因为这样相当于：

先看 5 小时额度，再把它换算成一天，然后还要考虑一周额度。

没有必要。

Codex 界面本来就直接显示一周剩余额度，而且这个数字肉眼就可以看到。

所以后续最简单的方法就是：

统一把一周总额度当成 100% 的基准。

无论判断一个 5 小时周期，还是判断一天的使用量，都只看这一周额度减少了多少。

这样就不用在不同单位之间反复换算。

最后只需要记住三个数字

经过这次实际记录以后，我准备把 Codex 的使用规则彻底简化成：

5 小时看 10%，一天看 12%，15% 是 5 小时极限。

这三个数字分别代表不同的含义。

5 小时：正常目标约 10%

根据实测，一个完整的 5 小时额度大约对应一周额度的 15%。

但正常使用显然不应该每一次都冲到极限。

所以我给自己的正常目标是：

一个 5 小时周期，尽量把周额度消耗控制在 10% 左右。

例如开始这一轮工作时，一周额度还剩 90%。

使用一段时间以后变成 80%。

那么这一轮就已经消耗了：

90% – 80% = 10%

这时候已经基本达到正常目标。

后面如果还有任务，可以根据重要程度决定是否继续，而不是看到 5 小时额度尚未归零，就继续把它全部用完。

一天：平均目标约 12%

一周总额度是 100%。

如果简单平均到 7 天：

100% ÷ 7 ≈ 14.3%

也就是说，如果每天平均消耗 14.3%，理论上第七天就会把整个周额度基本用完。

这样的安排没有任何缓冲空间。

所以我准备把每天的正常目标控制在：

周额度的 12% 左右。

一周就是：

12% × 7 = 84%

正常情况下，还能够留下大约 16% 的周额度作为机动空间。

这部分额度可以应对某一天突然出现的：

• 较大的代码修改；
• 集中的翻译任务；
• 验证失败后的重新处理；
• 临时需要 Codex 完成的其他工作。

因此，12% 并不是每天必须精确达到的数字。

有一天只使用 8%，完全没有问题。

某一天因为任务比较多使用了 14%，也不意味着立即超限。

真正需要关注的是：

一周内每天的平均消耗，不要长期明显超过 12%。

15%：5 小时周期的实际极限附近

最后一个数字是 15%。

这不是正常使用目标，而是一个警戒值。

从这次三张截图计算来看：

完整消耗一个 5 小时额度，大约会消耗周额度的 15%。

所以当我发现：

这一轮开始时周额度是 90%，现在已经降到 75% 左右，

即使不看左边的 5 小时剩余百分比，也应该知道：

这个 5 小时周期基本已经接近极限了。

这时候最好不要再开启新的大型任务。

后续实际上连计算器都不需要

这也是我这次最想留下来的使用习惯。

以后不需要每次重新计算：

“5 小时剩余 37%，折合成周额度是多少？”

只需要记住：

5 小时看 10%。
一天看 12%。
15% 是 5 小时极限。

然后直接观察 Codex 界面中的一周剩余额度。

例如一个 5 小时周期开始时：

一周剩余 87%。

使用一段时间以后：

一周剩余 77%。

直接做一个非常简单的减法：

87 – 77 = 10

说明这一轮已经达到正常的 5 小时使用目标。

如果当天开始时是一周剩余 87%，到当天结束时变成 75%：

87 – 75 = 12

说明当天的使用量正好处于我计划中的平均水平。

如果一个 5 小时周期内直接从 87% 降到 72%：

87 – 72 = 15

那就已经接近这次实际测出来的 5 小时极限。

这样判断比盯着两套额度来回换算简单得多。

这三个数字解决的是「使用节奏」，不是精确计费

需要说明的是，这次计算来源于我自己的实际 Codex 使用记录。

截图期间使用的任务和模型设置并不一定完全一致，而且 Codex 界面只显示整数百分比，因此没有必要把：

15%

理解成一个绝对精确、永远固定的官方换算比例。

它更适合作为我的实际使用经验。

我真正需要解决的问题也不是：

“每一个 Codex 请求究竟消耗周额度的万分之几？”

而是：

我现在使用得是不是太快？

对于这个目的，10%、12%、15% 已经足够用了。

最后总结

以后再看 Codex 剩余额度，我希望自己不要重新陷入复杂计算。

只记一句：

5 小时看 10%，一天看 12%，15% 是 5 小时极限。

其中：

• 10%：一个 5 小时周期的正常目标；
• 12%：一天的平均使用目标；
• 15%：一个完整 5 小时额度大约对应的周额度，也是需要避免经常触碰的极限附近。

所有数字都统一以：

一周额度 = 100%

作为基准。

这样以后只看 Codex 界面里的一周剩余额度，再做一次简单的减法，就可以大致知道当前使用节奏是否正常。

对我来说，这比建立一套复杂的额度计算公式更有意义。

因为真正能够长期执行的规则，最好是打开界面以后几秒钟就能判断出来的。