Codex weekly quota is being consumed far faster than expected during normal app development workflows

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

• #38233
• #38728
• #38335
• #38600

Powered by Codex Action

I am seeing this as well. I was just chatting about an issue I am having with ChatGPT and my usage has gone down by 2%. Only 4 small chats like what do you want me to say in the comments. Seems high for asking how to fix ChatGPT.

Additional context that may help reproduce or diagnose the usage behavior:

I am just new user subscribed to Chatgpt Plus and used Codex.

During my first weekly usage period, I used GPT-5.6 Sol heavily while designing architecture, establishing patterns, and implementing the first four engines of the application. That work involved large repository context and substantial reasoning, so reaching approximately 99% of the weekly allowance by the end of that week was not especially surprising.

The behavior that concerned me happened after the weekly allowance reset.

During the second week, the project already had its primary architecture, patterns and implementation structure in place. I therefore started using a mixture of GPT-5.6 Sol settings such as Medium and Light rather than consistently using the highest reasoning level.

Despite this, a very large portion of the new weekly allowance was consumed near the beginning of the week, particularly during roughly one 4-hour usage window.

So the pattern was approximately:

Week 1: heavy architectural/design work, mostly GPT-5.6 Sol, high usage over the entire week → understandable.
Weekly allowance reset.
Week 2: more incremental implementation/audit work, mixed Medium/Light model settings.
Within an early ~4-hour window, usage increased disproportionately compared with what I expected from the workload.

I also changed model/reasoning settings during this second period, so I cannot tell whether model switching, repository context handling, repeated context ingestion, or another accounting issue contributed to the spike.

I am adding this because the difference between the two weeks may be useful when investigating whether the usage calculation behaved as intended.

I noticed another report suggesting that switching between model/reasoning settings might be related to unusually high usage. I also switched between GPT-5.6 Sol settings during the affected period. I cannot confirm that this caused the issue, but the timing overlaps with my usage spike and may be relevant for reproduction.

One additional detail that may help narrow this down: I did not make major environment/workflow changes between the normal and abnormal usage periods.

In particular:

• I did not create or move to a new project/repository.
• I continued working on the same existing application and repository.
• I did not make significant changes to Codex personalization/instructions.
• The repository architecture and primary implementation patterns were already established during the first week.
• I did not suddenly increase the size or complexity of the tasks; if anything, much of the second-week work reused patterns established during the heavier first week.
• The notable behavioral change on my side was switching between GPT-5.6 Sol reasoning/model settings during the affected period.

I cannot say that model/reasoning switching caused the increased consumption. I mention it only as a variable that changed, while the items above remained broadly constant.

Update: 5-hour limit exhausted and ~15% of weekly quota consumed by a very small workflow

I have another concrete usage data point for this issue.

I deliberately kept this Codex session small because of the unusually high quota consumption I previously reported.

Despite that, the work exhausted my 5-hour Codex usage window and consumed approximately 15% of my weekly quota.

What Codex actually did

The work was limited to:

• Creating/moving a small number of folders/files.
• Editing approximately 5 files.
• Adding documentation text that I had already prepared and supplied.
• Making small test/project-reference changes required by those edits.
• Performing one repository audit/review.
• Producing analysis of possible next steps rather than implementing a substantial new feature.

There was no large feature implementation, no major refactor, no large code-generation task, no data-processing workload, and no long sequence of implementation tasks.

Some of the session was also spent correcting conclusions from earlier Codex analysis rather than producing additional implementation.

Usage result

After this relatively small workflow:

• 5-hour Codex usage limit: exhausted
• Weekly Codex quota consumed: approximately 15%

This is dramatically different from my earlier experience with Codex.

Previously, substantially larger development tasks consumed a much more reasonable fraction of my weekly allowance.

Because I had already noticed the increased consumption, I deliberately changed how I use Codex:

• smaller tasks;
• narrower prompts;
• more decisions prepared before invoking Codex;
• less open-ended exploration;
• less implementation per request.

Despite reducing the workload, the quota is still being consumed extremely quickly.

At the current observed rate, my weekly allowance would support only a surprisingly small number of ordinary file edits and repository reviews.

The 5-hour limit compounds the problem

I understand that the 5-hour limit represents a usage window rather than five literal hours spent interacting with Codex.

However, the practical result is:

small workflow → 5-hour limit exhausted → work stops → ~15% of weekly quota also gone

This means I can be blocked from continuing after a relatively small amount of useful work while simultaneously losing a significant part of the weekly allowance.

Waiting overnight does not solve the weekly-consumption problem.

I am reluctant to use the banked reset

