ChatGPT Plus、Pro 5x、Pro 20x 到底有多少额度?聊聊 Codex 那个让人看不懂的“周限额”

ChatGPT Plus、Pro 5x、Pro 20x 到底有多少额度?聊聊 Codex 那个让人看不懂的"周限额"

大家好,今天想聊一个最近重度使用 ChatGPT 和 Codex 的朋友非常关心的问题:

我一个月交这么多钱,到底能用多少?

尤其是最近几个套餐放在一起之后,这件事情越来越让人看不懂。

Plus 有额度,Pro 又分出了不同档位,有人说 Pro 是 Plus 的 5 倍,有人说是 20 倍;打开 Codex 的 /status,又会看到 5 小时限制和 Weekly limit,也就是周限制。

社区里甚至开始用美元来衡量额度:

"Plus 一周大概 140 刀。"

"Pro 5x 大概就是 700 刀。"

"Pro 20x 相当于 2800 刀。"

还有人直接说:"我一天能烧掉 200 刀。"

这些数字到底是什么意思?

难道买一个 ChatGPT Pro,OpenAI 真的每周往你的账户里面送几千美元 API Credit?

当然不是。

今天我们就把这件事情从头到尾捋一遍。

我会把 OpenAI 官方现在能够确认的信息,和社区用户实际使用 Codex 得出来的经验放到一起。最后再聊聊一个普通程序员到底应该怎么选 Plus、Pro 5x 和 Pro 20x。


一、先说结论:社区说的"140 刀周额度"不是官方给你的 140 美元

这是最容易产生误解的地方。

社区里经常有人说:

Plus 每周大概 140 美元额度。

Pro 5x 大概 700 美元。

Pro 20x 大概 2800 美元。

看到这里,很多人的第一反应可能是:

那 Pro 20x 也太划算了。

一个月花 200 美元,理论上每周能用 2800 美元,一个月岂不是一万多美元?

如果真是这样,OpenAI 不是亏麻了吗?

问题就在于:这个"美元"并不是你账户里真正存在的美元。

OpenAI 官方对于 Codex 的解释其实非常明确:Codex 的消耗并不是简单按照"你发送了多少条消息"计算的。

真正影响消耗的因素包括模型、任务复杂度、上下文长度、推理强度、任务在哪里运行、使用了哪些工具,以及一个任务到底持续了多久。

所以一个很简单的需求:

"帮我给这个 Java DTO 加两个字段。"

和另一个需求:

"阅读整个项目,分析订单领域,然后按照 DDD 重构支付模块,修改代码、运行测试、修复报错,最后给我提交完整结果。"

虽然在聊天界面上看起来都是"一次请求",实际资源消耗可能完全不是一个量级。

OpenAI 官方也明确提醒,固定消息条数并不是衡量 Codex 剩余额度的可靠方法

所以社区为了方便比较不同套餐,才会想办法把这些使用量折算成一个大家比较容易理解的东西------美元。

于是就出现了所谓:

Plus 约 140 美元每周。

但这个数字应该理解成一种社区估算出来的 API 等价资源价值

而不是 OpenAI 官方承诺:

"购买 Plus,我们每周赠送你 140 美元 API Credit。"

这是两回事。


二、官方真正确认的,是"5x"和"20x"

虽然社区估算出来的具体美元金额不能直接当成官方数据,但是有一个非常重要的信息,现在是 OpenAI 官方明确说明的:

Pro 的不同档位,核心区别之一确实就是使用额度倍数。

按照 OpenAI 目前的官方说明,100 美元档的 Pro 提供大约 Plus 5 倍的使用额度 ,而 200 美元档 Pro 提供大约 Plus 20 倍的使用额度

这就非常有意思了。

假设我们把 Plus 的 Codex 可用资源定义成:

1 个单位。

那么可以非常粗暴地理解:

Plus = 1。

Pro 5x = 5。

Pro 20x = 20。

注意,我这里故意不用"140 美元""700 美元""2800 美元"。

因为使用"单位"其实更加准确。

这样我们再回头看社区里的算法,就容易理解了。

社区有人认为 Plus 每周大约对应 140 美元的 API 等价资源。

那么按照官方确认的倍数关系:

140 × 5 = 700。

140 × 20 = 2800。

于是就有了:

Plus:约 140 美元。

Pro 5x:约 700 美元。

Pro 20x:约 2800 美元。

所以这里面其实混合了两部分信息:

"5 倍和 20 倍"有官方依据。

但是:

"Plus 基准值就是 140 美元"属于社区估算。

把这两个概念区分开,很多争论自然就消失了。


三、为什么你明明只用了几个小时,周额度却掉得特别快?

这可能是 Codex 用户最容易困惑的一件事情。

很多人第一次使用的时候会觉得:

