cache miss can cause higher usage towards limit than expected
Resolved 💬 11 comments Opened Oct 5, 2025 by dlukt Closed Nov 14, 2025
💡 Likely answer: A maintainer (github-actions[bot], contributor)
responded on this thread — see the highlighted reply below.
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.
11 Comments
Potential duplicates detected:
Powered by Codex Action
Lucky I have a claude sub to fill the gaps. Those limits really need to go.
@dlukt yup same.
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.
Nice explanation.
What can be done about it?
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.
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.
This is correct, the current way the caching works is that it expires after 15 mins. We are working on improving this. What I recommend is to start new sessions more frequently.
Internal conversation for reference: link.
@tibo-openai
What do you think about having an auxiliary agent that explores the code and drops snapshots into the main context? For example, Claude Code does something like that. This way, the chance of such an issue occurring would be much smaller than if you keep the entire exploration within the main context.
Url
Url
https://blog.langchain.com/deep-agents/
That’s just what I had in mind and what I was talking about.
https://blog.langchain.com/introducing-deepagents-cli/
We have landed optimizations behind the scenes that mean that you now will get the same usage throughout the day irrespective of the load or how traffic is routed.
Before you could get unlucky and hit a few cache misses in a row and get less usage.