Usage limit inconsistencies

What version of Codex CLI is running?

0.142.0

What subscription do you have?

plus

Which model were you using?

5.4

What platform is your computer?

windows 11

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

Git Bash

Codex doctor report

What issue are you seeing?

Inaccurate usage limit

What steps can reproduce the bug?

**# /status 5-hour usage indicator appears to recalculate unpredictably (remaining % increases and reset time moves earlier)

Summary

The Codex /status output can change in ways that are difficult to interpret.

In one continuous Codex session, I observed:

• Remaining 5-hour quota increase dramatically while I continued using Codex.
• The reported reset time move earlier.
• No explanation in the UI for why either value changed.

This makes it difficult to understand actual usage or predict remaining capacity.

Environment

• Codex CLI: v0.142.0
• Account: ChatGPT Plus
• Single active Codex session
• No manual usage reset
• No additional Codex sessions open

Initial /status

Context window: 37% left (166K used / 258K)
5h limit:       38% left (resets 15:35)

Later in the same session:

Context window: 16% left (219K used / 258K)
5h limit:       98% left (resets 15:26)

During that period:

• I continued using the same session.
• Context usage increased as expected.
• I did not invoke a usage reset.
• I did not intentionally start another session.
• The model automatically changed from GPT-5.5 to GPT-5.4 high during the workflow.

Expected behavior

Either:

• The displayed quota should behave monotonically according to whatever accounting model is used, or
• If recalculation is expected, the UI should explain why.

For example:

• "Usage recalculated."
• "Rolling window updated."
• "Accounting refreshed after model change."
• "Quota recomputed from backend."

Similarly, if the reset time changes, the interface should indicate why.

Actual behavior

The displayed remaining quota increased substantially (38% → 98%) while the reset time moved earlier (15:35 → 15:26), with no indication of what caused either change.

From a user's perspective, this makes it impossible to determine whether:

• usage accounting was corrected,
• the rolling window advanced,
• the model switch changed accounting,
• different models have different quota pools,
• or the values are approximate estimates.

Why this matters

The CLI exposes concrete-looking percentages and reset times, encouraging users to rely on them when planning work.

When those values change significantly without explanation, users are left trying to reverse-engineer the accounting system. Even if the backend behavior is correct, the presentation is not sufficiently transparent to inspire confidence.

Suggested improvements

• Document exactly what the 5-hour meter represents.
• Clarify whether it is a rolling window or another accounting model.
• Indicate when displayed values have been recalculated.
• Explain why the reset time changes.
• Explain whether automatic model switches can affect usage accounting.
• If percentages are estimates rather than exact values, label them accordingly.

**

What is the expected behavior?

_No response_

Additional information

"The 5-hour usage meter should either change predictably according to its documented accounting model or explain when and why it has been recalculated (for example, after a rolling-window update or model change)."