Unexpected Codex 5h Quota Exhaustion on Pro 5X + GPT-5.3 Codex Spark Context Window Failure

[irisa]

Environment

• ChatGPT Pro 5X
• Codex Desktop (macOS)
• Same account/workspace across Desktop, Web, and CLI
• Default service tier
• Primary model during the affected work: GPT-5.5 (xhigh reasoning)
• Later diagnostic run: GPT-5.3 Codex Spark (xhigh reasoning)

---

Issue A: Unexpected 5h Quota Exhaustion

Today I unexpectedly exhausted my Codex 5-hour quota after what appeared to be a very small amount of work.

From the user perspective:

• Only 3 active threads were used.
• Total active task runtime was under 20 minutes.
• Codex analytics showed very low daily thread activity
• No unusually large code generation jobs were performed.

I’ve never hit the wall with much more intensive work. I did not expect this workload to come anywhere close to exhausting the quota window.

After investigating local session logs, I found that one GPT-5.5 thread accumulated extremely large token counts.

Thread:

019ea500-1d8b-7c90-881a-bded967f5aa9

Run 1

• GPT-5.5 (xhigh)
• Duration: 157 seconds
• Reported primary usage: 15%
• Total tokens by end of run: 777,268

Run 2

• GPT-5.5 (xhigh)
• Duration: 497 seconds
• Reported primary usage: 38%
• Total tokens by end of run: 5,290,376

At this point the thread had accumulated more than 5 million total tokens.

However, before the next task, the account had already reached the 5-hour quota limit.

---

Why This Is Confusing

The visible workload appeared very small:

• 3 threads
• Less than 20 minutes of active runtime
• No large-scale generation tasks

Yet backend token accumulation appears to have reached multi-million-token levels.

What is not clear is how the following relate to one another:

• Total tokens
• Cached input tokens
• Primary usage %
• 5-hour quota consumption
• Pro 5X allowance

In particular:

• One run ended at approximately 5.29M total tokens while reporting only 38% primary usage.
• Before the next investigation run, the account was already at 100%.

I would appreciate clarification on:

1. How is “primary %” calculated?
2. Does “primary %” scale according to subscription tier?
3. Does 38% mean 38% of the Pro 5X allowance?
4. How much do cached input tokens contribute to quota consumption?
5. Is total token accumulation directly related to the 5-hour quota?
6. Are there known discrepancies between visible usage indicators and backend quota accounting?

---

Issue B: GPT-5.3 Codex Spark Context Window Failure

After the quota issue occurred, I switched to GPT-5.3 Codex Spark to investigate the problem.

The task was extremely simple:

“Can you figure out why we suddenly hit the 5h usage limit of Codex?”

Spark performed a few searches and inspections, then produced:

Context automatically compacted

followed immediately by:

Your input exceeds the context window of this model. Please adjust your input and try again.

No meaningful analysis was completed before the context window was exhausted.

Notably, this happened while attempting to diagnose the quota issue itself.

---

Why This Seems Strange

The sequence was roughly:

1. Open a repository/workspace.
2. Ask Spark to investigate a quota issue.
3. Spark performs a handful of searches.
4. Context compaction triggers.
5. Context window is exceeded.
6. Task aborts without completing.

This was not a large coding task.

It was primarily repository inspection and log analysis.

---

Questions About Spark

1. Is GPT-5.3 Codex Spark intended for repository-scale investigations?
2. Is Spark expected to automatically compact context successfully during repo analysis?
3. Are there recommended limits for:
   • AGENTS.md size
   • memory files
   • operational notes
   • workspace documentation
   • session history
4. Are there known issues where Spark repeatedly re-reads large workspace documents and rapidly consumes context?
5. Is there a recommended workflow for using Spark as a troubleshooting or repository-investigation agent?

---

Additional Context

This workspace contains:

• agent skills
• operational memory files
• workspace documentation
• automation notes
• agent-generated reports

It is possible that Spark is encountering a context-management edge case in repositories that contain large amounts of operational memory and documentation.

