How to Check Codex Token Usage: CLI /status, Usage Dashboards, API Tokens, and Local History

There is no single Codex token usage number. If you are inside Codex CLI, run /status to check the current session; use /statusline when you want counters visible while you work. For account quota or money, change surfaces: Codex or ChatGPT usage settings show plan quota or credits, OpenAI Platform Usage shows API organization usage, and a completed API response's usage object shows per-call tokens.

Choose the meter by the question:

• Current CLI session: /status
• Persistent CLI footer: /statusline
• ChatGPT/Codex plan quota or credits: Codex or ChatGPT usage settings
• API-key spend: OpenAI Platform Usage
• One API request: the completed response usage object
• Historical local activity: local Codex logs, as an estimate only

Do not start with private endpoint scripts or local JSONL totals. They can be useful for personal estimates, but they are not official account-wide billing records and they can expose prompt or file context from the machine where Codex ran.

Fast Answer: Choose the Right Usage Meter

The fastest answer is to ask what kind of usage you need to prove. A current CLI session, a ChatGPT plan quota, API billing, and one API response are different records. Comparing them as if they were one ledger creates false alarms.

As of May 23, 2026, volatile Codex plan limits, credit rules, dashboard labels, and UI paths still need a current OpenAI account check. The command names and the API response concept are more stable than the exact subscription dashboard wording.

Codex CLI: Use /status First

The fastest check inside Codex CLI is /status, but it is not an account-wide history report. OpenAI's Codex slash-command docs describe /status as the command that displays session configuration and token usage. That makes it the right first move when the question starts inside the terminal.

Run it in the active Codex session:

text
/status

Read the output as session evidence. It can help you understand the model, active configuration, context pressure, and token use for the current work surface. It does not prove how much your ChatGPT plan has left for the week, how much an API key spent yesterday, or how many tokens another computer used.

Use this boundary:

The practical workflow is simple. Run /status, capture the output if you need support evidence, then decide whether the next question belongs to the CLI, the subscription dashboard, or API billing.

Keep Counters Visible with /statusline

Use /statusline when you do not want to interrupt work just to check the session state. OpenAI's Codex slash-command docs describe /statusline as the command for configuring what appears in the footer, including model, context, limits, token counters, git, session, current directory, and Codex version.

That distinction matters. /status is a check you call. /statusline is a display surface you configure for ongoing visibility.

In Codex config terms, the status line belongs to the TUI configuration. OpenAI's Codex config reference points to the user config at ~/.codex/config.toml and documents tui.status_line as the ordered list of footer status-line items. Use that as a configuration pointer, not as a place to invent unsupported account-wide counters.

Good uses for /statusline:

• keep context pressure visible during long edits
• notice when a session is getting expensive before starting another large task
• keep model and session identity visible while switching projects
• reduce repeated /status checks during focused work

Bad uses for /statusline:

• proving historical spend
• reconciling ChatGPT plan quota with API billing
• replacing the OpenAI Platform Usage dashboard
• estimating another machine's Codex activity

If your question is "what is happening in this terminal right now?", stay in CLI commands. If your question is "what did my account or API key spend?", leave the CLI surface.

ChatGPT and Codex Quota: Check the Subscription Surface

Subscription-side usage is the easiest place to mix up vocabulary. A Codex plan quota, a credit balance, a local CLI session, and an API organization bill are not the same thing.

For plan quota or credits, start from the Codex or ChatGPT usage settings available to the signed-in account. OpenAI's Codex pricing and limits docs are the right current source for plan and credit rules, while the exact account UI labels can move. The stable rule is the owner: ChatGPT/Codex plan usage belongs to the ChatGPT or Codex account surface, not to OpenAI Platform API billing.

Use the subscription surface when the question looks like this:

• "How much Codex included usage do I have left?"
• "Did I hit a plan or credit limit?"
• "Do credits apply to this Codex route?"
• "Is this a ChatGPT sign-in session or an API-key session?"

Keep plan-limit detail out of the usage-check step. If you need current windows, credits, post-limit choices, and plan caveats, use the separate OpenAI Codex usage limits guide. That page owns the quota contract. The job here is narrower: choose the right meter before trusting the number.

The support-grade habit is to capture three facts together:

