Improvements to the information provided by the command /status

Open 💬 0 comments Opened Aug 26, 2026 by Dyemond

What version of Codex CLI is running?

codex-cli 0.149.1

What subscription do you have?

Plus

Which model were you using?

gpt-5.6-sol

What platform is your computer?

Windows 11

What terminal emulator and version are you using (if applicable)?

Powershell through Visual Studio

Codex doctor report

What issue are you seeing?

› Currently, /status primarily shows remaining usage as a percentage for the 5-hour and weekly
limits, along with reset times. This makes it very difficult to understand how much capacity is
actually available or how expensive individual Codex operations are.

I would like to see:

The actual number of usage points/credits remaining and the total allowance, in addition to the

percentage.

The usage cost of each completed Codex turn or command.

How much that operation deducted from both the 5-hour and weekly allowance.

Ideally, total usage consumed during the current session.

For example:

5-hour allowance:

38,420 / 45,000 remaining (85.4%)

Weekly allowance:

184,200 / 220,000 remaining (83.7%)

Last operation:

1,742 points consumed

Without this information, users cannot meaningfully budget their Codex usage. A percentage alone
tells us how depleted the allowance is, but not what any particular task costs.

The current experience is similar to receiving a monthly stipend but only being told what percentage
of it remains, while shopping in a store where none of the items display prices.

Even video games generally expose both the player's available resource pool and the cost of an action
before or after that resource is consumed. Codex should provide at least that level of transparency,
particularly because different development tasks can consume dramatically different amounts of the
available allowance.

This would make it much easier to decide whether there is enough capacity remaining to begin a large
implementation, run a comprehensive audit/test cycle, or save the remaining allowance for smaller
work.

• I’m using the OpenAI product guidance skill because this is feedback about Codex’s /status and usage
reporting. I’ll check whether exact point totals or per-operation costs are currently documented, then
give you a concise, actionable version of the request.

• Explored
└ Read SKILL.md

• Searched the web for site:developers.openai.com/codex usage limits status 5-hour weekly credits

• Searched the web for Codex usage limits 5-hour weekly status credits site:developers.openai.com

• Searched the web

────────────────────────────────────────────────────────────────────────────────────────────────────────

• This is a well-founded product request. The key improvement is not merely displaying more digits; it
is exposing a stable unit of consumption so users can estimate future work.

A useful /status response should include:

5-hour allowance
38,420 / 45,000 remaining (85.4%)
Resets in 2h 14m

Weekly allowance
184,200 / 220,000 remaining (83.7%)
Resets Monday at 00:00

Last turn
1,742 usage points
5-hour deduction: 1,742
Weekly deduction: 1,742

Current session
8,936 usage points consumed

Ideally, each completed turn would also show a breakdown such as model work, tool calls, delegated
agents, and retries—provided those categories genuinely affect the allowance.

The official documentation describes API pricing in tokens and API rate limits in RPM/TPM, but that is
distinct from Codex product-plan usage windows. I could not find official documentation exposing the
underlying 5-hour/weekly point totals or per-turn deductions. Consequently, percentages cannot
currently be translated reliably into credits, tokens, or API cost. OpenAI model and rate-limit
documentation (https://developers.openai.com/api/docs/models/gpt-5-codex)

The strongest requirements for a feature request are:

Show remaining and total units for every allowance window.
Show the exact deduction after each turn.
Show cumulative session consumption.
Define what a “usage point” represents, or explicitly describe it as a normalized internal unit.
Preserve percentages and reset times for quick scanning.
Expose the same information through /status and any graphical usage page.
Make usage data machine-readable so clients can display budgets and warnings.
If exact totals cannot be disclosed, show normalized units with a fixed total such as 100,000 per

allowance rather than percentages alone.

That would make usage planning possible without requiring disclosure of proprietary model-cost
calculations.

What steps can reproduce the bug?

Uploaded thread: 01a036dc-0640-7412-87bb-9c6b24325551

What is the expected behavior?