我今天也没问多少东西啊?

怎么 Weekly limit 已经掉了十几个点?

甚至有人一个复杂需求跑了一两个小时,再看 /status,发现周额度已经明显下降。

原因就在于 Codex 已经不是传统意义上的聊天机器人了。

以前我们使用 ChatGPT,比较习惯这种模式:

我问一句。

AI 回一句。

我再问一句。

AI 再回答。

但 Codex 更像一个工程师。

你说:

"帮我重构一下这个模块。"

它可能会自己读取几十个文件。

然后搜索代码。

分析调用关系。

修改文件。

执行 Maven。

发现编译错误。

继续修改。

运行单元测试。

测试失败。

继续分析。

最后再整理结果。

从你的角度看,你只输入了一句话。

但是从计算资源角度看,背后已经发生了大量模型调用和上下文处理。

而且随着项目越来越大,每一次模型调用需要携带的上下文也可能越来越多。

所以 OpenAI 官方特别强调,Codex 的使用量与模型、任务规模、推理强度、上下文以及实际完成的工作量有关。

这也是为什么:

"我今天只问了 20 个问题。"

几乎没有参考价值。

有人 20 个小问题可能只消耗几个百分点。

有人一个大型重构任务可能就烧掉非常明显的一块额度。


四、为什么还有一个"5 小时额度"?

很多第一次打开 Codex /status 的人会发现:

怎么有两个进度?

一个是 5 小时。

一个是 Weekly。

这实际上可以理解成两层限流。

第一层控制的是:

短时间内不要把所有计算资源一次性打满。

第二层控制的是:

整个周期内总共能够使用多少资源。

所以你可能出现一种情况:

周额度还有很多,但是当前 5 小时窗口已经比较紧张。

也可能出现另一种情况:

5 小时窗口看起来恢复了,但是 Weekly limit 已经快见底。

因此,真正重度使用 Codex 的人不能只盯一个数字。

你需要同时看:

短周期额度和周额度。

OpenAI 现在也明确建议用户直接进入 Settings 或 Usage Dashboard 查看具体是哪一项 allowance 已经耗尽;如果在 Codex CLI 中,则可以直接执行 /status

这个 /status,其实是我非常建议程序员养成习惯去看的东西。


五、"5 小时额度大约是周额度的 16%"靠谱吗?

社区里还有一个非常流行的说法:

5 小时额度大约等于周额度的 16%。

然后有人进一步计算:

如果 Plus 周额度折算成 140 美元,那么:

140 × 16% = 22.4 美元。

于是认为 Plus 每个 5 小时窗口大约对应 22 美元资源。

Pro 5x 就是:

112 美元左右。

Pro 20x:

448 美元左右。

这个算法作为社区观察,可以拿来帮助理解。

但是一定要加一句:

这不是一个适合当成官方 SLA 的固定换算公式。

OpenAI 官方真正强调的是动态消耗。

不同模型、不同任务、不同上下文、不同推理等级,实际消耗都可能变化。

所以你不能拿着计算器说:

"我这个 5 小时窗口还有 50%,那我肯定还能再烧 224 美元。"

没有这种保证。

它更适合拿来做什么?

横向比较。

比如你发现 Plus 对自己来说明显不够,而自己的工作量长期比较稳定,那么 Pro 5x 和 Pro 20x 的倍数关系就具有很大的决策价值。

至于具体对应多少美元,不需要算得那么死。


六、现在额度还有一个很大的变化:Credits

以前很多人的理解是:

额度用完了,就等恢复。

比如周额度没了:

那这周 Codex 基本就先歇着。

但现在 OpenAI 正在逐渐把体系变得更加灵活。

官方已经提供 Credits 机制。

简单来说就是:

套餐额度先用。

如果套餐自带额度用完,在支持的账户和功能上,可以继续购买 Credits 使用,而不是必须升级整个套餐或者一直等到下一个周期。

而且现在 Plus 和 Pro 的一些 agentic 功能,包括 Codex、ChatGPT Work、ChatGPT for Excel,在适用情况下会共享相关的 agentic usage allowance 或 credit pool。

这件事情其实非常重要。

因为未来我们选择套餐的时候,逻辑可能会从:

"我要不要为了偶尔超额直接升级?"

逐渐变成:

固定套餐 + 弹性 Credits。

举个例子。

假设你平时 Plus 完全够。

但是每个月上线前有三四天需要疯狂使用 Codex。

以前你可能会觉得:

是不是应该长期买 Pro?

现在另一种思路就是:

平时 Plus。

真正超过 included usage 的时候,再根据账户提供的选项购买 Credits。

反过来,如果你每天都在重度使用 Codex,那一直购买额外 Credits 未必是最划算的方案,这时候更高档位的 Pro 就开始有价值了。


