Possible Abnormal Token Consumption, Repeated Context Compaction Loops, Redundant Status Reporting, and Continuous Windows Commit Growth in Codex
I am a ChatGPT Pro 20x user and recently encountered several potentially related issues while using the Codex Windows desktop application for multi-task software development.
Environment and workflow
I was running more than ten independent Codex tasks across several projects. These were separate Codex tasks rather than subagents created through Ultra mode.
I manually assigned different responsibilities to them through prompts, including:
- Controller or project manager
- Implementation
- Code review
- Testing and auditing
The “controller” was therefore only another independent Codex task with a coordination role. It did not appear to have platform-level monitoring access to the internal status, token usage, or resource consumption of the other tasks.
1. Extremely high reported token consumption
My weekly usage cycle started on August 2, 2026 at approximately 12:00. The entire weekly limit was exhausted by approximately August 5 at 02:00, only about 62 hours later.
The usage interface reported approximately 3.17 billion tokens during this period.
I understand that I was running many tasks and several long-context projects simultaneously. However, the reported total still appears disproportionately high for an individual developer, even with more than ten active tasks.
This averages approximately:
- 51 million tokens per hour across the account
- 852,000 tokens per minute
- 14,000 tokens per second
I cannot determine from the current interface how much of this consisted of normal input, cached input, output, repeated context reconstruction, background polling, or duplicated accounting.
Please investigate whether this usage was caused entirely by expected activity or whether abnormal repeated processing, background loops, context-compaction behavior, or a metering problem contributed to it.
2. A task entered a repeated context-compaction and file-rereading loop
On one occasion, an independently running Codex task appeared to enter a severe context-compaction loop.
I left the tasks running and returned approximately one hour later. After I asked the separate controller task about project progress, I inspected the affected task and found that it had performed context compaction and subsequent context or file rereading dozens of times during roughly that one-hour period.
I did not manually count every compaction event, so I cannot provide an exact number. However, the frequency was clearly far beyond occasional context management.
The observed pattern appeared to be:
- The context became full.
- Codex compacted the context.
- The task reread files or reconstructed its working state.
- The context quickly grew again.
- Another compaction occurred.
- The cycle repeated without producing proportional progress.
The task did not automatically stop, warn me, or report that it was trapped in a repetitive cycle. I discovered the problem only after manually checking its progress approximately one hour later.
This behavior may have contributed significantly to the unusually high token consumption.
3. Repeated low-information “everything is normal” status reports
In another case, a task reported to the controller more than a dozen times during a single execution round that everything was normal or that work was proceeding normally.
These reports did not appear to contain corresponding new deliverables, meaningful progress changes, new test results, or new blockers.
This looked more like a model-driven heartbeat or status-reporting loop than useful project communication. If every report required another model invocation, rereading of shared project state, or context update, it may also have generated substantial unnecessary token consumption.
A task should not repeatedly declare that it is healthy without measurable progress. Status reports should ideally be tied to concrete changes such as:
- Files modified
- Tests completed
- Acceptance criteria closed
- New findings
- A changed blocker
- A completed deliverable
4. Lack of visible per-task monitoring and automatic circuit breakers
Because these were independently running Codex tasks, the manually designated controller task could not automatically detect that another task was repeatedly compacting its context, rereading files, or consuming tokens unusually quickly.
The multi-task interface did not provide a sufficiently visible warning for:
- Abnormally frequent context compaction
- Rapid per-task token growth
- Repeated reading of the same files
- Repeated execution of the same tests or commands
- Many status reports without measurable progress
- Long periods without new code, test results, or conclusions
- A task apparently trapped in a repetitive loop
It would be helpful to provide per-task telemetry and automatic safeguards, such as:
- Per-task input, cached-input, and output token statistics
- Context-compaction counters
- Token-consumption rate alerts
- Detection of repeated tool calls or repeated file reads
- Detection of repeated status reports without state changes
- User-configurable token or execution budgets
- Automatic pausing after several compactions without progress
- A warning when a task appears stalled or cyclic
5. Windows Commit continually increasing
I have also observed Windows system Commit, meaning committed virtual memory rather than Git commits, continually increasing while the Codex Windows desktop application was running.
Based on my observations, total Windows Commit increased at an average rate of approximately 1.2 to 1.7 GB per hour during extended Codex use.
This growth continued over time rather than stabilizing at a normal working level. The rate is large enough to create substantial committed-memory pressure during long-running sessions, especially when several Codex tasks are active.
I cannot determine whether the growth originates from the Codex application itself, Git-status monitoring, terminal or console processes, task sandboxes, subprocess creation, or another background component. However, the observed rate does not appear normal for a development application running over an extended period.
Please investigate whether the Windows desktop application has a committed-memory, process-lifecycle, Git-polling, terminal, sandbox, or resource-release issue.
It would also be useful for the investigation to distinguish among:
- Codex application private commit
- Child-process commit
- Windows paged-pool or nonpaged-pool growth
- Repeatedly created Git or console processes
- Resources retained after individual tasks complete
Requested investigation
Please review the account and diagnostic logs for the period from approximately:
- Start: August 2, 2026 at 12:00
- Weekly limit exhausted: August 5, 2026 at approximately 02:00
I would particularly appreciate clarification on:
- The breakdown of the reported 3.17 billion tokens into normal input, cached input, and output.
- Which tasks or sessions contributed most of the usage.
- Whether repeated context compaction and file rereading accounted for a substantial portion of the activity.
- Whether redundant status reporting or background polling generated repeated model calls.
- Whether any duplicated accounting, abnormal metering, or platform-side issue occurred.
- Whether continuous Windows Commit growth of approximately 1.2 to 1.7 GB per hour is a known Codex desktop issue.
- Which Codex or child process was responsible for the observed committed-memory growth.
I can provide screenshots, approximate task timelines, Windows Task Manager data, and any locally available diagnostic information privately.
I would also appreciate a review of whether the weekly usage limit was consumed correctly, because a meaningful portion of the reported activity may have resulted from runaway loops or repeated processing rather than productive task execution.
Possible Abnormal Token Consumption, Repeated Context Compaction Loops, Redundant Status Reporting, and Continuous Windows Commit Growth in Codex
I am a ChatGPT Pro 20x user and recently encountered several potentially related issues while using the Codex Windows desktop application for multi-task software development.
Environment and workflow
I was running more than ten independent Codex tasks across several projects. These were separate Codex tasks rather than subagents created through Ultra mode.
I manually assigned different responsibilities to them through prompts, including:
The “controller” was therefore only another independent Codex task with a coordination role. It did not appear to have platform-level monitoring access to the internal status, token usage, or resource consumption of the other tasks.
1. Extremely high reported token consumption
My weekly usage cycle started on August 2, 2026 at approximately 12:00. The entire weekly limit was exhausted by approximately August 5 at 02:00, only about 62 hours later.
The usage interface reported approximately 3.17 billion tokens during this period.
I understand that I was running many tasks and several long-context projects simultaneously. However, the reported total still appears disproportionately high for an individual developer, even with more than ten active tasks.
This averages approximately:
I cannot determine from the current interface how much of this consisted of normal input, cached input, output, repeated context reconstruction, background polling, or duplicated accounting.
Please investigate whether this usage was caused entirely by expected activity or whether abnormal repeated processing, background loops, context-compaction behavior, or a metering problem contributed to it.
2. A task entered a repeated context-compaction and file-rereading loop
On one occasion, an independently running Codex task appeared to enter a severe context-compaction loop.
I left the tasks running and returned approximately one hour later. After I asked the separate controller task about project progress, I inspected the affected task and found that it had performed context compaction and subsequent context or file rereading dozens of times during roughly that one-hour period.
I did not manually count every compaction event, so I cannot provide an exact number. However, the frequency was clearly far beyond occasional context management.
The observed pattern appeared to be:
The task did not automatically stop, warn me, or report that it was trapped in a repetitive cycle. I discovered the problem only after manually checking its progress approximately one hour later.
This behavior may have contributed significantly to the unusually high token consumption.
3. Repeated low-information “everything is normal” status reports
In another case, a task reported to the controller more than a dozen times during a single execution round that everything was normal or that work was proceeding normally.
These reports did not appear to contain corresponding new deliverables, meaningful progress changes, new test results, or new blockers.
This looked more like a model-driven heartbeat or status-reporting loop than useful project communication. If every report required another model invocation, rereading of shared project state, or context update, it may also have generated substantial unnecessary token consumption.
A task should not repeatedly declare that it is healthy without measurable progress. Status reports should ideally be tied to concrete changes such as:
4. Lack of visible per-task monitoring and automatic circuit breakers
Because these were independently running Codex tasks, the manually designated controller task could not automatically detect that another task was repeatedly compacting its context, rereading files, or consuming tokens unusually quickly.
The multi-task interface did not provide a sufficiently visible warning for:
It would be helpful to provide per-task telemetry and automatic safeguards, such as:
5. Windows Commit continually increasing
I have also observed Windows system Commit, meaning committed virtual memory rather than Git commits, continually increasing while the Codex Windows desktop application was running.
Based on my observations, total Windows Commit increased at an average rate of approximately 1.2 to 1.7 GB per hour during extended Codex use.
This growth continued over time rather than stabilizing at a normal working level. The rate is large enough to create substantial committed-memory pressure during long-running sessions, especially when several Codex tasks are active.
I cannot determine whether the growth originates from the Codex application itself, Git-status monitoring, terminal or console processes, task sandboxes, subprocess creation, or another background component. However, the observed rate does not appear normal for a development application running over an extended period.
Please investigate whether the Windows desktop application has a committed-memory, process-lifecycle, Git-polling, terminal, sandbox, or resource-release issue.
It would also be useful for the investigation to distinguish among:
Requested investigation
Please review the account and diagnostic logs for the period from approximately:
I would particularly appreciate clarification on:
I can provide screenshots, approximate task timelines, Windows Task Manager data, and any locally available diagnostic information privately.
I would also appreciate a review of whether the weekly usage limit was consumed correctly, because a meaningful portion of the reported activity may have resulted from runaway loops or repeated processing rather than productive task execution.