I currently have a banked rate-limit reset available, but I do not think it is safe to use while this behavior remains unexplained.

If the underlying usage accounting or weighting is abnormal, resetting the limit could simply expose another allowance to the same unusually high consumption rate.

This concern seems particularly relevant given the reports in:

• #40527 — significantly increased weekly quota consumption after reset
• #40693 — limit reportedly reached again after a reset and a single ~22-minute job

So the reset does not currently feel like a solution to the underlying issue.

What would help clarify this

Could OpenAI clarify:

• Have Codex weekly limits or effective usage weights changed recently?
• Has the relationship between the 5-hour and weekly limits changed?
• Has cached-context accounting changed?
• How much usage can repository reading/searching consume?
• Do tool calls, compaction, retries, test execution, or other background activity count toward these limits?
• Can significant usage occur that is not visible from the conversation/task itself?
• Do banked resets use exactly the same accounting and model weighting?
• Could #39699, #40527, and #40693 be related?

A per-task usage breakdown would be extremely useful.

Currently, seeing only the percentage remaining makes it impossible to determine whether this behavior comes from token/context volume, model weighting, tool overhead, background activity, or a quota-accounting problem.

Until this is clarified, I cannot meaningfully predict how much work my weekly Codex allowance actually provides.

Update — quota consumption remains extremely high even after aggressively reducing task scope/context

I have continued testing this because I wanted to rule out my repository structure, prompts, and Codex exploration behavior as the main cause.

Today I deliberately changed my workflow to minimize Codex usage:

• tasks were split into narrowly bounded implementation slices;
• prompts explicitly limited scope;
• repository instructions/navigation were made much smaller;
• unrelated projects/modules were excluded from normal inspection;
• I used fresh chats for independent tasks rather than carrying long conversations forward;
• Codex was asked to use focused tests rather than broad repository work.

This helped somewhat with unnecessary exploration, but the quota consumption is still extremely high.

A recent narrowly scoped task changed only three Python tooling files. It consumed approximately:

• 17% of the 5-hour allowance
• 3% of the weekly allowance

I asked Codex afterward to account for what it had actually read and done. It acknowledged some avoidable context use (a broad search and a full diff), but it had not performed a repository-wide audit. It did not inspect unrelated production engines, the shared architecture projects, API/persistence code, or even the relevant production engine implementation.

The implementation itself was non-trivial, so I do not expect it to be free. However, the resulting quota cost still seems disproportionate, especially after deliberately optimizing the workflow for minimal context.

More importantly, today alone I have already consumed almost half of my weekly allowance doing ordinary, tightly scoped application development. At this rate, the weekly allowance makes sustained development impractical.

This is now significantly affecting how I can use Codex. I am spending substantial effort designing prompts around the quota system, splitting work unnaturally, restricting useful inspection, and monitoring every task's percentage consumption. Even with these optimizations, the improvement is small.

I also specifically optimized repository context to test whether my project documentation was causing the high usage:

• added a very small repository-level AGENTS.md;
• added a small application-scoped AGENTS.md that tells Codex not to rediscover unrelated projects/modules;
• reduced the application's main README.md from roughly 18 KB / 153 lines to 6.6 KB / 87 lines, turning it primarily into an authority/navigation router;
• kept detailed authority documents separate so Codex only needs to inspect them when the task actually requires them;
• used narrowly scoped prompts explicitly prohibiting broad repository searches, broad test suites, full Git diffs, and unnecessary cross-module inspection.

Despite these changes, quota consumption improved only slightly. A recent narrowly scoped task still consumed approximately 17% of the 5-hour allowance and 3% of the weekly allowance.

This is important because I have now actively tested whether excessive repository documentation, automatic project context, broad exploration, or poor prompt scoping were responsible for the high consumption. They do not appear to explain the magnitude of the quota burn.

I am extremely unhappy with the current usage economics. Codex is useful for this workflow, but I cannot reasonably continue using it for normal development if a handful of focused implementation tasks can consume such a large portion of a weekly allowance.

I would particularly appreciate clarification from OpenAI on:

1. whether the effective weekly metering/accounting for gpt-5.6-sol has changed;
2. what actually determines the 5-hour and weekly percentage consumption;
3. whether cached input, tool output, reasoning, repeated context, or agent-side repository reads are charged differently than before;
4. whether there is currently a known regression affecting Codex App quota consumption;
5. whether users can get any per-session usage breakdown explaining why a particular task consumed X% of the weekly allowance.

At this point I have tried reducing repository context, narrowing prompts, reducing cross-module exploration, and isolating tasks into separate chats. The high quota burn persists.

This no longer looks to me like something I can solve simply by writing better prompts.