Codex usage limit decreases without corresponding user activity

Open 💬 7 comments Opened Jun 18, 2026 by excessive-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)?

Version 26.611.62324

What subscription do you have?

pro 5x

What platform is your computer?

Mac OS Darwin 25.6.0 arm64 arm

What issue are you seeing?

Subject:

<img width="1629" height="1192" alt="Image" src="https://github.com/user-attachments/assets/b162b67a-5775-45af-a605-3f4cfea06746" />
<img width="1629" height="1192" alt="Image" src="https://github.com/user-attachments/assets/19b33c0d-e74f-47d6-8b35-6a9e159b33fd" />
<img width="1629" height="1192" alt="Image" src="https://github.com/user-attachments/assets/6d675d00-07da-42f7-aa2b-f25fbc1b8200" />
<img width="1629" height="1192" alt="Image" src="https://github.com/user-attachments/assets/0a05b657-9094-4d0f-935d-6e16c797f484" />
<img width="1629" height="1192" alt="Image" src="https://github.com/user-attachments/assets/fb1e8a96-f30b-4efb-9088-190030cdb4a2" />
<img width="1629" height="1192" alt="Image" src="https://github.com/user-attachments/assets/8e880c2b-b434-47a0-95ee-8a9983316ead" />
<img width="1629" height="1192" alt="Image" src="https://github.com/user-attachments/assets/3615b4b7-113c-49dc-9f62-8ab35efc3d8b" />

Hello,

I would like to report what appears to be a bug related to Codex usage limits.

Environment:

  • macOS
  • Codex desktop application
  • Workspace contains multiple engineering projects
  • Subscription: paid plan with Codex access

Problem Summary

Codex usage limits decrease significantly even when there is little or no active usage.

I initially suspected that large project size or repository indexing might be responsible. During investigation I performed multiple isolation tests, but the issue remained.

Observed Behaviour

  1. Codex usage limit was exhausted unexpectedly despite normal usage.
  2. After limit reset, usage immediately returned to approximately 98% consumed.
  3. In several cases, the limit continued decreasing while:
  • no prompts were being submitted;
  • no active Codex tasks were running;
  • Codex window was idle;
  • system monitoring showed no significant Codex activity.

Investigation Performed

Phase 1 – Repository analysis

Initial workspace:

  • Main folder: “New project”
  • Size: approximately 7.7 GB
  • File count: approximately 256,468 files

Findings:

  • Root .git repository size: approximately 3.6 GB
  • Repository covered all engineering projects simultaneously.

At first I suspected Codex might be scanning the entire workspace.

Phase 2 – Repository isolation

Actions performed:

  1. Disabled root repository:

mv .git .git_DISABLED_2026-06-18

  1. Created a separate repository only inside project:

New project/НТГ ОРЧ

  1. Initialized new local repository:

git init

  1. Added .gitignore
  2. Verified git status.

Result:

The new repository contained only the project-specific content.

However, the Codex limit issue remained.

Phase 3 – Minimal project test

Created completely separate test workspace:

~/Documents/Test_Codex

Commands executed:

mkdir ~/Documents/Test_Codex
cd ~/Documents/Test_Codex
git init
echo test > README.md

Result:

Even in a nearly empty project containing only README.md, the usage limit continued to decrease.

This suggests the problem is not caused by project size.

Phase 4 – Process monitoring

Continuous monitoring was performed using:

while true; do
date
top -l 1 -o cpu -stats pid,command,cpu,time | head -30
sleep 10
done

Observations:

  • Codex processes remained almost completely idle.
  • CPU usage of Codex processes was effectively 0%.
  • No large indexing activity was visible.
  • No runaway git processes.
  • No continuous file scanning visible.
  • No significant memory growth.

Relevant processes observed:

Codex
Codex (Renderer)
Codex (Service)

The processes remained present but mostly inactive.

Result:

The operating system monitoring does not indicate any workload that would explain rapid consumption of Codex limits.

Additional Observation

I observed multiple situations where:

  • a session completed successfully;
  • Codex was closed or left idle;
  • no new requests were submitted;

yet after some time the usage limit had decreased significantly.

I also observed cases where usage dropped immediately after a reset despite almost no new activity.

Possible Cause

Based on testing, the issue appears unrelated to:

  • project size;
  • number of files;
  • Git repository size;
  • active local processing;
  • active user prompts.

It may be related to:

  • session accounting;
  • background usage accounting;
  • stale sessions remaining associated with the account;
  • server-side usage calculation.

Files Available

I can provide:

  • screenshots of limit behaviour;
  • terminal monitoring logs;
  • repository diagnostics;
  • Git isolation test results.

Please investigate whether usage accounting may be incorrectly attributing consumption to inactive or previously completed Codex sessions.

Thank you.

What steps can reproduce the bug?

I cannot reliably reproduce this intentionally because the issue appears to happen while Codex is idle.

Observed sequence:

  1. Open Codex desktop app on macOS.
  2. Work in a local project.
  3. Stop submitting prompts.
  4. Confirm no Codex task is actively running.
  5. Leave Codex idle or close/reopen it.
  6. Watch the Codex usage indicator after some time.
  7. The remaining Codex limit decreases even though no new prompt was submitted.

Additional isolation test:

  1. Create a minimal empty test project.
  2. Run:

mkdir ~/Documents/Test_Codex
cd ~/Documents/Test_Codex
git init
echo test > README.md

  1. Open this folder in Codex.
  2. Ask one very small prompt, for example: “Reply with one word: test.”
  3. Stop using Codex.
  4. Monitor the usage limit.
  5. The limit still decreases over time, even though the project is minimal and no active task is running.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #28896
  • #28694
  • #28687
  • #27608
  • #28085

Powered by Codex Action

excessive-eng · 1 month ago

Additional evidence collected after opening this issue:

I disabled the original repository metadata and recreated a clean local Git repository for the project to rule out excessive indexing caused by a large Git history.

Before:

  • Parent repository contained approximately 256,000 files.
  • .git directory size was approximately 3.6 GB.

Actions performed:

  • Disabled the original top-level .git repository.
  • Created a new clean repository only inside the active project folder.
  • Verified that the active project contains only a few thousand files.
  • Opened a completely new Codex chat and issued only trivial test prompts.

Observed behavior:

  • Codex successfully answered simple requests.
  • No long-running tasks were active.
  • No cloud execution was requested.
  • No repository-wide analysis was requested.
  • Despite this, the 5-hour Codex quota continued decreasing over time.

This suggests the issue is not caused solely by repository size, Git history size, or active user requests.

The quota appears to continue decreasing even after:

  • closing previous tasks,
  • opening a fresh chat,
  • recreating the repository,
  • issuing only trivial prompts.

Please investigate whether quota accounting, background task attribution, delayed reconciliation, or server-side session activity may be involved.

Necmttn · 29 days ago

This needs a charge ledger, not just a percent gauge. Each quota delta should have an origin such as foreground_prompt, background_task, resume/indexing, retry, memory_writer, or server_adjustment, plus session/thread id, model, token buckets, request id, and observed reset/window id.

That would let users prove the important case here: quota moved while no foreground task was active. Without that split, idle drain, delayed reconciliation, and background work all look the same.

Generated with ax - https://github.com/Necmttn/ax

neilo937-pixel · 10 days ago

I am seeing a possibly related Codex usage-metering issue on a ChatGPT Plus account.

Unlike the original report, I was actively running tasks, but the amount of usage consumed appears highly disproportionate to the workload.

Environment

  • Subscription: ChatGPT Plus
  • Client: Codex desktop app for Windows
  • Codex App version: 26.707.31428
  • App release date shown in About Codex: July 10, 2026
  • Time zone: KST / UTC+9
  • Date observed: July 10, 2026

Exact timeline

The five-hour usage limit reset at exactly 12:07 PM KST. I started the first task immediately after the reset.

Task 1

  • Start: 12:07 PM KST
  • End: 12:17 PM KST
  • Model: GPT-5.6 Terra
  • Reasoning effort: Medium
  • Usage before: approximately 100% remaining
  • Usage after: approximately 26% remaining
  • Duration: approximately 10 minutes

The task was documentation and prompt-governance refactoring.

Visible results:

  • Six Markdown governance documents
  • One Git commit
  • No production execution
  • No runtime code changes
  • No full test suite

Task 2

  • Started shortly after 12:17 PM KST
  • End: 12:54 PM KST
  • Model: GPT-5.6 Luna
  • Reasoning effort: Medium
  • Usage before: approximately 26% remaining
  • Usage after: 0% remaining

The task was substantially smaller than Task 1.

Visible results:

  • Validation of the previously created documentation
  • One prompt-history Markdown update
  • One Git commit
  • One local Git fast-forward
  • No production execution
  • No runtime code changes
  • No full test suite

The entire newly reset five-hour allowance was exhausted in approximately 47 minutes across two documentation-focused tasks.

The Codex app task history shows the timestamps and the model change from Terra to Luna. To my knowledge, no other Codex task, CLI session, IDE integration, or cloud task was running concurrently.

I understand that Codex usage depends on context size, reasoning, tool calls, and internal agent turns rather than only the visible number of file changes. However, this consumption is dramatically higher than my recent experience with GPT-5.5, where I was able to complete several longer implementation tasks within one usage window.