If Spark is not intended for this type of investigation, guidance on its expected scope would be very helpful.

[yducdx]

My plus account also encountered a similar problem. Two small questions, very mild workload, and the whole 5h limit is gone. Seems something changed on the codex backend.

[irisa]

Update: June 11, 2026 — new local log findings

I’ve now observed this quota exhaustion pattern for four days in a row and found stronger local evidence that the visible Codex workload is probably not the full explanation.

The most important new finding is that Codex Desktop appears to be running hidden memory-generation / memory-consolidation jobs outside the visible thread UI.

What I found

In local Codex state, I found a memory database:

~/.codex/memories_1.sqlite

It contains a job table with entries such as:

memory_stage1
memory_consolidate_global

The key suspicious row was:

kind: memory_consolidate_global
key: global
status: pending
started: 2026-06-11 10:12:03 local time
finished: 2026-06-11 12:37:53 local time
retry_remaining: 3
input_watermark: 2026-06-11 11:25:28 local time
last_success_watermark: 2026-06-11 01:12:15 local time

This job does not appear as a normal visible Codex thread in the UI.

Hidden memory runs hit the quota

Local logs show hidden / ephemeral Codex runs with:

cwd=~/.codex/memories
model=gpt-5.4

These runs repeatedly drove the primary 5-hour quota to 100%, then failed with the normal usage-limit message.

Examples:

2026-06-08 11:44 local time
hidden memory thread
input_tokens=168,179,587
cached_input_tokens=167,420,032
non_cached_input_tokens=759,555
output_tokens=147,757
then usage-limit error

2026-06-09 02:16 local time
hidden memory thread
input_tokens=205,992,174
cached_input_tokens=205,004,800
non_cached_input_tokens=987,374
output_tokens=142,778
then usage-limit error

2026-06-09 11:41 local time
hidden memory thread
input_tokens=176,506,519
cached_input_tokens=175,855,488
non_cached_input_tokens=651,031
output_tokens=121,722
then usage-limit error

Visible memory citations may not be the direct cause

One visible prompt showed “3 memory citations,” but I no longer think the citations themselves are enough to explain the quota jump.

The visible prompt had memory retrieval, but the quota percentage jumped before the final response containing the citations was emitted. Around the same time, Codex also started a memory_stage1 job.

So my current hypothesis is:

• visible “memory citations” are mostly memory read/retrieval;
• the dangerous quota usage seems to come from memory generation/consolidation in the background;
• the UI does not make this distinction clear.

Time pattern

The quota exhaustion repeatedly happened around my morning work window, corresponding roughly to 1:00-4:00 AM GMT.

That may be when Codex Desktop resumes, notices a backlog of memory work, runs memory_stage1, and then attempts memory_consolidate_global.

After the hidden job fails, pauses, or waits for a retry trigger, later visible work can appear stable even with more memory citations.

Why this seems like a bug or quota-accounting issue

This seems report-worthy because:

1. Hidden memory jobs consume visible quota.
2. The app does not surface these jobs as active work.
3. The quota UI makes the visible prompt look responsible.
4. The hidden jobs logged extremely large token counters, mostly cached input.
5. The global memory consolidation job remained pending with retries left after quota failure.
6. Disabling prompt verbosity or reducing normal visible work does not address the hidden memory workload.

Temporary mitigation I am testing / considering

A safer temporary config change appears to be disabling memory generation while keeping memory retrieval:

[memories]
generate_memories = false
use_memories = true

This should preserve existing memory citations but stop Codex from automatically generating / consolidating new memories.

I would appreciate clarification from OpenAI on:

1. Whether Codex Desktop memory generation/consolidation is expected to count against the 5-hour quota.
2. Whether cached input tokens in hidden memory jobs should be able to exhaust quota this quickly.
3. Why memory_consolidate_global jobs are not visible in the UI.
4. Whether there is a known bug around memory backlog processing.
5. Whether users should be given a separate toggle for memory reading vs memory writing.
6. Whether the hundreds-of-millions cached-input-token accounting is expected or anomalous.