七、还有一个很多人不知道的机制:额度可以提前"重置"

OpenAI 最近还增加了一个非常值得注意的能力。

符合条件的 Plus 和 Pro 个人账户,可以购买一次即时的 weekly reset。

也就是说:

你这周额度还没恢复,但是项目马上要上线,Codex 已经没额度了。

以前只能等。

现在部分账户可以直接购买 reset。

但是这里有一个特别容易理解错的地方。

这个 reset 并不是:

"额外送你一份新的周额度。"

官方的解释更接近:

把你下一周期原本拥有的 allowance 提前拉过来。

而且使用之后,新的周周期会重新计算。

所以它比较像:

"我现在就开启下一周。"

而不是:

"在这一周基础上白送一周。"

这个区别非常重要。


八、那为什么有人说自己的 Pro 20x 一天能跑掉"200 刀"?

回到社区讨论里一个特别有意思的回复。

有人说:

"一天 200 刀,哈哈。"

如果不了解前面的机制,很容易以为:

ChatGPT Pro 每天给他 200 美元余额。

实际上更合理的理解仍然是:

按照 API 或 Credits 等价成本估算,他当天的 AI 计算资源消耗可能达到了那个量级。

这其实一点都不夸张。

尤其是现在 Agent 类产品越来越强之后,一个"请求"背后的工作量已经完全不同了。

一个 Agent 可以:

阅读整个仓库;

搜索代码;

运行 shell;

调用工具;

分析日志;

修改几十个文件;

运行测试;

失败后重新修改;

甚至执行长时间任务。

OpenAI 在面向企业的 Rate Card 中也明确说明,Codex/Work 的消耗可以根据实际 input token、cached input 和 output token 来计费,而且典型任务本身就可能消耗不同数量的 credits。官方给出的说明同样强调,实际成本会随着模型、并发实例、自动化和 Fast mode 等因素发生明显变化。

所以未来判断 AI 工具贵不贵,可能越来越不能只看:

"我今天问了多少句话。"

而应该看:

AI 今天替我干了多少活。


九、Plus 到底适合什么人?

聊完机制,我们回到最实际的问题。

如果我是程序员,到底怎么买?

我的理解是:

如果你只是偶尔使用 Codex,比如:

写一个接口;

补几个单元测试;

分析一个 Bug;

解释一段代码;

写 SQL;

做小范围重构;

那么 Plus 依然是性价比非常高的选择。

OpenAI 对 Codex 的定位里,也曾把 Plus 描述成适合每周进行若干次集中式 coding session 的方案,而更高档位则更适合持续性的专业开发工作。

所以 Plus 的问题从来不是:

"能不能写代码?"

当然能。

真正的问题是:

能不能每天把它当一个全职 AI 工程师使用?

如果你每天工作八小时,其中四五个小时都让 Codex 在大型项目里面不断读取、修改、测试、重构,那么 Plus 很容易开始显得捉襟见肘。


十、Pro 5x 是一个很有意思的中间档

100 美元档 Pro 最大的价值,我认为不是单纯的"比 Plus 多"。

而是它把个人开发者的选择切得更细了。

以前可能只有:

普通用户。

和超级重度用户。

现在中间多了一档:

我确实每天大量使用 AI 编程,但还没重到需要 20x。

按照 OpenAI 官方目前的说法,它提供的是 Plus 大约 5 倍的 usage。

这对于职业程序员其实很有吸引力。

因为很多开发者不是全天让 Codex 跑任务。

可能一天真正高强度使用两三个小时。

这种情况下:

Plus 有点紧。

20x 又明显过剩。

5x 正好卡在中间。


十一、什么人才真正需要 Pro 20x?

Pro 20x 就完全是另外一种使用方式了。

它适合的不是:

"偶尔让 AI 帮我写代码。"

而更像:

把 Codex 当成生产力基础设施。

比如你每天同时维护多个项目。

大量使用 Agent。

经常让 Codex读取大型仓库。

长时间执行重构。

自动跑测试。

分析生产日志。

做 Code Review。

或者你已经形成一种开发习惯:

需求来了之后,第一件事情不是自己打开 IDE 开始写。

而是先把任务交给 Codex,让它先跑第一版。

这种使用方式,20x 才真正开始有价值。

OpenAI 官方对于最高档 Pro 的定位,本质上也是通过更高 usage allowance 服务这种持续高强度场景。


十二、真正聪明的算法不是算"美元",而是算自己的消耗速度

最后我想分享一个我认为比社区"140 美元理论"更加实用的方法。

不要猜。

自己测。

打开 Codex。

执行:

/status

记录:

Weekly limit:100%。

然后按照平时正常的工作方式使用。

不要为了测试故意狂跑任务。

正常写代码就行。

比如连续工作两个小时之后:

Weekly limit:

