Skip to content

Codex quota was exhausted again during a short working session. #28727

Open

Description

@excessive-eng

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

Version 26.611.61753

What subscription do you have?

PRO x5

What platform is your computer?

MacOS

What issue are you seeing?

Additional update: Codex quota was exhausted again during a short working session.

I am adding another observation from the same Codex session.

Session ID:
019e4f6c-c66b-7072-8678-f4370b9c5b86

Timeline:

14:14
Context: 179,518 / 258K
5-hour quota remaining: 80%
7-day quota remaining: 80%

14:19
Context: 186,991 / 258K
5-hour quota remaining: 74%
7-day quota remaining: 80%

15:06
Context: 93,534 / 258K
5-hour quota remaining: 35%
7-day quota remaining: 74%

15:20
Context: 93,534 / 258K
5-hour quota remaining: 25%
7-day quota remaining: 72%

15:43
Context: 143,431 / 258K
5-hour quota remaining: 6%
7-day quota remaining: 69%

15:58
Context: 143,431 / 258K
5-hour quota remaining: 0%
7-day quota remaining: 68%

Codex then became unavailable with the message that the Codex message limit was exhausted.

This means that within approximately 1 hour 44 minutes, the 5-hour quota dropped from 80% to 0%, and the 7-day quota dropped from 80% to 68%.

This happened during a limited number of user actions. The consumption still appears disproportionate and not transparent.

Important observation:

Between 15:43 and 15:58, the context size remained unchanged at 143,431 / 258K, but the 5-hour quota still dropped from 6% to 0%.

I also monitored local macOS process activity during the period. The system showed load, but the visible terminal output did not clearly attribute this load to Codex or ChatGPT specifically. This makes it impossible for me to verify whether the quota depletion was caused by an actual Codex task, background activity, delayed accounting, or a quota tracking issue.

Please investigate this session and provide a detailed usage breakdown showing:

  • exact charged operations;
  • timestamps;
  • source/client;
  • task or session ID;
  • whether quota was consumed by user prompts, background execution, retries, indexing, tool calls, or delayed reconciliation;
  • why quota continued decreasing even when context size did not change.

This is now the second time today that Codex became blocked due to 5-hour quota exhaustion under unclear circumstances.

As a paying user relying on Codex for professional work, I need transparent and auditable quota accounting.

Image Image Image Image Image Image

What steps can reproduce the bug?

  1. Open Codex in the ChatGPT macOS application.
  2. Start a normal Codex work session.
  3. Perform a small number of ordinary tasks involving file analysis and modifications.
  4. Observe the quota indicators in the session status panel.
  5. Continue working while periodically recording:
    • 5-hour quota remaining;
    • 7-day quota remaining;
    • session ID;
    • context size.
  6. Observe that the 5-hour quota decreases significantly faster than expected relative to the visible amount of work performed.
  7. Continue until the 5-hour quota reaches zero and Codex becomes unavailable.

Observed example from my session:

Session ID:
019e4f6c-c66b-7072-8678-f4370b9c5b86

14:14
5-hour quota: 80%
7-day quota: 80%

15:58
5-hour quota: 0%
7-day quota: 68%

Codex access was blocked due to exhaustion of the 5-hour limit.

Additional observation:

During part of the session, the context size remained unchanged while the available quota continued decreasing.

I cannot provide a deterministic reproduction sequence because the issue appears related to quota accounting rather than a specific user action. However, the behavior has now occurred multiple times during normal usage.

What is the expected behavior?

No response

Additional information

No response

