codex 免费版有多少额度

很多人开了 ChatGPT Plus，以为 Codex 的额度是「无限跟着账号走」，结果写着写着提示用不了，又不知道是免费额度用光了还是周额度没刷新。这篇不背数字，只讲额度从哪来、按什么周期回血、用完之前该看哪几个页面，以及怎么判断自己是不是被额度卡住，而不是网络或权限出问题。

很多人开了 ChatGPT Plus，默认以为 Codex 的额度是「无限跟着账号走」，结果写着写着提示用不了了，既不知道是免费额度用光了，也不知道是不是周额度还没回血。额度这件事拆开看其实就三块：免费试用量、订阅折算的周配额、用完之后的补充路径。这篇不背任何数字，只讲清额度从哪来、按什么节奏回、用完之前该看哪几个页面，以及怎么判断自己是被额度卡住，而不是网络或权限出了岔子。

先把预期放正：所有具体数量都会随官方口径调整，写死在文章里的数字很快就过期。正确做法是把它当成一个「查当时口径」的动作——每次对不上账，就回到站内资料页核一遍当期说明，再回到自己的用量记录对一遍，两边对上，你才知道自己到底卡在哪一层。

先分清「免费版」在 Codex 这儿指什么

Codex 的入口不止一个：网页端、编辑器里的插件、命令行工具，各自挂的账号体系可能并不完全相同。先把「你现在用的是哪一个入口」确认下来，否则你在网页看到还剩一点，命令行却直接拒绝，会误以为是额度凭空消失了。不同入口读的可能是同一份配额，也可能各算各的，这个必须自己实测一次。

• 账号自带的那点试用量：一般只够跑几个小任务，用来验证通路、跑通流程，不适合当日常主力
• 订阅权益折算出来的配额：跟着订阅档位走，按周期回血，是 Plus 用户实际能用的主要部分
• 第三方中转或自建 key 调用：额度规则完全跟着那家服务商走，跟你的账号订阅没关系，本文的账号侧逻辑对它不适用

什么情况下这套分法不适用：如果你走的是团队席位、教育账号或者换区订阅，权益折算方式往往和中途开卡的个人 Plus 不一样，这种时候最省事的办法是到站内对应说明页对一遍当期口径，而不是拿别人的经验套自己。

周额度和免费额度是两套东西，别混着算

「免费额度」更接近一次性或短周期的试用，用完就没了；「周额度」是按周期回血的配额，扣减顺序和恢复方式都不一样。很多人对账对不上，就是因为把两套东西加在一起算，结果怎么算都是错的。判断自己卡在哪一套，最直接的是看提示文案：是「达到上限」还是「额度不足」，两种措辞通常指向不同的池子。

Plus 档在 Codex 上的编程权益到底怎么折算，是按量算还是按次数算，站内资料页有当期口径说明，别凭印象。注意单位：有些入口显示的是剩余百分比，有些显示的是剩余次数，换算之前先确认单位，不然你会得出完全相反的结论。具体数值请到 /coding-plans/openai-codex-product-subscription-plus 核对当时的数字。

刷新周期怎么判断，而不是靠猜

多数周额度是按固定周期滚动回血的，不一定是自然周，更不一定是每月一号。听别人说「周一刷新」就去卡时间，很容易白等。想拿到属于你自己的周期，只有一个笨办法最可靠：额度见底那天记一笔时间，下一次确认能用的时间也记一笔，两次一减，重复两三次，你的实际周期就出来了。

1. 记录见底时刻额度用尽的那一分钟记下来，最好连提示文案一起截图，方便后面区分是哪个池子见底。
2. 记录恢复时刻下次确认能正常跑任务时再记一笔，别只看界面数字，真跑一个最小任务验证。
3. 两次相减重复两到三次，取一个稳定区间，这就是你账号的实际回血周期，站内 /resets 里的记录可以对上。
4. 存成一个备注把周期写进自己的备忘录，下次规划重活时直接按这个节奏排，不用再猜。