Could the team please investigate whether this may involve:

  • incorrect server-side usage accounting;
  • abnormal context or cache accounting;
  • stale or background sessions being attributed to the account;
  • an account-specific rate-limit or anti-abuse restriction;
  • or a regression in the Codex desktop app usage meter?

I can provide sanitized prompts, completion summaries, exact timestamps, and additional screenshots privately if needed.

<img width="985" height="248" alt="Image" src="https://github.com/user-attachments/assets/6ba03c8d-d4ca-400e-bc50-7340d8916f73" />

excessive-eng · 10 days ago

Hi, thank you for sharing such a detailed timeline.

As far as I can determine, ordinary ChatGPT usage and Codex usage are not directly tied to the same visible quota meter. Otherwise, exhausting and blocking the Codex allowance would presumably also block ordinary ChatGPT usage at the same time. That has not been my experience, although I cannot confirm the exact server-side accounting mechanism.

Your reported consumption still looks unusually high, especially because the entire freshly reset five-hour allowance disappeared during two documentation-focused tasks.

One additional check may be useful. During my own investigation, I discovered that Codex could be running through local background processes and scheduled automations even when I was not manually submitting anything in the desktop interface.

In my case, background commands were launching real autonomous sessions such as:

codex exec --ephemeral --full-auto ...

Those are actual Codex tasks and may consume quota even though no foreground task is visibly running in the desktop application.

Since you are using Windows, I recommend checking the following.

1. Find all Codex-related processes and inspect their command lines

Open PowerShell as Administrator and run:

Get-CimInstance Win32_Process |
    Where-Object {
        $_.Name -match 'codex|node|powershell|cmd' -or
        $_.CommandLine -match 'codex|codex exec|full-auto|automation'
    } |
    Select-Object ProcessId, ParentProcessId, Name, CommandLine |
    Format-List
Pay particular attention to command lines containing:

codex exec
--full-auto
--ephemeral
unexpected project paths
scripts that repeatedly relaunch Codex
Node or PowerShell processes whose command lines reference Codex

The normal Codex desktop application and its renderer/network subprocesses are not automatically suspicious. The important items are autonomous CLI executions or scripts that launch them.
2. Check specifically for active
codex exec
sessions
Get-CimInstance Win32_Process |
    Where-Object { $_.CommandLine -match 'codex\s+exec' } |
    Select-Object ProcessId, ParentProcessId, Name, CommandLine |
    Format-List
If this produces output while no task should be running, a background Codex session is active.
3. Stop only autonomous Codex CLI sessions
First review the output. Then stop the relevant process by its PID:
Stop-Process -Id <PID> -Force
To stop every process whose command line contains codex exec:
Get-CimInstance Win32_Process |
    Where-Object { $_.CommandLine -match 'codex\s+exec' } |
    ForEach-Object {
        Stop-Process -Id $_.ProcessId -Force
    }
This is safer than terminating every process named Codex, because it leaves the normal desktop application alone.
4. Check Windows Task Scheduler
Get-ScheduledTask |
    Where-Object {
        $_.TaskName -match 'codex|openai|automation|autowake' -or
        $_.TaskPath -match 'codex|openai'
    } |
    Select-Object TaskPath, TaskName, State
To inspect the commands executed by matching tasks:
Get-ScheduledTask |
    Where-Object {
        $_.TaskName -match 'codex|openai|automation|autowake' -or
        $_.TaskPath -match 'codex|openai'
    } |
    ForEach-Object {
        [PSCustomObject]@{
            TaskPath = $_.TaskPath
            TaskName = $_.TaskName
            State    = $_.State
            Actions  = ($_.Actions | Out-String).Trim()
        }
    } |
    Format-List
To disable a confirmed unwanted task:
Disable-ScheduledTask -TaskName '<TASK_NAME>' -TaskPath '<TASK_PATH>'
Do not disable anything until its action and origin have been checked.
5. Check startup applications and registry entries
Get-CimInstance Win32_StartupCommand |
    Where-Object {
        $_.Name -match 'codex|openai' -or
        $_.Command -match 'codex|openai'
    } |
    Select-Object Name, Command, Location, User |
    Format-List
Also check the common Run registry keys:
$runKeys = @(
    'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run',
    'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run',
    'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Run'
)

foreach ($key in $runKeys) {
    if (Test-Path $key) {
        Write-Host "`n=== $key ==="
        Get-ItemProperty $key
    }
}
6. Check Windows services
Get-CimInstance Win32_Service |
    Where-Object {
        $_.Name -match 'codex|openai' -or
        $_.DisplayName -match 'codex|openai' -or
        $_.PathName -match 'codex|openai'
    } |
    Select-Object Name, DisplayName, State, StartMode, PathName |
    Format-List
