The issue of dramatically increased Codex quota consumption.

Open 💬 12 comments Opened Jun 4, 2026 by ballytranshipper-eng
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.601。21317

What subscription do you have?

chat gpt plus

What platform is your computer?

"$([Environment]::OSVersion | ForEach-Object VersionString) $(if ([Environment]::Is64BitOperatingSystem) { "x64" } else { "x86" })"

What issue are you seeing?

After my Codex quota reset on June 4, 2026, token usage became abnormally high compared with the previous day, and the sidebar context also became much shorter.

This does not look like normal task variance.

On June 3, 2026, I started a new task and did a lot of heavy work, including scanning the whole project folder and identifying issues across the workspace. That kind of work usually consumes a lot of tokens. Even so, the total usage for the entire day was only about 4.6M tokens.

On June 4, 2026, after the quota reset, I only worked for about 2-3 hours and did only a few relatively small tasks, but usage already reached about 20.559M tokens.

So compared to yesterday:

  • the work was lighter
  • the working time was much shorter
  • but token usage was about 4.5x-5x higher

At the same time, I also noticed that the sidebar context became much shorter much earlier than before.

Because of that, this feels more like a regression in usage accounting, context compaction, repeated context processing, or some reset-related backend issue, rather than normal differences in task complexity.

What steps can reproduce the bug?

Feedback ID: 019e8bff-cfa6-7972-8041-7a2d0d3eab75

I cannot provide a perfectly deterministic minimal repro, but I can provide a concrete timeline and a server-side reference that should make investigation easier.

I already submitted in-product feedback from the main working chat thread:

  • Feedback ID: 019e8bff-cfa6-7972-8041-7a2d0d3eab75

If this feedback ID lets the team inspect the underlying thread, usage accounting, and context behavior for that session, it should be possible to compare the abnormal behavior directly.

Observed timeline:

  1. June 3, 2026
  • I was working in my main Codex chat thread.
  • This was not a trivial session. I did relatively heavy work, including scanning the whole workspace / project folder and identifying problems.
  • Even with that heavier workload, total usage for the day was only about 4.6M tokens.
  • Overall behavior felt normal.
  1. June 4, 2026, after quota reset
  • I continued working again in Codex.
  • This time I only did a few relatively small tasks and worked for about 2-3 hours.
  • Despite the lighter workload, usage already reached about 20.559M tokens.
  • At the same time, the sidebar context became noticeably shorter much earlier than before.
  1. The abnormal pattern is therefore:
  • previous day: heavier work, lower total token usage
  • after reset: lighter work, much higher token usage
  • context retention also appeared worse after reset

This is why I suspect the issue may be related to:

  • usage accounting after quota reset
  • repeated context processing
  • context compaction / context reuse regression
  • or another backend issue affecting token accounting or effective context retention

This does not look explainable by normal task complexity differences alone.

What is the expected behavior?

Token usage after reset should be broadly consistent with the actual workload.

If I do lighter work for a shorter amount of time, token usage should not suddenly become 4.5x-5x higher than the previous day.

Context retention should also behave similarly unless there was an intentional product change.

Additional information

I already submitted feedback from the affected main chat thread:

  • Feedback ID: 019e8bff-cfa6-7972-8041-7a2d0d3eab75

If the team can inspect that thread internally, it may help verify:

  • actual token accounting per turn
  • whether context was repeatedly reprocessed
  • whether context compaction changed after reset
  • whether the session was routed differently after quota refresh

Important comparison:

  • June 3, 2026: heavy work, including scanning the whole workspace, about 4.6M tokens total
  • June 4, 2026: after quota reset, only 2-3 hours and a few smaller tasks, but about 20.559M tokens

So the issue is not just "high usage" in the abstract. It is a sharp day-to-day change that appeared immediately after quota reset.

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #25132
  • #25051
  • #26253
  • #24860

Powered by Codex Action

amitahire · 1 month ago

Same thing happened to me and a dramatic 77% increase in calls after reset and all my weekly quota is exhausted

starpos-com-ar · 1 month ago

Same here. Yesterday I was using very simple prompts, without even editing any files, and I ran out of my 5-hour usage window in just 25 minutes. The day before, and in previous weeks, I was able to complete much heavier tasks with the same model and effort level. This seems like a sudden change in token usage or rate-limit accounting.

jaylex32 · 1 month ago

I CANT BELIEVE THIS HASNT BEEN FIX YET, IS BAD!!!

Ch0pin · 1 month ago

Same here !!

stkthreejp · 1 month ago

