How to Check Your Codex Usage and Remaining Limits

The fastest way to check Codex usage is /status inside a CLI session: it reports your plan, your position against the rolling 5-hour window and any weekly limit, and when each resets. ChatGPT’s web surfaces show usage too, and for automation the dependable method is request-level logging through a gateway. Numbers move with plan and model, so check the meter rather than memorizing figures; how the limits themselves work is covered in Codex usage limits, explained.

The /status command

Inside any interactive Codex session, type /status. Output looks roughly like this (illustrative; the format and your numbers will differ):

> /status
Plan:           ChatGPT Plus
Model:          (your configured model)
5h window:      62% used · resets 17:40
Weekly limit:   31% used · resets Tue 09:12

Two readings matter. The 5-hour figure tells you whether you can push hard right now. The weekly figure tells you whether you can push hard this week, and it is the one to check before launching anything parallel or long-running. The window mechanics behind these two numbers are unpacked in Codex’s 5-hour window.

/status is a session command, which is its one limitation: it answers when you ask, inside a TUI. It cannot page you.

ChatGPT’s usage surfaces

Outside the CLI, ChatGPT’s settings expose a usage view for Codex, and the Codex web app shows your task activity. OpenAI moves these surfaces around as the product iterates, so we will not pin a click path that goes stale; the help center at help.openai.com tracks where the usage view currently lives. The numbers describe the same shared pool the CLI reports, since every Codex surface draws from one allowance per account.

If you came looking for a programmatic version of this: OpenAI does not currently document a public endpoint for plan-limit usage. Whatever monitoring you build has to come from the request side.

Request-level monitoring through a gateway

For Codex wired into real workloads, polling a TUI is not monitoring. The reliable signal is a log of every request with enough metadata to see limits bind. That is how we built Codex Hosted: each call through the endpoint is logged with timestamp, the lane that served it (subscription account A, account B, or your own API key), and its API-equivalent value.

The lane column is the limit detector. A request served by your API-key lane instead of your subscription lane means the subscription window was exhausted at that exact moment. You see limits as events in a log, not as anecdotes. A week of lane data answers the sizing questions that forum threads argue about in the abstract: how often your workload exhausts a window, what time of day it happens, and what the overflow would have cost at API rates. The full failover behavior is described in what happens when you hit your Codex usage limit.

A practical monitoring routine

A workable routine costs two minutes a day:

When	Check
Before any large or parallel run	/status, both meters
Morning after a heavy day	/status, weekly figure specifically
Continuously, if automated	Per-request log; alert on fallback-lane activity
Monthly	Overflow totals vs plan price, resize if needed

The habit that matters most is the first one. Most lockout stories, and most panic credit purchases, start with a big run launched against a meter nobody read. You cannot manage a limit you cannot see, and /status is the first command worth learning after login.

The monthly row is where monitoring pays for itself: observed overflow is the honest input for deciding between a bigger plan, a second account, or staying put. If you want that decision computed from your actual spend, the calculator does the tier math for you.