Activity

  1. added
    bugSomething isn't working
    rate-limitsIssues related to rate limits, quotas, and token usage reporting
    on Jun 17, 2026
  2. github-actions commented on Jun 17, 2026

    @github-actions
    Contributor
  3. waleedajaz990-web commented on Jun 21, 2026

    @waleedajaz990-web

    facing this same issue +1

  4. excessive-eng commented on Jun 30, 2026

    @excessive-eng
    Author
    Image

    Мониторинг 30.06.2026.rtf

    Codex quota decreases while idle and can reach zero before first interaction

    Summary

    I believe there is an issue with how my Codex usage quota is being accounted for.

    Over multiple days I have repeatedly observed that my remaining Codex quota decreases while I am not actively using Codex.

    The most recent observation is the strongest evidence so far:

    • I did not use Codex at all before launching it today.
    • I simply opened the application.
    • Immediately after launch I was presented with:

    “You have run out of Codex messages.”

    No prompt had been submitted.

    No project had been opened.

    No interaction with Codex had occurred.

    This means the remaining quota reached zero before the first user action of the day.

    ⸻

    Previous observations

    For several days I have documented the following behavior:

    • remaining quota decreases while Codex is idle;
    • remaining quota decreases even when I am not sending prompts;
    • both the 5-hour quota and the 7-day quota decrease over time;
    • the reduction continues while the application is simply open;
    • in some cases the reduction continues even after periods without any interaction.

    This has been reproduced multiple times.

    ⸻

    Today’s reproduction

    Today I intentionally performed another clean test.

    Test conditions

    • Codex was not used before the test.
    • No prompts were submitted.
    • No projects were opened.
    • No local tasks were started manually.
    • No repositories were indexed manually.

    I simply launched Codex.

    Immediately after launch the application reported that my message quota had already been exhausted.

    ⸻

    Monitoring performed

    To rule out local causes I prepared continuous monitoring.

    I collected:

    • process lists;
    • CPU usage;
    • memory usage;
    • running ChatGPT/Codex processes;
    • timestamps over many hours.

    The monitoring log shows:

    • ChatGPT and ChatGPTHelper processes were present;
    • no sustained CPU activity corresponding to model inference;
    • no obvious local workload capable of consuming the amount of quota observed;
    • no repeated foreground requests were executed by me.

    The complete monitoring log is attached.

    ⸻

    Additional investigation already performed

    Before opening this report I attempted to eliminate common local causes.

    Environment

    • macOS
    • Latest ChatGPT desktop application
    • Codex

    I verified

    • no duplicate ChatGPT processes;
    • no orphan Codex processes;
    • no abnormal startup items;
    • no login items repeatedly launching Codex;
    • no obvious extensions responsible for repeated execution;
    • no obvious background jobs started by me.

    I also inspected the local Codex and ChatGPT application data directories.

    Nothing indicates continuous local execution of prompts.

    ⸻

    Existing community reports

    After creating this issue I noticed several reports describing very similar behavior, including:

    • quota decreasing while idle;
    • Codex becoming blocked without user interaction;
    • unexplained background quota consumption.

    This suggests the issue may not be isolated to a single installation.

    ⸻

    What would help identify the problem

    At the moment users only see a remaining percentage.

    That is insufficient to determine what actually consumed quota.

    A usage ledger would make this immediately diagnosable.

    Ideally each quota change would include something like:

    • foreground_prompt
    • background_task
    • project_indexing
    • retry
    • resume
    • memory_writer
    • server_adjustment
    • session ID
    • request ID
    • model
    • timestamp

    Without this information it is impossible to determine whether quota was consumed by:

    • foreground requests,
    • background processing,
    • delayed accounting,
    • or an accounting bug.

    ⸻

    Request

    Could you please investigate the quota accounting for my account?

    Specifically, could you inspect the internal usage ledger between my previous Codex session and my first launch today?

    I would like to know:

    1. Which events were recorded as quota-consuming.
    2. Whether any background operations consumed message quota.
    3. Whether project indexing, synchronization or reconciliation consume the same quota.
    4. Whether this behavior is expected.
    5. If expected, how users can distinguish foreground usage from background quota consumption.

    If this is not expected behavior, I believe there may be an issue in the quota accounting system.

    ⸻

    Attachments

    I am attaching:

    • screenshots showing quota decreasing over time;
    • screenshots showing the application opening directly into the “quota exhausted” state;
    • continuous monitoring logs covering many hours of idle operation;
    • previous screenshots documenting the gradual quota reduction.

    ⸻

  5. excessive-eng commented on Jul 1, 2026

    @excessive-eng
    Author

    I would like to formally escalate this issue.

    Over the past several days I have spent many hours investigating what appears to be incorrect Codex quota accounting.

    I have already submitted multiple reports and attached extensive evidence, including:

    • screenshots;
    • long-term process monitoring;
    • terminal logs;
    • repository isolation tests;
    • local environment investigation;
    • reproduction attempts.

    Despite all of this work, I have not received any substantive response addressing the technical observations.

    Instead, every new report is automatically marked as a potential duplicate, without any indication that the evidence has actually been reviewed.

    At this point my concern is no longer only the quota itself.

    It is the complete lack of transparency regarding how quota is consumed.

    The product UI tells me:

    “You have run out of Codex messages.”

    However, the pricing documentation describes the plans in terms of usage, not messages.

    Those are fundamentally different concepts.

    As a paying customer, I currently have no way to determine:

    • what exactly consumed my quota;
    • whether foreground prompts, background tasks, retries, indexing, session recovery, or server-side reconciliation are counted;
    • why quota decreases while no visible task is running;
    • why quota can already be exhausted before my first interaction after launching Codex.

    I have attempted to eliminate every reasonable local explanation.

    I investigated:

    • Git repositories;
    • workspace size;
    • local processes;
    • CPU usage;
    • local Codex task databases;
    • application caches.

    Nothing explains the observed quota behaviour.

    I am not asking for speculation.

    I am asking for transparency.

    Please review my attached evidence and provide a technical explanation based on the internal usage records for my account.

    If Codex usage is based on something other than foreground user messages, then the product should expose that information.

    At minimum, users need access to an audit trail (charge ledger) showing:

    • timestamp;
    • event type;
    • quota delta;
    • session/thread ID;
    • request ID;
    • model;
    • source of consumption.

    Without this information it is impossible to verify whether quota was consumed by my own actions or by background operations.

    A professional paid product should provide users with sufficient information to understand why their purchased quota has been exhausted.

  6. excessive-eng commented on Jul 2, 2026

    @excessive-eng
    Author

    Вот так будет значительно сильнее и честнее.

    ⸻

    After further investigation, I cannot conclusively determine whether the background automation was responsible for my quota consumption.

    Unfortunately, I had to upgrade to a higher Codex plan before I could complete a proper long-term comparison of quota usage during periods of complete inactivity. As a result, I lost the opportunity to accurately measure whether the quota was decreasing without any user interaction.

    However, during my investigation I discovered several local background LaunchAgents that were automatically starting Codex-related processes (codex exec, autowake, cua_node, SkyComputerUseService). After disabling these background jobs, only the normal Codex desktop application remained running.

    For other users who suspect unexpected background activity, I recommend checking their system with the following commands.

    1. Check for background Codex processes

    ps -axo pid,ppid,%cpu,%mem,time,command |
    grep -Ei "codex exec|autowake|cua_node|SkyComputerUseService" | grep -v grep

    1. Stop all detected background processes

    pkill -f "codex exec"
    pkill -f "autowake"
    pkill -f "cua_node"
    pkill -f "SkyComputerUseService"

    1. Check LaunchAgents

    launchctl list | grep -Ei "codex|autowake|enir"

    1. Remove any unwanted LaunchAgents

    launchctl remove <agent_name>

    1. Find LaunchAgent plist files

    find ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons
    -iname "codex" -o -iname "enir" -o -iname "autowake" 2>/dev/null

    1. Disable the local autowake directory (if present)

    mv ~/.codex/autowake ~/.codex/autowake_DISABLED_$(date +%Y%m%d_%H%M%S)

    1. Verify that only the normal Codex application remains

    ps -axo pid,command |
    grep -Ei "codex exec|autowake|cua_node|SkyComputerUseService" | grep -v grep

    I hope these steps help other users troubleshoot unexpected background Codex activity while investigating unusual quota consumption.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingrate-limitsIssues related to rate limits, quotas, and token usage reporting

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions