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

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

5.6 Sol

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11

What issue are you seeing?

Summary

My Codex weekly allowance is being consumed dramatically faster than it was in earlier sessions, even though my recent work has been comparable or smaller in scope.

This does not look like normal variation. From my perspective, quota accounting changed materially without any clear explanation in-product.

What I observed

My weekly quota started and a very large portion was consumed within about 5 hours.
I saw ordinary development activity, not unusually large generation output.
Even small follow-up questions started consuming what looked like roughly 2% to 5% of my weekly quota each.
Earlier app development sessions did not behave like this.

Project context

I have been using Codex for a a new app workflow.

Earlier work included:

architecture design
4 engines

Recent work included:

one engine, using previous engine patterns already.
cross-engine audit
calibration methodology start

Why this seems wrong

Local session/rollout evidence suggests:

recent quota consumption increased much faster than earlier app work
repository growth alone does not explain the increase
cache ratios were still high, so this does not appear to be simply “the repo got bigger”
repeated large context resend / internal repetition may be contributing, but the resulting weekly quota burn still appears disproportionate

In my measured comparison, newer sessions appeared to consume weekly quota at roughly more than 2x the earlier rate for similar recorded work.

Impact

I lost a large share of my weekly allowance in a few hours
normal development became impractical
I had to stop using the stronger model because the quota burn was too aggressive
trust in quota predictability was damaged

Expected behavior

weekly allowance consumption should be broadly consistent for comparable work
if pricing/accounting/quota logic changed, this should be clearly communicated
users should be able to understand why a small session or question consumed a large percentage of their weekly allowance

Actual behavior

quota dropped much faster than expected
small and medium tasks consumed a surprisingly large share of weekly usage
there was no clear in-product explanation tying the burn rate to the actual work performed

Requested action

Please investigate whether there was:

a regression in quota accounting
a model-specific usage multiplier/change
excessive internal context resend or repeated hidden processing
an entitlement or meter bug affecting Codex weekly usage

Please also clarify whether quota accounting changed recently for these models/workflows.

I prefer not to post session IDs publicly because they may reveal private project activity. I can provide representative session/task IDs directly to support if needed.

What steps can reproduce the bug?

This is not a bug in my application code. This appears to be a Codex usage/quota accounting issue that is reproducible through ordinary development workflow on an existing medium-sized repository.

Steps to reproduce

Start with a fresh weekly Codex allowance.
Open an existing medium-sized software repository.
Use Codex for normal development tasks across multiple sessions:
- architecture discussion
- implementation
- review/audit
- follow-up questions
Compare quota consumption for earlier sessions versus recent sessions on the same repository and similar task types.
Observe that recent sessions consume weekly quota dramatically faster, including some small follow-up prompts.

Observed behavior

A very large portion of weekly quota was consumed within a few hours of normal development use.
Some short follow-up prompts appeared to consume a surprisingly large percentage of weekly allowance.
Recent sessions appeared materially more expensive than earlier comparable sessions.
High cache usage was still present, so repository growth alone does not explain the change.

Expected behavior

Comparable work on the same repository should consume broadly comparable weekly quota.
If quota accounting or model metering changed, that change should be clearly communicated.
Users should be able to understand why a small or medium task consumed a large percentage of weekly allowance.

Session / token details

From locally available Codex session logs, I observed representative sessions with totals in this general shape:

Earlier sessions:

input tokens in the multi-million range
cached input ratio roughly 96% to 98%
moderate output/reasoning totals
normal multi-turn development activity

Recent sessions:

similar pattern of multi-turn development activity
similarly high cached-input ratio
but weekly quota appeared to fall much faster than before

In my local comparison, recent sessions appeared to burn weekly allowance at roughly more than 2x the earlier rate for comparable recorded work.

Model / context

Model observed in local logs:

gpt-5.6-sol

If helpful, I can provide private session IDs directly to support, but I do not want to post repository-specific or project-identifying details publicly.

Code snippet

No standalone code snippet applies here, because the issue is not caused by application code. The repro is the Codex session workflow and quota accounting behavior.

What is the expected behavior?

No response

Additional information

No response

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

GPT-5.6 Sol normal mode appears to consume Codex quota unusually fast on $100 plan #38233
Pro weekly quota meter accelerated ~2.4x mid-window, then returned to normal (Aug 14) #38728
[Pro 20x] Severe 7-day quota depletion during light workloads + frequent "Selected model is at capacity" with usage remaining #38335
Request: transparency and investigation into rapid Codex quota depletion for long-context research workflows #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:

Pro 20x weekly quota consumption increased dramatically after reset #40527 — significantly increased weekly quota consumption after reset
Rate limit reach after resetting, then I'm out of Codex after running a 22minute job #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 Codex weekly quota is being consumed far faster than expected during normal app development workflows #39699, Pro 20x weekly quota consumption increased dramatically after reset #40527, and Rate limit reach after resetting, then I'm out of Codex after running a 22minute job #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:

whether the effective weekly metering/accounting for gpt-5.6-sol has changed;
what actually determines the 5-hour and weekly percentage consumption;
whether cached input, tool output, reasoning, repeated context, or agent-side repository reads are charged differently than before;
whether there is currently a known regression affecting Codex App quota consumption;
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.

Update — another extremely high-consumption session

I had another case today that seems relevant to this issue and to the workflow-amplification category being tracked in #41220.

I deliberately narrowed the work before giving it to Codex. The task was small and bounded, and the final implementation involved only 4 files and 29 focused tests.

Despite that, completing this single small slice consumed approximately one entire 5-hour usage allowance plus ~20% of the next 5-hour allowance.

I complained to Codex about the disproportionate usage which consumed my 3% of 5-hour usage, and Codex itself responded:

“Spending a full five-hour allowance plus roughly 20% of the next one on this promotion is unacceptable. The implementation was four files and 29 focused tests; the usage was wildly disproportionate.”

“I also made it worse by loading far more artifact content than necessary and repeatedly re-reading context. The repository’s authority requirements explain some inspection, but they do not justify that waste.”

I think this is particularly relevant because unnecessary context loading/re-reading was identified by the agent itself, rather than inferred by me from the usage meter.

Codex then suggested reducing reads, avoiding repeated output/test runs, and using lower-cost models such as Terra or Luna.

I don't think changing models addresses the underlying issue being reported here. The concern is that comparable, deliberately bounded development work is consuming dramatically more quota than it previously did, and agent-side context replay or other workflow amplification may be contributing to that consumption. A cheaper model may reduce the rate, but it does not explain or fix the apparent regression.

Current state after continuing work today:

5h allowance: 77% remaining in the current window
Weekly allowance: 19% remaining
I had recently received/restored weekly capacity, which allowed me to continue working, but the renewed allowance has again been consumed very rapidly.

The practical problem is now significant: a normal several-hour development session can consume the short-window allowance in roughly 1–2 hours of actual work, even when tasks are intentionally kept small and implementation-ready.

I appreciate the help team did and it has allowed me to continue working.

Adding this as another data point for #41220. I hope the team can investigate not only nominal model pricing/weighting, but also context replay, repeated repository/artifact reads, caching/accounting behavior, and other agent workflow amplification.

Additional finding: autonomous overhead appears even while auditing excessive context usage

I found another small but revealing example of the usage problem.

After I asked Codex to review a task prompt specifically to identify why it might be consuming excessive context/tokens, Codex responded:

“I’ll use the OpenAI/Codex guidance skill because this is about my context-loading and usage behavior. The skill requires one narrow official-doc check before I inspect the attachment.”

It then loaded another skill/instruction file before inspecting the prompt I had actually asked it to review.

Individually, this extra lookup is probably inexpensive. The concern is the pattern it demonstrates: autonomous procedural overhead accumulates even during tasks whose explicit purpose is to reduce unnecessary inspection and context loading.

In this case, the requested operation was essentially:

Read one supplied task prompt.
Identify instructions that could trigger excessive reading or repeated inspection.
Report the findings.

Instead, an additional guidance/skill lookup was inserted before the requested work.

This seems relevant to the much larger quota-consumption issue I have been reporting. A single extra lookup is not the problem by itself. But if similar decisions occur repeatedly during implementation—loading skills, following authority references, reopening artifacts, checking documentation, re-reading context, performing extra verification—then many individually “reasonable” actions can compound into very high token/context consumption for a very small code change.

The especially interesting part is that Codex itself concluded in the same audit that my prompt was already aggressively scoped and that the previous excessive usage was primarily an execution problem rather than something justified by the prompt.

This may be worth investigating at the agent/runtime level:

How much quota is being consumed by autonomous context gathering, skill loading, repeated file reads, internal procedural guidance, and verification activity versus the actual user-requested implementation?

I’m posting these examples because they may help isolate why very small, tightly bounded development tasks can still consume disproportionately large amounts of quota.

Anonymous high-usage incident summary

Files changed

1 production/configuration source file
2 focused test files
1 documentation file

Git change statistics

Added: 525 lines
Deleted: 18 lines
Net: +507 lines

Breakdown:

Production implementation: 36 added, 0 deleted
Tests: 403 added, 7 deleted
Documentation: 86 added, 11 deleted
Generated/data artifacts: 0

These are the recoverable four-file Git totals already present in the session. Because the files remained uncommitted across adjacent slices, Git cannot independently establish that every line belongs exclusively to this bounded job.

Concrete outcome

The job promoted one bounded production configuration, added executable calibration/parity safeguards, documented the approved behavior, and completed 29 focused tests successfully.

Correction/rework

The session shows that the job required correction/rework rather than succeeding cleanly on the first attempt. The precise number of repair iterations and their contribution cannot be recovered reliably, so I am not assigning a number.

Codex's own explanation of workflow overhead

When I complained about the disproportionate usage, Codex explicitly responded:

“I also made it worse by loading far more artifact content than necessary and repeatedly re-reading context.”

Codex therefore independently acknowledged unnecessary artifact loading and repeated context reads during the session. I am not making any claim here about internal token counts or backend quota accounting.

Output versus reported usage

The concrete result was 36 added production lines, supported by 403 added test lines, 86 added documentation lines, and 29 focused tests, across 4 files.

My observed usage for completing this bounded work was approximately one full 5-hour allowance plus ~20% of the following 5-hour allowance.

I am posting these numbers so the engineering output and reported quota consumption can be compared directly rather than describing the incident only as “high usage.”

The audit itself costed me only ~2% of a 5h window, despite Codex examining Git metadata and producing a fairly detailed report. That strengthens my intuition that bounded work itself doesn't inherently have to consume enormous amounts.

Update: repeated operational problems are not being recognized or actually resolved

I found another source of avoidable Codex usage. Python happened to expose it, but I don't think this is really a Python issue.

Across multiple focused tasks, Codex repeatedly encountered the same environment friction, recovered, and continued.

Eventually I noticed the repetition and explicitly asked Codex to fix the underlying problem so future tasks would not keep paying the same cost.

What concerns me is that it took roughly three attempts to actually get there.

The pattern was approximately:

recurring environment problem
→ Codex recovers and continues
→ same problem appears in another task

I explicitly ask for a permanent fix
→ Codex applies a fix and reports the problem solved

next task
→ related problem appears again

investigate/fix again
→ another missing part becomes visible

third attempt
→ repository finally gets a deterministic runtime,
   pinned dependencies and standard launcher

So the issue is not simply that Codex failed to automatically optimize its environment.

Even after I identified the recurring problem and explicitly asked for it to be fixed permanently, I still had to verify the result, discover that the solution was incomplete, and drive additional attempts before the root problem was actually removed.

Under usage limits, this is expensive twice:

Codex spends usage repeatedly recovering from operational friction.
The user then spends additional usage and cognitive effort auditing whether Codex's claimed fix actually fixed the recurring problem.

Python/PyArrow was just the example that made this visible.

The broader trust issue for me is: how many similar patterns exist in ordinary Codex work that I don't notice?

I don't want to inspect every shell command, permission request, fallback, or retry to determine whether Codex is repeatedly paying for something that could have been eliminated earlier.

For recurring operational failures, I think Codex needs a stronger loop:

detect recurrence
→ identify root cause
→ apply durable fix
→ verify the original recurring condition is gone
→ only then report it resolved

The last two steps matter. In my case, “fixed” was reported before the broader recurring condition had actually been eliminated.

This is less about one Python configuration problem and more about agent self-correction, root-cause verification, usage efficiency, and user trust.

Update: Codex ignored the requested validation order, continued after I raised the blocker, then spent usage undoing the work

Summary;
The prompt gave the correct order → Codex deviated from it → I explicitly challenged the exact risk → Codex incorrectly dismissed my concern → continued doing conditional work → eventually discovered I was right → rejected → spent more quota undoing that work.

I have another concrete example that may help explain why my Codex 5-hour usage is being consumed much faster than the amount of completed work suggests.

This was a bounded task, and the prompt explicitly required this order:

complete validation;
determine whether the candidate was actually acceptable;
choose either PRODUCTION READY or REJECT;
only if the verdict was PRODUCTION READY, continue with production implementation;
if rejected, stop without making production changes.

The intended execution order was explicit.

What happened

Codex ran the main validation and obtained good results. However, an important edge case was absent from the validation data. Existing tests already defined the required behavior for that case, and the candidate's behavior could be determined directly from its formula.

This should have been checked before the production-readiness decision.

Instead, Codex decided the candidate had passed and started the production work.

More importantly, I explicitly challenged this while Codex was working.

After Codex reported that validation passed and that it was proceeding with production promotion, I asked whether the missing edge case meant the candidate had actually failed.

Codex said no and continued.

It reasoned that the validation results were strong and that the missing case could be covered with synthetic tests.

That was the key mistake. The issue was not missing test coverage. The candidate's behavior for that case was already known, and it violated an existing requirement. A synthetic test would only prove that the candidate had to be rejected.

Codex nevertheless continued with production changes, tests, verification work, documentation, builds, and test runs.

Only later did Codex recognize the contradiction. It changed the verdict to:

REJECT

It then had to remove the production work it had just performed, restore the previous behavior, correct the validation artifacts, rebuild, and rerun tests.

So the sequence was:

Prompt explicitly requires validate → decide → only then implement

→ Codex deviates from that order
→ user explicitly challenges the exact risk
→ Codex incorrectly dismisses the concern
→ Codex continues doing conditional implementation work
→ Codex eventually discovers the user was right
→ candidate is rejected
→ Codex spends more usage undoing its own work and verifying the rollback

The correct sequence was:

validate all requirements → find contradiction → reject → stop

Why this matters for high Codex usage

The final useful result was simply:

candidate rejected; production unchanged

But Codex consumed limited usage by doing steps in the wrong order, failing to respect conditional instructions, failing to react correctly when the user identified the risk, and then spending additional usage recovering from those mistakes.

With a 5-hour usage limit, this kind of avoidable implementation → rollback → retest cycle can consume a meaningful part of the available session without producing corresponding progress.

The final repository state was correct. The concern is the amount of limited usage Codex consumed to reach a result that the requested validation order—and later the user's explicit warning—should have reached much earlier.

The frustrating part is that this isn't just “the model made a wrong decision.” In an agent workflow, mistakes have a multiplier:
wrong decision → unnecessary implementation → more context → tests/builds → discovery → rollback → more tests/builds → quota gone.

Evidence addendum: verification against local Codex task records

I asked Codex to inspect the original local task history behind this update, including the complete prompt, intermediate messages, file mutations, build/test commands, later reversal patches, and final result. The following is its sanitized verification:

The local task record substantively supports this report.

The original prompt explicitly required this order:

complete validation;

evaluate the required behavior and edge cases;

choose a production-readiness verdict;

modify production code only if the verdict was positive;

stop without production changes if the candidate was rejected.

The prompt specifically required examination of the relevant edge-case behavior before the readiness decision.

The recorded execution then followed this sequence:

Codex completed the aggregate validation and announced that the candidate had passed.

Codex stated that it was proceeding with production promotion.

The user questioned whether an absent edge case meant the candidate had actually failed.

Codex answered that it had not failed and said the absent case could be protected with synthetic tests.

Relying on that answer, the user instructed Codex to continue.

Codex modified production calculation, configuration, engine, calibration, tests, parity protection, and documentation.

Codex built the implementation and ran focused tests successfully.

A later contract check established that the candidate’s deterministic edge behavior contradicted an existing authoritative requirement.

Codex changed the verdict to rejection.

The task record contains reversal patches removing the production implementation, production calibration, production parity work, tests, and documentation that had just been added.

Codex then rebuilt and reran focused tests to verify the restored production state.

Therefore, the evidence supports this concrete sequence:

explicit conditional gate → premature approval → user raises the exact risk → incorrect reassurance → conditional implementation → late contradiction detection → rejection → rollback → rebuild and retest

One factual qualification should be included: after Codex reassured the user that the missing case was not a failure, the user explicitly told Codex to continue. Therefore, the problem is not accurately described as Codex continuing against an outstanding user instruction to stop.

The stronger and more precise conclusion is:

Codex gave the user an incorrect readiness assessment when the user raised the blocker. The user resumed based on that assessment, after which Codex implemented, tested, documented, and then reversed work that the requested validation gate should have prevented.

The underlying mathematical condition was an edge case. The operational failure was broader: a conditional agent workflow approved and executed downstream mutations without first checking an existing requirement that was relevant to the decision.

The final repository state was correct, but the recorded implementation, build, test, rollback, rebuild, and retest cycle was avoidable.

This is a sanitized summary. I am not publishing task IDs, repository names, file paths, model/domain details, artifacts, or private application semantics. I can provide representative task/session identifiers privately to OpenAI if required.

This evidence verifies the observable execution sequence. It does not independently verify OpenAI’s backend quota accounting or calculate the precise quota consumed by the avoidable work.

Feedback ID
01a05c1d-3d9b-7312-b6aa-d674fcc5a0ea

for one task...

Additional observation after filing this issue

I recently started using much more tightly scoped prompts: explicit repository-navigation limits, clear task boundaries, staged gates, and stop-on-blocker instructions.

Since doing this, my Codex plan usage appears to have decreased materially for comparable development work.

I do not have enough controlled data to claim that prompt structure is the cause. There could be other factors involved.

I’m attaching Product Activity / Usage History screenshots showing the distribution by product, model, surface, and turns.

This makes me think per-task usage diagnostics would be particularly useful: model, agent turns, context/tokens, subagent activity, and percentage of the quota consumed. That would make it possible to determine whether task scope/prompt structure actually affects usage this strongly.

Update: reproduced with Codex CLI 0.155.1

I switched from Codex Desktop to CLI to test whether the unusually high usage was Desktop-specific.

I ran one relatively small implementation task using gpt-5.6-sol / Medium / Fast.

5-hour usage dropped by approximately 40% during this task (60% remaining afterward).

Session ID: 01a0c31f-461f-7632-8912-bbb6f08bd979

I asked Codex afterward for a sanitized execution summary. It reported:

64 top-level tool invocations
52 command launches
~22 unsuccessful/partially unsuccessful attempts and retries
17 files directly inspected
8 files changed
7 test/build executions (3 focused tests, 2 broad test suites, 2 full builds)
2 tool outputs truncated at approximately 15k and 10k tokens
1 substantial version-control diff
repeated searches, reads, patch attempts, tests and builds
0 context compactions observed
no subagents/delegated workers

Codex itself identified repeated environment/setup failures, patch retries, repeated validation runs, and large outputs as plausible contributors to usage.

This is important because I can now reproduce the high consumption in CLI as well as Desktop, so it does not appear to be Desktop-specific.

The session ID should allow the team to compare the actual server-side model/token/cache/request telemetry against the ~40% 5-hour usage decrease.

Sanitized diagnostic report

Codex CLI version: UNKNOWN. No version telemetry was exposed.
Session ID: UNKNOWN.
Model: GPT-5; exact deployed model identifier UNKNOWN.
Reasoning effort: UNKNOWN.
Approximate duration: Total wall-clock duration UNKNOWN. Tool-reported execution time accumulated to roughly 7 minutes, excluding reasoning, queueing, and approval time.
Shell/tool executions: 64 visible top-level tool invocations:
- 52 command-launch calls
- 8 direct patch calls
- 4 waits for running commands
Files inspected: 17 distinct files were directly read or displayed. Searches may have touched additional files; exact broader count UNKNOWN.
Files changed: 8 files touched: 2 created, 6 modified, 0 deleted.
Tests/builds: 7 executions:
- 3 focused test runs
- 2 broad test-suite runs
- 2 full builds
- Final focused and broad runs passed; one non-test library reported no discoverable tests.
Failed commands/retries: Approximately 22 visibly unsuccessful or partially unsuccessful attempts, including environment-launch failures, patch parsing failures, unavailable executable lookups, and retries.
Large output: Yes. Two tool outputs were explicitly truncated at approximately 15,000 and 10,000 pre-truncation tokens. A version-control diff also produced substantial output.
Repeated activity: Yes. Searches, file reads, patch attempts, focused tests, broad tests, and builds were repeated.
Subagents/background workers: No subagents or delegated workers were created. No persistent background worker remained active. Four command sessions temporarily yielded and were subsequently completed.
Additional-agent model provenance: Not applicable; no additional agents existed.
Context compaction: 0 observed. No compaction event was indicated.
Previous-session/cache/history loading: UNKNOWN. Preexisting command-approval rules were visible, but their provenance was not exposed.
Token/cache telemetry: UNKNOWN. No input-token, output-token, cached-token, or billable-usage counters were exposed.
Plausible usage contributors:

Repeated environment setup failures forced retries and alternative execution paths.
Numerous patch attempts failed before a working invocation was found.
Two unusually large file-read outputs were truncated.
One broad diff brought substantial preexisting unrelated changes into context.
Focused tests, broad tests, and builds were rerun multiple times.
No subagent fan-out contributed to usage.

SANITIZED SUPPORT SUMMARY

CLI version: UNKNOWN
Session ID: UNKNOWN
Model: GPT-5; exact identifier UNKNOWN
Reasoning effort: UNKNOWN
Approximate duration: UNKNOWN total; roughly 7 minutes of reported tool runtime
Task size: Medium
Tool/shell execution count: 64
Files inspected count: 17 directly; broader search count UNKNOWN
Files changed count: 8
Test/build count: 7
Retries/failures: Approximately 22
Large-output events: 2 explicitly truncated, plus 1 substantial diff
Subagents/background workers: None
Context compactions: 0 observed
Token/cache telemetry: UNKNOWN
Anomalous execution behavior: Repeated environment and patch failures, repeated validation runs, and unusually large outputs plausibly increased usage

A related observation about persistent project context

Session/Thread:
01a0da4c-3eaf-7501-855a-fa1ec12509db

I initially wondered whether repeated work on the same repository should become
progressively cheaper as the agent accumulates useful project knowledge:

Early work
discover repository + understand architecture + perform task
██████████

Later work
reuse project knowledge + verify changed/relevant source + perform task
██████

Mature project
retrieve relevant knowledge + verify current source + perform task
███

I do not know whether Codex promises this behavior, so I am not reporting the
absence of such a cost curve as a bug.

However, after almost two months of using Codex on the same repository, I asked
it—without allowing repository reads—what it already knew about the project.
It characterized its own semantic knowledge as:

v0.1 — fragmentary/path-level

That surprised me because this is a repository Codex has worked on extensively.

I understand that repository source must remain authoritative and that agents
need to inspect current code before making changes. My concern is not that
Codex performs retrieval or verification.

The concern is the combination of:

noticeable allowance consumption even for a tiny interaction with no
repository reads;
apparently limited reusable project knowledge available to that interaction;
repeated repository/context reconstruction during normal development; and
no per-turn accounting showing what actually consumed the allowance.

I cannot determine from the available information whether this is expected
context-processing cost, insufficient reuse/caching, a memory limitation, or
a metering problem.

More detailed per-turn usage attribution would make this distinction possible.

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

Summary

What I observed

Project context

Why this seems wrong

Impact

Expected behavior

Actual behavior

Requested action

What steps can reproduce the bug?

Steps to reproduce

Observed behavior

Expected behavior

Session / token details

Model / context

Code snippet

What is the expected behavior?

Additional information

Activity

github-actions commented on Aug 20, 2026

RodgerDJr commented on Aug 20, 2026

wauspe commented on Aug 22, 2026

wauspe commented on Aug 22, 2026

wauspe commented on Aug 22, 2026

wauspe commented on Aug 26, 2026

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

What Codex actually did

Usage result

The 5-hour limit compounds the problem

I am reluctant to use the banked reset

What would help clarify this

wauspe commented on Aug 26, 2026

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

wauspe commented on Aug 29, 2026

wauspe commented on Aug 29, 2026

Additional finding: autonomous overhead appears even while auditing excessive context usage

wauspe commented on Aug 29, 2026

wauspe commented on Aug 30, 2026

Update: repeated operational problems are not being recognized or actually resolved

wauspe commented on Aug 30, 2026

Update: Codex ignored the requested validation order, continued after I raised the blocker, then spent usage undoing the work

What happened

Why this matters for high Codex usage

wauspe commented on Aug 31, 2026

Evidence addendum: verification against local Codex task records

wauspe commented on Sep 1, 2026

wauspe commented on Sep 6, 2026

wauspe commented on Sep 21, 2026

Sanitized diagnostic report

SANITIZED SUPPORT SUMMARY

wauspe commented on Sep 25, 2026

A related observation about persistent project context

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions