Usage limit weirdness again

[dlukt]

What version of Codex is running?

codex-cli 0.44.0

Which model were you using?

gpt5-codex high

What platform is your computer?

Linux 6.16.10-arch1-1 x86_64 unknown

What steps can reproduce the bug?

/status

╭─────────────────────────────────────────────────────────────────────────────╮
│  >_ OpenAI Codex (v0.44.0)                                                  │
│                                                                             │
│  Model:            gpt-5-codex (reasoning high, summaries auto)             │
│  Directory:        ~/RustroverProjects/ember                                │
│  Approval:         never                                                    │
│  Sandbox:          danger-full-access                                       │
│  Agents.md:        AGENTS.md                                                │
│  Account:          (Plus)                               │
│  Session:          0199b19b-0ef7-7f92-b8bd-23d515644c0c                     │
│                                                                             │
│  Context window:   6% left (255K used / 272K)                               │
│  5h limit:         [██████████████████░░] 91% used (resets 14:29)           │
│  Weekly limit:     [████████████░░░░░░░░] 62% used (resets 10:07 on 10 Oct) │
╰─────────────────────────────────────────────────────────────────────────────╯


› Moderator gate checks wrong role casing

  The client now blocks access to the moderation console unless roles.includes("MOD"), but server roles are normalised to lowercase
  strings such as "moderator" or "mod" (Role::from_claim maps any case to lowercase, see auth/context.rs). If the identity provider
  issues the standard lowercase claims, authenticated moderators will still be rejected on the client because the check only looks
  for the uppercase literal "MOD". Consider accepting the same variants the backend accepts (e.g. lowercase moderator/mod) or
  normalising roles before comparison so authorised moderators are not inadvertently locked out.


• Ran zsh -lc "apply_patch <<'PATCH'
  │ *** Begin Patch
  │ *** Update File: ember-web/src/app/auth/AuthProvider.tsx
  │ … +15 lines
  └ Success. Updated the following files:
    M ember-web/src/app/auth/AuthProvider.tsx

• Ran zsh -lc 'pnpm lint'
  └
    > ember-web@0.0.0 lint /home/darko/RustroverProjects/ember/ember-web
    > eslint .


■ You've hit your usage limit. Upgrade to Pro (https://openai.com/chatgpt/pricing) or try again in 2 hours 3 minutes.

/status

╭─────────────────────────────────────────────────────────────────────────────╮
│  >_ OpenAI Codex (v0.44.0)                                                  │
│                                                                             │
│  Model:            gpt-5-codex (reasoning high, summaries auto)             │
│  Directory:        ~/RustroverProjects/ember                                │
│  Approval:         never                                                    │
│  Sandbox:          danger-full-access                                       │
│  Agents.md:        AGENTS.md                                                │
│  Account:          (Plus)                               │
│  Session:          0199b19b-0ef7-7f92-b8bd-23d515644c0c                     │
│                                                                             │
│  Context window:   6% left (256K used / 272K)                               │
│  5h limit:         [████████████████████] 100% used (resets 14:28)          │
│  Weekly limit:     [█████████████░░░░░░░] 65% used (resets 10:07 on 10 Oct) │
╰─────────────────────────────────────────────────────────────────────────────╯

What is the expected behavior?

not 9% used with a single prompt

What do you see instead?

No response

Additional information

Restore token information.
I want to see exactly how many tokens are and were used.

[github-actions]

Potential duplicates detected:

• Plan only updates on the first request of a new conversation; never updates on subsequent requests #3599

Powered by Codex Action

[dlukt]

Lucky I have a claude sub to fill the gaps. Those limits really need to go.

[Alfredo-Sandoval]

@dlukt yup same.

[AdsQnn]

not 9% used with a single prompt

The reason for this is that Codex manages context poorly — it processes everything through the main context buffer.
I’ve discussed this many times. Claude Code, for example, uses separate agents for editing and searching,
so it doesn’t handle all of that in the main thread.

Their explanation is that they only count new tokens toward the limit and don’t use a persistent cache.
However, a fast cache can usually stay alive for 5–10 minutes, sometimes even up to an hour.
So if you step away for a while or resume a session, and you already have 150k tokens in context,
the entire 150k will be loaded into the limit right from the first request.
Then, every subsequent iteration — every search or read operation during one response —
adds even more tokens to the total. That’s why the overflow happens.

[dlukt]

Nice explanation.
What can be done about it?

[AdsQnn]

You can avoid long pauses between tasks and rely on the model not generating a single continuous response for more than about 5 minutes without calling a function :)

You can also start new sessions more frequently.

Or, if you prefer, you can modify the Codex CLI yourself — adding dedicated agents to handle specific actions.

Or just hope they’ll eventually do something about it someday.

You can’t completely solve this — whenever you start with a large context and write with breaks,
you’ll eventually hit a cold cache that’s already expired.
Still, proper context management can greatly minimize the impact.

[dlukt]

I was thinking maybe have some kind of in memory backed to disk cache, but that would require deep modifications in the cli, right?
I tried, no plug intended, factory ai/droid. They have a, well more badly than well working codex-web like service. It has many issues but I observed something.
Initially tokens would be consumed like crazy but after a while, warm-up phase I guess, that token consumption would slow down considerably.
I was using gpt-5 high because it wouldn't work with gpt-5-codex.
And that was really great, got a lot done with little token consumption, but then the platform errors hit again, some change was probably pushed which disconnected the web client from the VM, had to start a new chat and same happened again, initial token burn, then stabilization until the next unannounced UI change.
With the droid cli using gpt-5-codex token consumption remained steady, I'd judge it medium-high but not extreme.
It was however very refreshing to not be limited and scared of hitting the next artificial limit again.

Token display should be at the bottom again with a timer display.
I don't like the new tui.