100% → 92%。

说明消耗:

8%。

那么非常粗略地估算:

2 ÷ 8% ≈ 25 小时。

也就是说:

按照你当前这种工作强度,一整个周额度大约可以支撑 25 小时左右。

这比别人告诉你:

"Plus 一周 140 刀。"

有用得多。

因为那 140 美元是别人的模型。

而这 25 小时:

是你自己的真实工作负载。

如果你一周真正使用 Codex 只有十小时:

Plus 可能完全够。

如果你需要三四十小时:

那就开始考虑 5x。

如果你已经把 Codex 当成全天候工程师,并且同时跑多个复杂任务:

再考虑 20x。

这才是更加合理的购买逻辑。


十三、所以,别再问"ChatGPT 到底给了我多少美元"

聊到这里,其实我们已经可以回答最开始的问题。

ChatGPT Plus、Pro 5x、Pro 20x 到底有多少额度?

答案不是一个简单的美元数字。

我们目前真正能够确定的是:

OpenAI 会按照套餐提供不同等级的 included usage;

Pro 5x 和 Pro 20x 与 Plus 存在明确的倍数关系;

Codex 的消耗并不等于简单的消息数量;

模型、上下文、推理、任务规模、工具调用都会影响实际消耗;

短周期限制和 Weekly limit 需要分别关注;

部分账户在额度用完后还可以通过 Credits 继续使用;

符合条件的个人账户还可能购买即时 weekly reset。

而社区流传的:

Plus 140 美元。

Pro 5x 700 美元。

Pro 20x 2800 美元。

5 小时约占周额度 16%。

这些数字更适合作为:

民间测算模型。

可以参考。

可以用来比较。

但是不要把它当成 OpenAI 对你的合同承诺。


十四、最后聊一个我觉得更重要的问题

其实大家之所以这么关心额度,本质上不是舍不得那几十或者一两百美元。

真正的问题是:

AI 编程已经开始从"辅助工具"变成生产工具了。

以前 GitHub Copilot 一个月十几美元的时候,我们不会天天研究:

"今天还剩多少额度?"

因为它主要是在补全代码。

但现在 Codex 做的事情已经完全不同。

你可以把一个需求交给它。

让它理解项目。

设计方案。

修改代码。

运行命令。

执行测试。

发现问题。

继续修复。

这已经越来越像一个真正的软件工程工作流。

于是我们第一次开始认真计算:

一个 AI 工程师一天到底值多少计算资源?

一个月 20 美元、100 美元、200 美元到底贵不贵?

答案其实不能只看订阅价格。

如果你花 200 美元,一个月只是让 AI 帮你补了几十段代码:

那当然贵。

但如果这 200 美元让你一个月少写几十个小时重复代码,少查十几个小时文档,少花几个晚上定位 Bug,甚至让一个原本需要三天的需求一天完成:

那它可能又非常便宜。

所以我现在看 Plus、Pro 5x 和 Pro 20x,已经越来越不把它们当成传统意义上的"会员套餐"。

它更像:

你每个月准备购买多少 AI 工程能力。

Plus 买的是辅助。

5x 买的是深度协作。

20x 买的则越来越接近:

给自己配一个可以高频调用的 AI 工程师。

至于社区里面说的"140 刀""700 刀""2800 刀",看看就好。

真正应该看的只有三个东西:

你的 /status

你的工作效率。

以及:

AI 到底替你省下了多少时间。

如果一个月 200 美元能换回来二三十个小时。

对于一个职业程序员来说,这笔账其实已经非常容易算了。

而这,可能才是理解 ChatGPT 和 Codex 套餐额度最重要的一件事情。

相关推荐
明月_清风1 小时前
递归算法:从原理到实战,一次讲透
后端·算法·go
用户608186527901 小时前
Avalonia 控件模板实战:从 WPF 迁移自定义 Button 样式的完整指南
后端
明月_清风2 小时前
GPT-6 Astra 与 AGI 的门槛:我们到底在争论什么?
人工智能·后端·openai
jyOverQ2 小时前
RabbitMQ 延迟消息怎么实现?TTL 与死信队列
分布式·后端·rabbitmq·ruby
元界metalite2 小时前
Java通用枚举驱动下拉框-元数据接口与前端契约
后端
Csvn2 小时前
🐍 Day 10: 依赖管理 — 从 requirements.txt 到 pyproject.toml
后端·python
学长毕业设计2 小时前
基于SpringBoot的校园二手物品交易系统(源码+文档+讲解视频)
java·spring boot·后端
Darling噜啦啦2 小时前
从 SSE 到 LLM 流式输出:搞懂前端实时通信的两种姿势
前端·后端·llm
wangfpp2 小时前
原生NodeJS维护Agent Memory实践
后端·agent·全栈