7. Create a timestamped monitoring log
This records relevant processes every 30 seconds:
$log = "$env:USERPROFILE\Desktop\codex_process_monitor.log"

while ($true) {
    "===== $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') =====" |
        Out-File $log -Append

    Get-CimInstance Win32_Process |
        Where-Object {
            $_.Name -match 'codex|node|powershell|cmd' -or
            $_.CommandLine -match 'codex|codex exec|full-auto|automation'
        } |
        Select-Object ProcessId, ParentProcessId, Name, CommandLine |
        Format-List |
        Out-String |
        Out-File $log -Append

    Start-Sleep -Seconds 30
}
Stop monitoring with Ctrl+C.
For a clean test, I would:

record the exact Codex percentage and time;
confirm that no codex exec process is running;
disable any confirmed Codex-related scheduled task;
leave the computer idle without submitting prompts;
take screenshots of the usage meter at regular intervals;
preserve the process-monitoring log.

This does not prove that background activity explains your case. Your two visible tasks may genuinely have consumed the allowance because of context size, model rates, internal turns, or a metering defect. However, eliminating autonomous local sessions makes the evidence much stronger if the quota continues to fall.


Отправлено с iPhone10 июля 2026 г., в 07:25, neilo937-pixel ***@***.***> написал(а):neilo937-pixel left a comment (openai/codex#28908)
I am seeing a possibly related Codex usage-metering issue on a ChatGPT Plus account.
Unlike the original report, I was actively running tasks, but the amount of usage consumed appears highly disproportionate to the workload.
Environment

Subscription: ChatGPT Plus
Client: Codex desktop app for Windows
Codex App version: 26.707.31428
App release date shown in About Codex: July 10, 2026
Time zone: KST / UTC+9
Date observed: July 10, 2026

Exact timeline
The five-hour usage limit reset at exactly 12:07 PM KST. I started the first task immediately after the reset.
Task 1

Start: 12:07 PM KST
End: 12:17 PM KST
Model: GPT-5.6 Terra
Reasoning effort: Medium
Usage before: approximately 100% remaining
Usage after: approximately 26% remaining
Duration: approximately 10 minutes

The task was documentation and prompt-governance refactoring.
Visible results:

Six Markdown governance documents
One Git commit
No production execution
No runtime code changes
No full test suite

Task 2

Started shortly after 12:17 PM KST
End: 12:54 PM KST
Model: GPT-5.6 Luna
Reasoning effort: Medium
Usage before: approximately 26% remaining
Usage after: 0% remaining

The task was substantially smaller than Task 1.
Visible results:

Validation of the previously created documentation
One prompt-history Markdown update
One Git commit
One local Git fast-forward
No production execution
No runtime code changes
No full test suite

The entire newly reset five-hour allowance was exhausted in approximately 47 minutes across two documentation-focused tasks.
The Codex app task history shows the timestamps and the model change from Terra to Luna. To my knowledge, no other Codex task, CLI session, IDE integration, or cloud task was running concurrently.
I understand that Codex usage depends on context size, reasoning, tool calls, and internal agent turns rather than only the visible number of file changes. However, this consumption is dramatically higher than my recent experience with GPT-5.5, where I was able to complete several longer implementation tasks within one usage window.
Could the team please investigate whether this may involve:

incorrect server-side usage accounting;
abnormal context or cache accounting;
stale or background sessions being attributed to the account;
an account-specific rate-limit or anti-abuse restriction;
or a regression in the Codex desktop app usage meter?

I can provide sanitized prompts, completion summaries, exact timestamps, and additional screenshots privately if needed.
image.png (view on web)
image.png (view on web)

—Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today!
You are receiving this because you authored the thread.Message ID: ***@***.***>
neilo937-pixel · 10 days ago

Hello Cherry,

Just to clarify, this is not a suspended ChatGPT Team or Business workspace
issue. I am using an active ChatGPT Plus account, and my request concerns
unexpectedly rapid depletion of the Codex five-hour usage allowance.

I will provide the requested screenshots and incident details below.

2026년 7월 10일 (금) 오후 3:44, excessive-eng @.***>님이 작성:

excessive-eng left a comment (openai/codex#28908) <https://github.com/openai/codex/issues/28908#issuecomment-4932716201> Hi, thank you for sharing such a detailed timeline. As far as I can determine, ordinary ChatGPT usage and Codex usage are not directly tied to the same visible quota meter. Otherwise, exhausting and blocking the Codex allowance would presumably also block ordinary ChatGPT usage at the same time. That has not been my experience, although I cannot confirm the exact server-side accounting mechanism. Your reported consumption still looks unusually high, especially because the entire freshly reset five-hour allowance disappeared during two documentation-focused tasks. One additional check may be useful. During my own investigation, I discovered that Codex could be running through local background processes and scheduled automations even when I was not manually submitting anything in the desktop interface. In my case, background commands were launching real autonomous sessions such as: codex exec --ephemeral --full-auto ... Those are actual Codex tasks and may consume quota even though no foreground task is visibly running in the desktop application. Since you are using Windows, I recommend checking the following. ### 1. Find all Codex-related processes and inspect their command lines Open PowerShell as Administrator and run: ``powershell Get-CimInstance Win32_Process | Where-Object { $_.Name -match 'codex|node|powershell|cmd' -or $_.CommandLine -match 'codex|codex exec|full-auto|automation' } | Select-Object ProcessId, ParentProcessId, Name, CommandLine | Format-List Pay particular attention to command lines containing: codex exec --full-auto --ephemeral unexpected project paths scripts that repeatedly relaunch Codex Node or PowerShell processes whose command lines reference Codex The normal Codex desktop application and its renderer/network subprocesses are not automatically suspicious. The important items are autonomous CLI executions or scripts that launch them. 2. Check specifically for active codex exec sessions Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'codex\s+exec' } | Select-Object ProcessId, ParentProcessId, Name, CommandLine | Format-List If this produces output while no task should be running, a background Codex session is active. 3. Stop only autonomous Codex CLI sessions First review the output. Then stop the relevant process by its PID: Stop-Process -Id <PID> -Force To stop every process whose command line contains codex exec: Get-CimInstance Win32_Process | Where-Object { $_.CommandLine -match 'codex\s+exec' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force } This is safer than terminating every process named Codex, because it leaves the normal desktop application alone. 4. Check Windows Task Scheduler Get-ScheduledTask | Where-Object { $_.TaskName -match 'codex|openai|automation|autowake' -or $_.TaskPath -match 'codex|openai' } | Select-Object TaskPath, TaskName, State To inspect the commands executed by matching tasks: Get-ScheduledTask | Where-Object { $_.TaskName -match 'codex|openai|automation|autowake' -or $_.TaskPath -match 'codex|openai' } | ForEach-Object { [PSCustomObject]@{ TaskPath = $_.TaskPath TaskName = $_.TaskName State = $_.State Actions = ($_.Actions | Out-String).Trim() } } | Format-List To disable a confirmed unwanted task: Disable-ScheduledTask -TaskName '<TASK_NAME>' -TaskPath '<TASK_PATH>' Do not disable anything until its action and origin have been checked. 5. Check startup applications and registry entries Get-CimInstance Win32_StartupCommand | Where-Object { $_.Name -match 'codex|openai' -or $_.Command -match 'codex|openai' } | Select-Object Name, Command, Location, User | Format-List Also check the common Run registry keys: $runKeys = @( 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run', 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run', 'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Run' ) foreach ($key in $runKeys) { if (Test-Path $key) { Write-Host "n=== $key ===" Get-ItemProperty $key } } 6. Check Windows services Get-CimInstance Win32_Service | Where-Object { $_.Name -match 'codex|openai' -or $_.DisplayName -match 'codex|openai' -or $_.PathName -match 'codex|openai' } | Select-Object Name, DisplayName, State, StartMode, PathName | Format-List 7. Create a timestamped monitoring log This records relevant processes every 30 seconds: $log = "$env:USERPROFILE\Desktop\codex_process_monitor.log" while ($true) { "===== $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') =====" | Out-File $log -Append Get-CimInstance Win32_Process | Where-Object { $_.Name -match 'codex|node|powershell|cmd' -or $_.CommandLine -match 'codex|codex exec|full-auto|automation' } | Select-Object ProcessId, ParentProcessId, Name, CommandLine | Format-List | Out-String | Out-File $log -Append Start-Sleep -Seconds 30 } Stop monitoring with Ctrl+C. For a clean test, I would: record the exact Codex percentage and time; confirm that no codex exec process is running; disable any confirmed Codex-related scheduled task; leave the computer idle without submitting prompts; take screenshots of the usage meter at regular intervals; preserve the process-monitoring log. This does not prove that background activity explains your case. Your two visible tasks may genuinely have consumed the allowance because of context size, model rates, internal turns, or a metering defect. However, eliminating autonomous local sessions makes the evidence much stronger if the quota continues to fall. Отправлено с iPhone10 июля 2026 г., в 07:25, neilo937-pixel @.> написал(а):neilo937-pixel left a comment (openai/codex#28908) I am seeing a possibly related Codex usage-metering issue on a ChatGPT Plus account. Unlike the original report, I was actively running tasks, but the amount of usage consumed appears highly disproportionate to the workload. Environment Subscription: ChatGPT Plus Client: Codex desktop app for Windows Codex App version: 26.707.31428 App release date shown in About Codex: July 10, 2026 Time zone: KST / UTC+9 Date observed: July 10, 2026 Exact timeline The five-hour usage limit reset at exactly 12:07 PM KST. I started the first task immediately after the reset. Task 1 Start: 12:07 PM KST End: 12:17 PM KST Model: GPT-5.6 Terra Reasoning effort: Medium Usage before: approximately 100% remaining Usage after: approximately 26% remaining Duration: approximately 10 minutes The task was documentation and prompt-governance refactoring. Visible results: Six Markdown governance documents One Git commit No production execution No runtime code changes No full test suite Task 2 Started shortly after 12:17 PM KST End: 12:54 PM KST Model: GPT-5.6 Luna Reasoning effort: Medium Usage before: approximately 26% remaining Usage after: 0% remaining The task was substantially smaller than Task 1. Visible results: Validation of the previously created documentation One prompt-history Markdown update One Git commit One local Git fast-forward No production execution No runtime code changes No full test suite The entire newly reset five-hour allowance was exhausted in approximately 47 minutes across two documentation-focused tasks. The Codex app task history shows the timestamps and the model change from Terra to Luna. To my knowledge, no other Codex task, CLI session, IDE integration, or cloud task was running concurrently. I understand that Codex usage depends on context size, reasoning, tool calls, and internal agent turns rather than only the visible number of file changes. However, this consumption is dramatically higher than my recent experience with GPT-5.5, where I was able to complete several longer implementation tasks within one usage window. Could the team please investigate whether this may involve: incorrect server-side usage accounting; abnormal context or cache accounting; stale or background sessions being attributed to the account; an account-specific rate-limit or anti-abuse restriction; or a regression in the Codex desktop app usage meter? I can provide sanitized prompts, completion summaries, exact timestamps, and additional screenshots privately if needed. image.png (view on web) image.png (view on web) —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.Message ID: @.> — Reply to this email directly, view it on GitHub <https://github.com/openai/codex/issues/28908?email_source=notifications&email_token=CAFEGWQKHDP5QZ26MSPGA6T5ECGDRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTGI3TCNRSGAY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4932716201>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CAFEGWS3WAOT7OBP5DUYALT5ECGDRAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TINRZGIZTAMJQGU32C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CAFEGWXIB36GYU4WAEQMKJD5ECGDRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTGI3TCNRSGAY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/CAFEGWQJ67FWRI7XSGKYJ2L5ECGDRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTGI3TCNRSGAY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>
neilo937-pixel · 8 days ago

Hello Cherry,

I performed one additional test today and observed the same issue again.

Date: July 12, 2026
Timezone: KST (UTC+9)
Model: GPT-5.6 Terra
Reasoning level: High
Image generation: None
Visible parallel Codex sessions: None

Usage Dashboard:

  • Approximately 13:24:43: 5-hour limit 85% remaining / weekly limit 90%

remaining

  • Approximately 13:35:24: 5-hour limit 56% remaining / weekly limit 86%

remaining

In approximately 10 minutes and 41 seconds:

  • The 5-hour allowance decreased by 29 percentage points.
  • The weekly allowance decreased by 4 percentage points.

The task involved code review, tests, and corrections in one existing
project. I am attaching the two timestamped screenshots.

This is now the third similar incident I have documented across July 10,
July 11, and July 12.

I understand that usage can vary depending on model, reasoning level,
context size, and task complexity. However, I cannot determine whether this
usage was caused by the visible task, context processing, retries, or
background activity because the Codex dashboard does not provide a usage
breakdown.

I do not have a screen recording because the unexpected depletion cannot be
predicted in advance. I do not intend to consume additional paid usage
solely to reproduce the issue again for a recording.

Please escalate the case using the account, timestamps, and screenshots
already provided, and review the server-side usage records for these three
incidents.

Please confirm whether the case has been escalated.

Best,
Kang Min

2026년 7월 10일 (금) 오후 5:54, 김강민 @.***>님이 작성:

Hello Cherry, Just to clarify, this is not a suspended ChatGPT Team or Business workspace issue. I am using an active ChatGPT Plus account, and my request concerns unexpectedly rapid depletion of the Codex five-hour usage allowance. I will provide the requested screenshots and incident details below. 2026년 7월 10일 (금) 오후 3:44, excessive-eng @.***>님이 작성: > excessive-eng left a comment (openai/codex#28908) > <https://github.com/openai/codex/issues/28908#issuecomment-4932716201> > > Hi, thank you for sharing such a detailed timeline. > > As far as I can determine, ordinary ChatGPT usage and Codex usage are not > directly tied to the same visible quota meter. Otherwise, exhausting and > blocking the Codex allowance would presumably also block ordinary ChatGPT > usage at the same time. That has not been my experience, although I cannot > confirm the exact server-side accounting mechanism. > > Your reported consumption still looks unusually high, especially because > the entire freshly reset five-hour allowance disappeared during two > documentation-focused tasks. > > One additional check may be useful. During my own investigation, I > discovered that Codex could be running through local background processes > and scheduled automations even when I was not manually submitting anything > in the desktop interface. > > In my case, background commands were launching real autonomous sessions > such as: > > codex exec --ephemeral --full-auto ... > > Those are actual Codex tasks and may consume quota even though no > foreground task is visibly running in the desktop application. > > Since you are using Windows, I recommend checking the following. > > ### 1. Find all Codex-related processes and inspect their command lines > > Open PowerShell as Administrator and run: > > ``powershell > Get-CimInstance Win32_Process | > Where-Object { > $_.Name -match 'codex|node|powershell|cmd' -or > $_.CommandLine -match 'codex|codex exec|full-auto|automation' > } | > Select-Object ProcessId, ParentProcessId, Name, CommandLine | > Format-List > Pay particular attention to command lines containing: > > codex exec > --full-auto > --ephemeral > unexpected project paths > scripts that repeatedly relaunch Codex > Node or PowerShell processes whose command lines reference Codex > > The normal Codex desktop application and its renderer/network > subprocesses are not automatically suspicious. The important items are > autonomous CLI executions or scripts that launch them. > 2. Check specifically for active > codex exec > sessions > Get-CimInstance Win32_Process | > Where-Object { $_.CommandLine -match 'codex\s+exec' } | > Select-Object ProcessId, ParentProcessId, Name, CommandLine | > Format-List > If this produces output while no task should be running, a background > Codex session is active. > 3. Stop only autonomous Codex CLI sessions > First review the output. Then stop the relevant process by its PID: > Stop-Process -Id <PID> -Force > To stop every process whose command line contains codex exec: > Get-CimInstance Win32_Process | > Where-Object { $_.CommandLine -match 'codex\s+exec' } | > ForEach-Object { > Stop-Process -Id $_.ProcessId -Force > } > This is safer than terminating every process named Codex, because it > leaves the normal desktop application alone. > 4. Check Windows Task Scheduler > Get-ScheduledTask | > Where-Object { > $_.TaskName -match 'codex|openai|automation|autowake' -or > $_.TaskPath -match 'codex|openai' > } | > Select-Object TaskPath, TaskName, State > To inspect the commands executed by matching tasks: > Get-ScheduledTask | > Where-Object { > $_.TaskName -match 'codex|openai|automation|autowake' -or > $_.TaskPath -match 'codex|openai' > } | > ForEach-Object { > [PSCustomObject]@{ > TaskPath = $_.TaskPath > TaskName = $_.TaskName > State = $_.State > Actions = ($_.Actions | Out-String).Trim() > } > } | > Format-List > To disable a confirmed unwanted task: > Disable-ScheduledTask -TaskName '<TASK_NAME>' -TaskPath '<TASK_PATH>' > Do not disable anything until its action and origin have been checked. > 5. Check startup applications and registry entries > Get-CimInstance Win32_StartupCommand | > Where-Object { > $_.Name -match 'codex|openai' -or > $_.Command -match 'codex|openai' > } | > Select-Object Name, Command, Location, User | > Format-List > Also check the common Run registry keys: > $runKeys = @( > 'HKCU:\Software\Microsoft\Windows\CurrentVersion\Run', > 'HKLM:\Software\Microsoft\Windows\CurrentVersion\Run', > 'HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Run' > ) > > foreach ($key in $runKeys) { > if (Test-Path $key) { > Write-Host "n=== $key ===" > Get-ItemProperty $key > } > } > 6. Check Windows services > Get-CimInstance Win32_Service | > Where-Object { > $_.Name -match 'codex|openai' -or > $_.DisplayName -match 'codex|openai' -or > $_.PathName -match 'codex|openai' > } | > Select-Object Name, DisplayName, State, StartMode, PathName | > Format-List > 7. Create a timestamped monitoring log > This records relevant processes every 30 seconds: > $log = "$env:USERPROFILE\Desktop\codex_process_monitor.log" > > while ($true) { > "===== $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss') =====" | > Out-File $log -Append > > Get-CimInstance Win32_Process | > Where-Object { > $_.Name -match 'codex|node|powershell|cmd' -or > $_.CommandLine -match 'codex|codex exec|full-auto|automation' > } | > Select-Object ProcessId, ParentProcessId, Name, CommandLine | > Format-List | > Out-String | > Out-File $log -Append > > Start-Sleep -Seconds 30 > } > Stop monitoring with Ctrl+C. > For a clean test, I would: > > record the exact Codex percentage and time; > confirm that no codex exec process is running; > disable any confirmed Codex-related scheduled task; > leave the computer idle without submitting prompts; > take screenshots of the usage meter at regular intervals; > preserve the process-monitoring log. > > This does not prove that background activity explains your case. Your two > visible tasks may genuinely have consumed the allowance because of context > size, model rates, internal turns, or a metering defect. However, > eliminating autonomous local sessions makes the evidence much stronger if > the quota continues to fall. > > > Отправлено с iPhone10 июля 2026 г., в 07:25, neilo937-pixel @.> > написал(а):neilo937-pixel left a comment (openai/codex#28908) > I am seeing a possibly related Codex usage-metering issue on a ChatGPT > Plus account. > Unlike the original report, I was actively running tasks, but the amount > of usage consumed appears highly disproportionate to the workload. > Environment > > Subscription: ChatGPT Plus > Client: Codex desktop app for Windows > Codex App version: 26.707.31428 > App release date shown in About Codex: July 10, 2026 > Time zone: KST / UTC+9 > Date observed: July 10, 2026 > > Exact timeline > The five-hour usage limit reset at exactly 12:07 PM KST. I started the > first task immediately after the reset. > Task 1 > > Start: 12:07 PM KST > End: 12:17 PM KST > Model: GPT-5.6 Terra > Reasoning effort: Medium > Usage before: approximately 100% remaining > Usage after: approximately 26% remaining > Duration: approximately 10 minutes > > The task was documentation and prompt-governance refactoring. > Visible results: > > Six Markdown governance documents > One Git commit > No production execution > No runtime code changes > No full test suite > > Task 2 > > Started shortly after 12:17 PM KST > End: 12:54 PM KST > Model: GPT-5.6 Luna > Reasoning effort: Medium > Usage before: approximately 26% remaining > Usage after: 0% remaining > > The task was substantially smaller than Task 1. > Visible results: > > Validation of the previously created documentation > One prompt-history Markdown update > One Git commit > One local Git fast-forward > No production execution > No runtime code changes > No full test suite > > The entire newly reset five-hour allowance was exhausted in approximately > 47 minutes across two documentation-focused tasks. > The Codex app task history shows the timestamps and the model change from > Terra to Luna. To my knowledge, no other Codex task, CLI session, IDE > integration, or cloud task was running concurrently. > I understand that Codex usage depends on context size, reasoning, tool > calls, and internal agent turns rather than only the visible number of file > changes. However, this consumption is dramatically higher than my recent > experience with GPT-5.5, where I was able to complete several longer > implementation tasks within one usage window. > Could the team please investigate whether this may involve: > > incorrect server-side usage accounting; > abnormal context or cache accounting; > stale or background sessions being attributed to the account; > an account-specific rate-limit or anti-abuse restriction; > or a regression in the Codex desktop app usage meter? > > I can provide sanitized prompts, completion summaries, exact timestamps, > and additional screenshots privately if needed. > image.png (view on web) > image.png (view on web) > > —Reply to this email directly, view it on GitHub, or unsubscribe.Triage > notifications, keep track of coding agent tasks and review pull requests on > the go with GitHub Mobile for iOS and Android. Download it today! > You are receiving this because you authored the thread.Message ID: > @.> > > — > Reply to this email directly, view it on GitHub > <https://github.com/openai/codex/issues/28908?email_source=notifications&email_token=CAFEGWQKHDP5QZ26MSPGA6T5ECGDRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTGI3TCNRSGAY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4932716201>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/CAFEGWS3WAOT7OBP5DUYALT5ECGDRAVCNFSNUABFKJSXA33TNF2G64TZHM4TMNJUGE2TMNBZHNEXG43VMU5TINRZGIZTAMJQGU32C5QC> > . > Triage notifications, keep track of coding agent tasks and review pull > requests on the go with GitHub Mobile for iOS > <https://github.com/notifications/mobile/ios/CAFEGWXIB36GYU4WAEQMKJD5ECGDRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTGI3TCNRSGAY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> > and Android > <https://github.com/notifications/mobile/android/CAFEGWQJ67FWRI7XSGKYJ2L5ECGDRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJTGI3TCNRSGAY2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. > Download it today! > You are receiving this because you commented.Message ID: > @.***> >