用 Codex CLI 写代码，最容易懵的不是报错，而是不知道额度还剩多少：终端里看不到一个明确的「余额」数字，登录状态、订阅档位、用量页各说各话，任务跑到一半才提示受限。这篇不背数字，只教你去哪看、按什么顺序核对，以及看到的口径对不对得上。
用 Codex CLI 写代码，最容易懵的不是报错，而是不知道额度还剩多少。终端里找不到一个明确的「余额」数字，登录状态、订阅档位、用量页各说各话，任务跑到一半才提示受限，回头一查又对不上账。这篇不背数字，只教你按什么顺序去核对、在哪一层看什么，以及看到的口径为什么经常对不上。
先把结论摆前面：CLI 本身不负责算钱，它是调用端，不是钱包。真正的额度活在账号侧和计费侧，终端能给你的只是间接信号。所以正确姿势是「先确认身份，再读信号，再去账号侧对账」，而不是盯着终端等一个数字蹦出来。下面逐层拆。
为什么终端里看不到一个「剩余额度」数字
Codex CLI 的设计定位是一个执行入口：把登录态、可用模型、任务请求送出去，再把结果或报错拿回来。至于你套餐里还剩多少，那是订阅系统的内部状态，CLI 不拉取也不缓存。指望它在提示符旁边挂个余额条，方向一开始就错了。
- CLI 显示的是登录状态、可用模型、报错类型，不是钱包余额
- 额度是订阅侧概念，按周期重置，终端不参与这个计算
- 任务被拦时给出的文本，往往只说明「被限制」，不说明还剩多少
- 本地配置文件里存的是凭据和偏好，不是用量账本
先分清三层口径：订阅额度、用量页、账单
对不上账，九成是因为把不同层的数字放在一起比。这三层各有各的算法和周期，必须先确认自己属于哪一层，再来谈「还剩多少」。判断依据很简单：你是怎么付费的、账号是谁开的。
| 层级 | 看的是什么 | 什么时候适用 | 去哪看 |
|---|---|---|---|
| 订阅额度 | 套餐档位对应的周期性额度口径 | 个人或团队按月订阅席位 | 账号侧订阅/用量页面 |
| 用量页 | 按天或按周聚合的消耗记录 | 需要核对消耗节奏时 | 账号侧用量页面 |
| 账单 | 逐笔计费明细 | 走纯按量 API 计费时 | 账号侧账单页面 |
| 站内目录 | 各渠道/套餐的口径说明 | 分不清自己属于哪层时 | 去 /official-api 核对 |
三层对不上时，先别怀疑系统出错，更可能是你拿订阅层的额度去比账单层的金额。先去站内的编程套餐目录确认自己属于哪一层，再往下查，会省掉一大半无效排查。
CLI 里能拿到的几个间接信号
虽然看不到余额，CLI 还是能给你几个有用的线索。关键是把它们分开读，别把三种不同的限制混成一句「没额度了」，否则处理方向会完全跑偏。
- 登录与账号
- 确认当前跑的是哪个账号、哪个档位，用错号是最常见的假故障
- 启动时输出
- 留意有没有受限、降级、额度相关的提示字样
- 报错文本
- 限流、额度不足、无权限是三种问题，处理方式完全不同
- 本地日志与时间点
- 任务失败的时间戳能帮你反推是哪条规则拦的
实操上，跑一个很小的任务当探针最省事。它成功，说明链路和额度都没问题；它被拦，把报错原文抄下来，对照上面的分类先定性，再决定去哪个页面深查。
到账号用量页看什么、怎么读
用量页是核对的主力，但读它有两个前提：先确认周期起点，再对消耗量。很多人一看数字没清零就以为「额度没刷新」，其实只是你的周期不是按自然月走的，而是从订阅起始日滚动。
- 先找周期起始和结束时间，把它记下来
- 再看当期已用量，和自己本地记录对一遍
- 区分「额度用完」和「被限速」：前者跟周期有关，后者跟当下并发有关
- 差异大时，先查是不是多端共用了同一个账号
- 站内的 /codex-radar 和 /resets 能帮你判断是不是普遍性波动
如果用量页的数字和你体感差得离谱，别急着怀疑被扣量。先看是不是有编辑器插件、网页版在后台共用同一账号消耗。多端混用是这类「账不平」的头号原因，查起来也最快。
一份可照做的核对清单
把下面这套流程跑一遍，基本能在几分钟内搞清楚自己的额度状态。顺序不要跳，跳了就容易在中途得出错误结论。
- 确认账号与档位查清当前 CLI 用的是哪个账号、属于哪个套餐，记下当前周期起始时间。
- 跑一次小任务用一个极小的请求当探针，观察是否出现受限、降级或额度相关提示。
- 打开账号用量页抄下当期已用量和周期起止时间，别只看百分比。
- 对照口径说明到站内编程套餐页核对额度口径，判断是否真的接近上限。
- 记进自己的台账把这次结论写下来，包括账号、周期、已用量、判断结果，下次直接对比。
这套清单的价值在于「可复现」。下次再遇到受限，你不需要重新摸索，照着走一遍就能定位到是哪一层的问题。建议把它存成自己的小抄。
对不上时的四种常见原因
如果你按上面的流程走完，发现数字还是对不上，多半落在这几类里。按顺序排除，比东查西查高效得多。
| 现象 | 大概率原因 | 怎么验证 |
|---|---|---|
| 额度明明没用完却提示受限 | 触发了限速闸门，不是额度问题 | 换小任务重试，看是否随时间恢复 |
| 用量页消耗比体感高 | 多端共用同一账号 | 逐一确认网页版、插件、CLI 的登录账号 |
| 周期没按预期重置 | 周期从订阅起始日滚动，不是自然月 | 在用量页核对周期起止时间 |
| 换模型后消耗变快 | 不同模型在额度折算上权重不同 | 记录换模型前后的消耗节奏对比 |
只有以上几条都排除了，才需要往账号异常或计费异常方向查。顺序反过来做，往往会在半路被一个假原因带偏，白折腾半天。
什么情况下这套方法不适用
方法再顺，也有它管不到的地方。提前说清楚边界，比事后发现「原来查了个寂寞」要好。如果你属于下面任何一种，就该换一套核对姿势。
- 走的是自建中转或第三方渠道：额度由渠道方自己定义，官方用量页看不到
- 团队统一采购的席位：你个人看到的往往是人均分摊，不是真实总量
- 已经切到纯按量 API 计费：那时该看账单，而不是订阅额度
- 用共享账号而非本人账号：所有数据都可能被别人的消耗污染
中转渠道这块尤其要留心，额度口径、重置规则、限速策略都可能和官方不一样。需要横向比较时，去站内 /sites 核对该渠道当期的说明和可信度检测结果。而如果你已经切到纯按量，价格与计费口径去 /official-api 的官方价格页核对当时的数字。
把「查额度」变成日常动作
临时抱佛脚式的查额度，永远是被动的。真正省事的做法是把它变成每周一次的小动作：固定时间抄一次用量，记下任务类型和消耗的关系，慢慢你就能预判某类活大概要花多少。
- 每周固定时间抄一次用量，比临时查有效得多
- 记录任务类型与消耗的关系，培养预判能力
- 接近上限前提前决定：等刷新、换模型，还是切按量计费
- 需要横向参照时，去站内 /usage 看真实用量榜，不要凭感觉
额度不是查出来的，是养出来的习惯——你越早建立台账，越少在关键时刻被限制打断。
还有一点容易被忽略：换模型、改任务规模、拉人协作，都会改变消耗曲线。台账里把这些变化也记一笔，下次出现异常时才有对照基线。没有基线，任何波动看起来都像故障。
下一步想省掉每次手动比对的麻烦，可以先把常见渠道的额度口径和可信度看一遍，心里有个底；在 /sites 里挑渠道时，顺手核对当时的检测记录，比事后补救划算。→常见问题
Codex CLI 里有直接查看剩余额度的命令吗？
通常没有一条只输出余额的命令。CLI 侧重调用与状态提示，额度属于账号侧信息，得去账号的用量页看；终端里能做的是确认登录账号、观察受限或降级提示，再用这些信号去反推。
终端没报错，是不是就说明额度还够？
不一定。限速和额度不足是两回事，短时间小任务可能都正常，跑到长任务或批量场景才被拦。稳妥做法是定期去用量页核对，而不是等报错才查。
为什么用量页的数字和我自己的记录对不上？
常见原因有周期起点不一致、多端共用一个账号、不同模型的额度折算权重不同。建议先确认订阅周期的起始日，再把网页版、CLI、插件的消耗合并进来一起看。
额度用完之前有没有办法提前知道？
可以按固定节奏抄用量，观察每周的消耗曲线。接近上限时提前决定是等刷新、换低消耗模型，还是切到按量计费，这样不会卡在任务做到一半。
用第三方中转或团队统一采购时，这套方法还管用吗？
要看情况。额度由渠道方或团队管理员定义时，官方用量页往往看不到真实数字，得找渠道或管理员要口径。个人侧只能做本地记录和趋势判断。
