Guide
How to check your Codex CLI usage limits
When you sign in to the Codex CLI with ChatGPT, your plan includes a usage allowance measured over time windows. Hit a window's limit and Codex stops answering until it resets. With several Codex sessions running, that happens sooner than you expect, so it pays to know where the numbers are.
What the limits are
Which windows you have depends on your plan, and OpenAI changes them from time to time. Plans have had a rolling five-hour window and a weekly window, each with its own reset time, and you can run into either one. Some plans have a single, longer window instead: on a Go plan we saw one 30-day window. The Codex pricing page lists what each plan includes today.
The limits belong to your account, not to a session or a machine. Every Codex session you run, anywhere, draws on the same windows. If you sign in with an API key instead, you pay per token and these windows do not apply.
1. /status in the CLI
Type /status in a running Codex session. Besides the model and settings of the session, it shows how much of each window you have used and when it resets. Codex learns the numbers from its replies, so send one prompt first in a new session.
2. The usage page
The Codex usage page in your ChatGPT settings (chatgpt.com/codex/settings/usage) shows the same windows, their reset times and any credits. It works without a running session. Note that the OpenAI API dashboard only covers API-key spending, not your plan's windows.
3. Codex's session logs
Codex writes every session to a file under ~/.codex/sessions/YYYY/MM/DD/ (or under $CODEX_HOME/sessions if you set it). After each reply it adds a token_count event with a rate_limits object:
"rate_limits": {
"primary": { "used_percent": 42.0, "window_minutes": 300, "resets_at": 1792512000 },
"secondary": { "used_percent": 18.0, "window_minutes": 10080, "resets_at": 1792944000 },
"plan_type": "plus"
}used_percent is how much of the window is used, window_minutes its length (300 is five hours, 10080 a week) and resets_at the reset time in Unix seconds. secondary is null when your plan has one window. Older Codex versions wrote resets_in_seconds instead. To read the latest numbers without opening Codex, on macOS or Linux (needs jq):
f=$(ls -t ~/.codex/sessions/*/*/*/rollout-*.jsonl | head -1)
grep '"rate_limits"' "$f" | tail -1 | jq '.payload.rate_limits | {primary, secondary}'On Windows, in PowerShell:
$f = Get-ChildItem "$HOME\.codex\sessions" -Recurse -Filter 'rollout-*.jsonl' |
Sort-Object LastWriteTime | Select-Object -Last 1
(Select-String $f.FullName -Pattern '"rate_limits"' | Select-Object -Last 1).Line |
ConvertFrom-Json | ForEach-Object { $_.payload.rate_limits }Both read the newest session. If it has not had a reply yet, they print nothing; the numbers are the account's, so any recent session will do. The format is not documented and may change.
4. Always in view, next to Claude Code's
Paneherd, an extension for VS Code and Cursor, reads those log entries for you and shows Codex's windows at the top of its sidebar, under Claude Code's five-hour and weekly limits, with the time to each reset. They update after every Codex reply and show while a Codex pane is open, or until a window you used resets. Nothing is sent anywhere: it reads the files Codex already writes. It is in the free version.
Making the allowance last
- Check before starting more sessions. Three sessions use a five-hour window three times as fast.
- Keep tasks small and specific. Long, wandering sessions with big contexts use the most.
- Hand off to another agent. Claude Code, Copilot CLI and others bill their own plans, so a task can move when Codex is close to a limit. See running several agents side by side.
Next: how parallel sessions use Claude Code's limits and how the tools compare.