I've had the same issue all week. Codex was great until this past week, and now usage is gone, with one prompt every window. It's wild, I saw an update today, maybe that helped?

rafiqlightwala · 1 month ago

Same issue please fix this asap!

primozcerar · 1 month ago

Same issue. Quota drain increased dramatically this week for all our business account users, preventing normal work with codex since we can not complete a simple task in the 5 hour usage limit! Needs fixing ASAP!

jaylex32 · 1 month ago

at this point, anything is better than codex for the price, not worth it.

lukakas0213 · 1 month ago

same herre

SREDevOpsNL · 1 month ago

+1 — I am seeing a very similar regression, but on a newer Codex Desktop version.

Codex app version:
26.609.71450, released Jun 16, 2026

Platform:
Windows, Codex desktop app

Account:
Personal ChatGPT Plus account

Feedback ID:
019e97a5-b545-7641-bcec-cfcd9b53fca2

Issue:
After updating to 26.609.71450, Codex started over-expanding narrow tasks and spending a very long time on work that should be a small maintenance fix.

Concrete case:
I asked Codex to fix a simple smoke-test video artifact path mismatch.

Original request, shortened/sanitized:

Video of a demo smoke test run is moved to another folder: <repo>\test\test-results\smoke-artifacts\pvw-ui-smoke-demo\20260614-013147\01_PVW-US-09-...\playwright\videos\<test-name>\<hash>.webm Please check that smoke tests use again: <repo>\test\test-results\smoke-artifacts\pvw-ui-smoke-demo\20260614-013147\01_PVW-US-09-... where 20260614-013147 is DateTime-UniqueNumber specific to that test run.

Expected behavior:
Codex should keep the task narrow:

  • identify why the raw Playwright video remains nested under playwright\videos\...;
  • copy/promote the reviewer-facing video back to the scenario folder root, e.g. demo.webm;
  • make the minimal code/path fix if needed;
  • stop after minimal verification.

Actual behavior:
Codex worked for 3h 20m 33s and still did not properly complete the simple requested fix. It drifted into broader, unnecessary work such as:

  • reading startup/project context;
  • investigating runner behavior too broadly;
  • improving timestamp collision handling;
  • editing docs/runbooks;
  • editing review-pack notes;
  • changing more files than needed for the immediate path mismatch.

Codex later admitted the scope drift itself:

“You’re right to be angry. I overworked a simple artifact-path fix.” “I correctly identified that the raw Playwright video was nested under playwright\videos\<test-name>\<hash>.webm.” “I did copy it to the scenario root as demo.webm.” “Then I drifted into ‘improving’ the runner, docs, timestamp collision handling, and review-pack wording. That was not necessary for the immediate fix.”

Impact:
This consumed a large amount of Codex quota and made the desktop app unreliable for small maintenance tasks. The issue is not only raw slowness; it is also task-scope drift combined with very long agent runtime.

Why I think it is related to this issue:
The visible behavior matches the regression described here: narrow tasks that previously should have taken a few minutes now take tens of minutes or hours, with long stretches of context loading/searching/tool work before reaching the actual edit/verification phase.

Request:
Please treat this as a serious Codex Desktop agent-runtime regression affecting:

  • task scoping;
  • no-progress detection;
  • excessive context loading;
  • long-running task control;
  • quota consumption for small tasks.

I have uploaded in-app feedback from the affected Codex session.

Feedback ID:
019e97a5-b545-7641-bcec-cfcd9b53fca2

Bigg-Iron · 27 days ago

Asked another AI agent to review my codex usage logs:

"The quota drain is almost certainly from background / automated activity inside Codex, not a silent OpenAI quota cut.

Key evidence from your local Codex database (state_5.sqlite):

• 4 threads were updated after June 20 and consumed ~19.06 million tokens in that period alone. (I just returned from a camping trip June 19-21 -- haven't touched a computer since friday)
• Several of those are codex-auto-review threads that appear to be running automatically.
• There is a thread updated as recently as June 23 02:26 (very recent).
• You have multiple long-running sessions that keep accumulating tokens even when you're not actively chatting.

Most likely causes

  1. Automated review agents (codex-auto-review) — These are being spawned or kept alive in the background and are burning through tokens via repeated tool calls or context building.
  2. Persistent / long-lived threads — Some sessions (especially the 10M–17M token ones from June 16–19) are staying active and continuing to consume tokens. (??)
  3. MCP server activity — You have several MCP servers configured (GitHub, Chrome DevTools, etc.). If any of them are polling or triggering tool calls autonomously, they can generate significant token usage."

I'm on a 'Plus' plan. Hope this helps.