你在终端里跑 Codex CLI，任务跑到一半被拦下来，提示额度不够或者超过限制，但你不知道还剩多少、也不知道刚才那轮到底扣了哪些。这篇就把「查额度」这件事讲成一套固定动作：先弄清你用的是订阅额度还是 API 计费，再按对应入口去看数，最后对照站内的价格与追踪页确认口径。全程不给死数字，因为额度规则和单价一直在变，看当期页面最准。
你在终端里跑 Codex CLI，任务跑到一半被拦下来，提示额度不够或者超过限制，但你不知道还剩多少、也不知道刚才那轮到底扣了哪些。这篇就把「查额度」这件事讲成一套固定动作：先弄清你用的是订阅额度还是 API 计费，再按对应入口去看数，最后对照站内的价格与追踪页确认口径。全程不给死数字，因为额度规则和单价一直在变，看当期页面最准。
不少人第一反应是到处敲 --help 试参数，试了七八条命令还是没结果。其实查额度卡住的根因通常不在命令写法，而在你没先分清自己走的是哪条计费通道。下面按「先分类、再查数、后对账」的顺序走一遍，每一步都告诉你怎么验证有没有查对。
先搞清你查的是哪一种额度
Codex CLI 背后可能是订阅套餐额度，也可能是你自己填的 API Key 按量计费，两者的查询入口完全不一样。订阅类看的是周期内剩余量，API 类看的是账户余额和已消耗金额，混着看容易得出错误结论。
- 订阅套餐额度
- 按周期重置，关心的是本周期还剩多少可用量，通常在账号或套餐页面看
- API 按量计费
- 没有周期重置概念，花多少扣多少，关心的是余额和已消耗金额
- 中转站 Key
- 计费与额度由中转站后台管理，官方页面查不到，必须去你买 Key 的那家后台看
- 翻 CLI 配置确认认证方式打开配置文件或环境变量，看当前用的是登录态令牌还是手填的 Key。看到 Key 且不是官方签发的那种长串，基本就是走第三方通道。
- 去对应页面核对口径订阅的去编程套餐目录里对应档位页面看折算规则；按量的去官方 API 价格页看计价项；中转站的直接登它的用户后台。
在 CLI 里查额度的几条路子
CLI 的额度入口不固定，不同版本挂的子命令名字会变，所以别背命令，按下面顺序一条条试，试到能出结果就停。每条命令后面都给验证方式，别只看它有没有报错。
# 第一步：列出当前版本支持的全部子命令
codex --help
# 第二步：确认身份是否被识别
codex whoami
# 第三步：找用量或状态类子命令，名字常见为 usage / status / account
codex usage --help- 先敲帮助命令，把当前版本支持的子命令列出来，额度相关的一般挂在账号、用量或状态这一类下面
- 查版本和登录状态，确认 CLI 认得你的身份，未登录状态下查额度往往只会报权限错误
- 用非交互模式发一条极短请求，观察返回里有没有剩余量、限速窗口这类字段，这是最直接的验证方式
- 部分版本会把用量信息写进本地状态文件或缓存目录，可以去看，但要注意它可能是上次同步的旧值，别当成实时数据
本地状态文件这条路要格外小心：它通常只在某次成功请求后写入，如果你中途断网或者刚重置过额度，读到的就是过时值。判断办法很简单，对比文件修改时间和当前时间，差得远就直接跳过这个来源。
命令查不到时，去这些页面看当期数字
CLI 版本老、或者中转通道压根不把额度信息透传给客户端，这时候死磕命令没意义，直接去网页侧看。下面是常见入口和它们各自回答什么问题，具体数值一律以页面当期显示为准。
| 你想确认的事 | 该去哪类页面看 |
|---|---|
| 订阅档位对应的额度折算规则 | 编程套餐目录里对应档位的页面 |
| 官方按量计费的计价项拆分 | 官方 API 价格页，注意区分输入、输出和缓存 |
| 价格或额度最近有没有调整 | 价格变动追踪、额度重置追踪这类记录页 |
| 某家中转站靠不靠谱、额度会不会突然缩水 | 中转站可信度检测与站点目录页 |
| 自己的用量复盘和账单核对流程 | 站内已有的用量复盘类文章 |
- 套餐档位对应的额度口径，去编程套餐目录里对应档位的页面看，那里写的是折算规则而不是硬编码数字
- 官方按量价格去官方 API 价格页核对，注意区分输入、输出和缓存几类计价项
- 想看价格和额度最近有没有调整，去价格变动追踪和额度重置追踪页翻记录
- 用量复盘和账单核对的方法，站内已有专门文章讲流程，这里不重复
查出来的数和你感觉的对不上怎么办
对不上多半不是查询出错，而是口径和用量特征的问题。按下面这个顺序排查，通常两三轮就能定位。
- 先对齐统计口径CLI 显示的可能是本地累计，账户页面是服务端结算，两者存在同步时间差。先看两边的时间戳是不是同一时刻。
- 排查是否共用凭证同一个 Key 被别的工具或并发会话用过，数字会跳。检查有没有把 Key 填到多个客户端里。
- 判断是不是用量特征偏高连续重试、长上下文任务、大文件反复读入都会让消耗明显高于预期，这属于用法问题，不是查询方法问题。
- 建立观测线把三次查询的时间点和读数记下来，形成一条自己的曲线，比任何单次读数都靠谱。
单次读数只能告诉你此刻是多少，连续记录才能告诉你消耗是不是正常。
需要说明的是，这套排查主要适用于你自己能拿到账户读数的场景。如果你用的是别人转发的共享 Key、或者中转站明确不开放用量查询，那本方法里的对账环节不适用，你只能依赖对方后台给出的数据，这时候更应该先去确认那家站点的可信度。
下一步把你当前用的套餐档位或中转站找出来，对照页面上的折算规则重新算一遍自己的剩余量，比在终端里反复试命令快得多。→常见问题
Codex CLI 有没有一条命令直接显示剩余额度？
不同版本差异比较大，有的把用量放在账号类子命令下，有的只在请求返回里带剩余量字段，还有的干脆不暴露。稳妥做法是先敲帮助看当前版本支持哪些子命令，再配合发一条极短请求看返回值，两边对照着确认。查不到就去对应的套餐页或账户页看。
为什么我在 CLI 里看到的用量和后台对不上？
常见原因是口径不同：CLI 侧可能是本地累计或缓存值，后台是服务端结算，同步有延迟。另外同一个凭证被多个工具或并发会话共用时，数字也会分散。建议固定一个观测入口，记录几个时间点再看趋势，不要拿两次不同来源的读数直接相减。
查额度需要额外付费或者开权限吗？
查询动作本身一般不产生模型调用费用，但如果你是用发一条真实请求的方式去验证剩余量，那条请求是会计费的，只是量很小。用中转站 Key 的话，能不能查、查到多细取决于该站后台做得怎么样，可以先在站内中转站目录里看看它有没有用量面板。