1. Which account is signed in.
2. Which Codex route is active: ChatGPT sign-in, API key, or mixed setup.
3. Which usage surface you checked and when.

That evidence is much stronger than a copied number with no route context.

API Billing and Per-Call Tokens Are a Different Lane

OpenAI Platform Usage is the API billing lane, not the ChatGPT subscription quota lane. Use it when an API key, project, organization, service account, SDK, or backend integration is involved.

There are two API checks that answer different questions:

The completed response usage object is the per-call token source. In the Responses API reference, completed responses expose token accounting fields such as input tokens, cached input tokens, output tokens, reasoning output tokens where applicable, and totals. If you stream responses, do not assume usage is final until you have the completed response data that includes usage.

A minimal logging shape looks like this:

json
{
  "response_id": "resp_...",
  "model": "gpt-...",
  "usage": {
    "input_tokens": 1200,
    "cached_input_tokens": 800,
    "output_tokens": 350,
    "total_tokens": 1550
  }
}

Those numbers are useful for request-level accounting, debugging, and cost attribution. They still do not tell you how much ChatGPT subscription Codex quota remains. If your workflow moved from ChatGPT sign-in to an API key, you also moved the meter.

For the route decision itself, use the Codex API key vs subscription guide. It separates ChatGPT sign-in, API-key billing, and credits before you start comparing usage.

Local History Estimates: Useful, but Not Official

Local logs can help with estimates only after you know what official meter you are trying to compare. They are most useful when you need a personal sense of local Codex activity on one machine, such as "which project created the longest sessions?" or "did this terminal run a large task yesterday?"

They are weak evidence for billing or quota disputes.

Use this safety boundary before parsing anything local:

If you run a local parser, keep it private, read-only, and scoped to the files you control. Do not paste full transcripts into public tools. Do not treat local JSONL totals as official account-wide usage. Do not build a workflow around private endpoints just because a community post discovered one.

The honest sentence is: local history can estimate what this machine recorded; official surfaces decide billing, quota, and account state.

Why the Numbers Do Not Match

Different Codex and OpenAI usage numbers often disagree because they are answering different questions.

Do not force a reconciliation across surfaces. First classify the number, then compare it only with the same kind of number.

What to Capture Before Asking Support

If the number still looks wrong, collect evidence that keeps the meter boundaries intact.

For a CLI issue:

• /status output from the active session
• the Codex version if visible in the TUI or status line
• the model and route you expected
• whether the session used ChatGPT sign-in or an API key
• the approximate time window

For a subscription quota issue:

• screenshot or account-visible copy of the Codex or ChatGPT usage surface
• plan or workspace type
• whether credits were involved
• time zone and time window
• a note about whether cloud tasks, local messages, or code reviews were involved

For an API billing issue:

• organization and project scope
• API key or service-account owner, without exposing the key
• Platform Usage time range
• representative completed response usage objects
• model names and request IDs where available

That evidence lets support or an admin answer the right question. "Codex token usage is wrong" is too broad. "The /status session counter, ChatGPT quota dashboard, and Platform Usage dashboard are being compared across different routes" is diagnosable.

FAQ

How do I check Codex token usage in CLI?

Run /status inside the active Codex CLI session. Use it for current session configuration and token usage, not for account-wide history.

What does /statusline do?

/statusline configures footer visibility in the Codex TUI. It can keep counters and context visible while you work, but it is still a session-facing display, not a billing dashboard.

Where do I check Codex plan quota or credits?

Use the Codex or ChatGPT usage settings for the signed-in account. Treat exact labels and plan rules as volatile, especially around credits, model availability, and workspace migration.

Where do I check OpenAI API token usage?

Use OpenAI Platform Usage for organization or project usage. For one request, inspect the completed response usage object.

Why does Codex CLI usage not match OpenAI Platform Usage?

Because they are different meters. CLI usage describes the active Codex session. Platform Usage describes API organization or project usage.

Can local Codex logs show historical token usage?

They can estimate local activity on the machine where the logs were written. They cannot prove official account-wide usage, and they can contain sensitive prompt, path, or file context.

Should I use private endpoint scripts to check usage?

No. Use supported CLI commands, account usage settings, Platform Usage, and completed API response usage first. Private endpoints are not a normal reader-safe checking path.