codex免费额度有多少token

很多人搜「Codex 免费额度多少 token」，其实问的是两件事：一是我现在不花钱能用多少，二是这个额度多久回血一次。麻烦在于官方给的是额度单位和使用窗口，不是直接标一个 token 数，加上网页版和 CLI 走的口径不完全一样，网上流传的数字经常过期。这篇把判断顺序理出来：先分清你用的是哪个入口，再去站内对应页面看当期规则，最后教你怎么用一次真实任务倒推自己的 token 消耗，从而知道额度大概能撑多久。

很多人搜「Codex 免费额度多少 token」，实际想问两件事：现在不花钱能用多少，以及这个额度多久回血一次。麻烦在于官方给的是额度单位和使用窗口，不是直接标一个 token 数，网页版和 CLI 的口径也不完全一样，网上流传的数字经常已经过期。

这篇只做一件事：把判断顺序理清楚。先分清你用的是哪个入口，再去站内对应页面看当期规则，最后用一个真实任务倒推自己的 token 消耗，算出额度大概能撑多久。全程不给死数字，因为写下来的数字第二天就可能不对。

先分清：你问的是哪个 Codex

Codex 至少有三个接触面：网页或对话入口里的编程能力、在本地跑的命令行工具、以及走 API key 的按量调用。这三种「免费」的含义完全不同，混在一起算一定会得出错误结论。

网页/对话入口

通常挂在订阅体系的额度之下，免费层给的是有限使用窗口，不是写死的 token 池

命令行 CLI

多数情况同样计入订阅额度，本地执行但消耗走账号，别以为本地跑就不算

API key 按量调用

没有「免费额度」这个概念，只有新用户的试用赠送，之后全按用量出账单

判断自己属于哪一类，看用量页面最直接：显示「剩余额度 / 下次重置时间」的是订阅式额度，显示「已用金额」的是按量账单，两者不能互相换算。如果你是通过第三方中转站接入 Codex 类模型，规则由中转站自己定，跟官方免费额度无关，得去看那家的说明页。

额度不是按 token 报的，那怎么估

官方给的额度单位一般是「某个窗口内可消耗的量」，具体用什么计量，去站内页面看当期口径，别靠记忆或别人的截图。想换成 token 数，只有一条路：自己实测。

1. 挑一个代表性任务比如让 CLI 读一个中等规模的仓库、改一处逻辑，别用一问一答的闲聊任务来估
2. 记录前后差值跑之前看一眼用量页，跑完再看一次，差值就是这个任务的真实 token 成本
3. 做三到五个不同类型改 bug、加功能、写测试各来一遍，取平均值，得到你自己的私人换算表
4. 之后用平均值反推看到剩余额度，除以平均单任务消耗，就是大概还能跑几轮的粗略答案

刷新周期与自查顺序

免费额度的重置按时间窗口走，窗口多长、从哪个时点开始算，官方调整过，所以别背周期。直接去站内额度重置追踪和套餐页看当期说明，才是稳的做法。

还有一个容易被忽略的点：额度到期作废、一般不结转。你在窗口末期才开始用，之前没用掉的不会累积到下个周期，别把没用的额度当存款。另外先确认同一账号下对话额度和编程额度是不是同一池子，各家不同，不然容易以为还有余量结果中途卡住。

免费额度怎么用在刀刃上

免费额度有限，用在哪很关键。一条原则：留给需要来回改的活，把一次成型的活放到别处做。迭代最烧次数，生成样板代码、写文档这种一锤子买卖不值得占用额度。

• 用 CLI 时只让它读需要改的那几个文件，别整仓库喂进去，上下文长度直接决定消耗
• 先跑小样判断方向对不对，确认了再上全量任务，避免一次错误的大任务打光整周期额度
• 把反复试错的重构放前面做，顺手的一次性任务往后排
• 每次大任务前记一下用量页数字，事后能对账，也能持续修正你的平均消耗估算

什么情况下这套省法不适用：如果你一天要跑几十轮重构，免费额度基本撑不住，这时候该考虑的是套餐档位，而不是继续抠用量。省额度只在轻度使用时有意义。