›_ Codex Issues
Codex Issues / #14880

rate_limits is always null in rollout session files

Open 💬 4 comments Opened Mar 17, 2026 by Loongphy

What version of Codex CLI is running?

0.114.0

What subscription do you have?

Team

Which model were you using?

gpt-5.4

What platform is your computer?

Linux 6.6.114.1-microsoft-standard-WSL2 x86_64 unknown

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

Windows Terminal

What issue are you seeing?

In local Codex session rollout files, token_count events are present, but the rate_limits field is always null.

Because of this, tools like https://github.com/Loongphy/codex-auth that inspect ~/.codex/sessions/**/
rollout-*.jsonl cannot determine the actual rate limit state from the latest rollout file.

What I observed

The latest rollout file contains token_count events, but rate_limits is null
in those entries.

Example pattern:

{
  "type": "event_msg",
  "payload": {
    "type": "token_count",
    "info": {
      "total_token_usage": {
        "input_tokens": 14676,
        "output_tokens": 412,
        "total_tokens": 15088
      },
      "model_context_window": 258400
    },
    "rate_limits": null
  }
}

What steps can reproduce the bug?

  1. Run Codex CLI normally in a workspace.
  2. Locate the newest file under ~/.codex/sessions/**/rollout-*.jsonl.
  3. Search for token_count or rate_limits.
  4. Observe that rate_limits is recorded as null.

What is the expected behavior?

  • rate_limits should contain the actual rate limit metadata when available
  • It happens after gpt-5.4 model released.

Additional information

_No response_

View original on GitHub ↗

4 Comments

Astro-Han · 5 months ago

Additional data point from normal TUI usage (not codex exec): I can reproduce the same rate_limits: null behavior on codex-cli 0.115.0 with gpt-5.4 on macOS.

In two concurrent TUI tabs, both sessions initially started without five-hour-limit / weekly-limit in the status line. Later, one tab began showing 5h 94% and weekly 16%, but the corresponding rollout-*.jsonl files for both sessions still had rate_limits: null for every token_count event.

So this seems broader than exec-mode JSONL output alone. At least in TUI, there appears to be a divergence between:

  • the rate-limit state rendered in the UI
  • the rate-limit state persisted into rollout events

I opened #15054 for the TUI symptom, but it looks like the same underlying issue from a different angle.

Loongphy · 5 months ago
the rate-limit state rendered in the UI

/status fetch the usage api so that you can see accurate usage limit info in TUI

jazzyalex · 5 months ago

This bug (or it was done intentionally?) break all limit trackers who were using json parser to get it.

Like my jazzyalex.github.io/agent-sessions
macOS • open source • ⭐️ 385

Would be great to hear form oAI whether it will be fixed or not.

MarlonPassos-git · 3 months ago

I wish this switching logic could be intelligent and, when making this "automatic" switch, always pick the account with the weekly quota that is closest to being updated.