如果同一个账号在不同设备上显示的剩余量不一致，先退出重登，再看是不是本地缓存的旧数字。还有一种情况会让周期判断彻底失效：账号被风控、订阅中断、或者换区，这时候刷新节奏会变，盯周期没有意义，先解决账号状态再看额度。

自己核对额度的四步动作

与其到处问「我这样正常吗」，不如固定一套核对动作。多账号用户尤其要注意第一步，很多「额度不对」的报案，最后查出来是登错了账号，或者切到了另一个浏览器配置里。

1. 确认账号和入口看清当前登录的是哪个账号、走的是网页还是插件或命令行，多账号用户最容易在这里搞错。
2. 截取用量入口在客户端或网页里找到用量展示位置，截图存好，后面和记录对账时用得上。
3. 核对当期口径到 /coding-plans/openai-codex-product-subscription-plus 核对当期折算单位，确认它标的是量还是次数。
4. 记一行消耗日志把「任务类型—大致耗时—剩余额度变化」记成一行，连续记三次，你就知道哪类任务最吃额度。

这套动作的价值在于可复现：下次再遇到「用不了」，你能在三分钟内分清是额度问题、入口问题还是服务问题，而不用重新从头猜一遍。什么情况下不必这么麻烦：如果你只偶尔用一次，记日志的成本高于收益，直接看提示文案就够了。

额度不够用时的几条补充路径

额度不够时，第一反应通常是「加钱提档」，但这未必是最划算的一条路。先判断瓶颈到底在哪：是整周总量不够，还是单次任务太长被拦，抑或只是你把简单任务跑得太啰嗦。三者对应的解法完全不同。

提档

从 Plus 往更高档位走，额度随档位递增，先到 /coding-plans 把各档折算口径对一遍再决定，别只看宣传语。

换入口

官方 API 按量付费是另一套账，适合偶发的大任务，不适合全天挂着跑，账期和预算逻辑都不一样。

减消耗

把大任务拆小、少让模型反复读整份代码库、上下文控制在必要范围，往往比换套餐见效更快。

换时段

如果服务侧高峰波动明显，把重活挪到相对空闲的时段，同样能减少失败重试带来的额外消耗。

不适用的情况要写清楚：如果瓶颈是单次请求的上下文长度，而不是整周总量，那加额度根本解决不了，得改任务切分方式；如果你的任务是自动化批量调用，那 API 按量付费和订阅配额是两种完全不同的计费逻辑，硬换算成「哪个更划算」意义不大，得按自己的调用形态选。

额度没到顶却报错，先排除这几种

「用不了」不一定是额度问题，但大家习惯第一时间怪额度。按固定顺序排查，能省掉大量来回试错。建议从服务侧开始，因为它的验证成本最低。

• 服务侧波动：先看 /ai-status 和 /codex-radar 是不是大面积异常，别急着归因到自己的账号
• 权限或地区问题：换区订阅、共享账号常见这类表现，特征是所有任务都失败，而不是大任务才失败
• 任务本身超限：单次请求太长、附带的文件太多、工具循环调用，这类会被单独拦下，跟总量无关
• 入口配置问题：插件没登录、命令行 token 过期，表现也是「突然用不了」，但用量页其实没怎么动

排查顺序建议固定成：先看服务状态，再换一个最小任务试跑，接着看用量页有没有变化，最后才怀疑额度。这个顺序的逻辑是成本从低到高，先用一次小任务就能把一大半可能性排掉。

把额度当成预算来管，而不是救火

真正少踩坑的人，不是额度多，而是把额度当预算在排。给一周的额度心里定个自用上限，比如先划出「重活留给哪两天」，避免周初就把额度烧在反复调试上，到了关键任务反而没得用。这个习惯不需要工具，记在备忘录里就行。

团队共用账号时尤其要分开记：谁用、干什么、大概消耗多少，否则到了对账的时候根本说不清。分摊不清的后果不是钱的问题，而是下次选方案时你没有任何依据，只能继续凭感觉。这份习惯同样适用于按量付费的 API 场景，账对得清，后面换方案才有数据支撑。

额度管理的核心不是记住数字，而是记住你上一次是怎么用完的。