[Regression] Codex repeatedly reprocesses massive cached context in long sessions, causing severe latency, timeouts, JSONL growth, and excessive credit usage #34971

Activity

1. brolabitalia

   added

   bugSomething isn't workingSomething isn't working

   on Jul 23, 2026
2. github-actions

   added

   CLIIssues related to the Codex CLIIssues related to the Codex CLI

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   performance

   rate-limitsIssues related to rate limits, quotas, and token usage reportingIssues related to rate limits, quotas, and token usage reporting

   on Jul 23, 2026
3. github-actions commented on Jul 23, 2026

   

   github-actionsbot

   on Jul 23, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • macOS Desktop: app-server pins ~2 cores rebuilding thread-history pages from very large rollout JSONLs (full re-parse per page) #34915
   • Codex Desktop re-sends generated-image history in subsequent /responses turns, growing requests to 27 MB and TTFT to 20s+ #33760
   • Usage is gone in one prompt #34176

   Powered by Codex Action
4. grtninja commented on Jul 23, 2026

   

   grtninja

   on Jul 23, 2026 – with ChatGPT Codex Connector

   More actions

   Fresh Windows 11 Pro / ChatGPT Pro corroboration from Codex Desktop on July 23, 2026.

   The affected long-running repository thread visibly reported Context automatically compacted, but immediately remained about 80% full. Only a small number of additional commands/tool operations fit before another compaction. The thread then repeated the same broad plans, reread or reprocessed prior state, and continued producing tool/receipt activity without proportional repository completion.

   Visible impact in this case:

   • multiple compaction events occurred close together;
   • the post-compaction thread retained only about 20% working headroom;
   • prior tool output and coordination state appeared to be rehydrated or retained at high volume;
   • the agent lost or softened the completed-versus-pending execution frontier;
   • included weekly usage fell into the low single digits while the requested production acceptance remained incomplete;
   • local storage also accumulated large volumes of session logs, receipts, screenshots, and repeated evidence.

   The narrower post-compaction occupancy bug is filed as #35032. This comment links that visible symptom to the cached-context/JSONL/usage pattern reported here.

   Requested diagnostics and protections:

   1. record pre-compaction input tokens, retained raw-history tokens, replacement-summary tokens, retained tool-state tokens, and post-compaction occupancy;
   2. identify whether already-compacted history is being compacted or transmitted again;
   3. bound raw historical tool results and deduplicate repeated tool/command outputs;
   4. stop or hand off when compaction cannot reclaim a minimum amount of working headroom;
   5. expose session-level usage accounting that separates useful generation from compaction, cached-context replay, empty polling, and failed/retried tools;
   6. provide a support route to review usage consumed by a confirmed reprocessing/compaction loop.

   The reporter has screenshots of the compaction events, the approximately 80% post-compaction meter, the usage panel, and the non-converging thread. Private repository data is intentionally omitted.
5. grtninja commented on Jul 23, 2026

   

   grtninja

   on Jul 23, 2026 – with ChatGPT Codex Connector

   More actions

   Cross-linking #35032 as a narrower UI-visible reproducer of the same usage-impact class. Codex Desktop reported successful auto-compaction but immediately remained about 80% full, then reprocessed state and compacted again while repository progress stalled. The affected user reached the edge of the included allowance during the loop. Please consider exposing original-history, retained-tool-state, replacement-summary, and reserved-output token counts so cached-context reprocessing can be distinguished from legitimate new work.
6. Nielsony commented on Jul 29, 2026

   

   Nielsony

   on Jul 29, 2026 – with ChatGPT Codex Connector

   More actions

   Corroborating report from Codex Desktop on macOS, observed on July 24, 2026.

   Environment

   • ChatGPT/Codex Desktop: 26.721.41059
   • Bundled Codex CLI: 0.146.0-alpha.3.1
   • Model: gpt-5.6-sol
   • Reasoning effort: medium and xhigh

   Aggregate observation

   Across four long-running tasks during one 24-hour window:

   • approximately 812 million cumulative raw tokens
   • approximately 96.8% cached input
   • approximately 26.21 million uncached input plus output tokens
   • 1-4 days of lifetime per task
   • 25-82 user continuations per task
   • 18-51 context compactions per task
   • 51-76 child-agent sessions per task

   The largest growth occurred when old threads continued into follow-up topics and when short test or review agents inherited broad task history. This produced rapid cumulative-token growth, repeated compaction, increased latency, and many child sessions without proportional task progress.

   Measurement boundary

   Child rollout token events inherited the parent task's existing cumulative total. I therefore calculated task-level deltas over the time window and did not add child cumulative totals together. The raw cumulative-token figures are also not being claimed as equivalent to billed cost.

   Requested guardrails

   • Separate current context occupancy from cumulative input, cached input, output, and reasoning output.
   • Warn before full-history forks or high child-agent counts and show an estimated usage impact.
   • Default bounded review/test agents to a summary or limited recent turns.
   • Detect repeated compaction, topic drift, and high-usage/low-progress loops, then recommend a bounded handoff.
   • Preserve completed items, pending items, the exact next action, and explicit do-not-repeat boundaries after compaction.
   • Expose task-level accounting that cannot be misread by summing inherited child totals.

   This also appears adjacent to #24704, although the observed high cached-input ratio does not establish that lost prompt-cache lineage is the cause here.

   An in-product /feedback submission was attempted, but automated access to the Codex Desktop feedback dialog was unavailable and the bundled CLI treated /feedback as ordinary conversation input; no feedback receipt was produced.

   Private repository names, paths, task IDs, and transcripts are intentionally omitted.
7. Nielsony commented on Aug 21, 2026

   

   Nielsony

   on Aug 21, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce the local-storage aspect on Codex Desktop/macOS in a separate workload.

   Before cleanup, a read-only local scan reported:

   • 1,000 archived sessions; 8,527,943,243 bytes of logical session storage
   • 80 sessions containing records above the bounded-reader threshold
   • 1,766,530,466 bytes of inline images/Data URLs across 2,721 images
   • largest archived rollout: about 3.4 GiB

   Removing only the archived-session files reclaimed about 11 GiB of physical disk space. This is remediation for disk pressure only, not a fix for the underlying serialization/compaction behavior.

   After cleanup, one currently live rollout still exceeded the 16 MiB threshold (about 33 MiB) and grew during the validation window. A bounded diagnostic attempt against that latest file did not complete within 30 seconds, so I cancelled it rather than leave a stalled process running.

   I am intentionally omitting local paths, repository names, session content, and screenshots. This observation establishes local JSONL growth and inspection difficulty; it does not by itself establish the backend token/credit attribution described in the issue.
8. drakerfire98 commented on Aug 21, 2026

   

   drakerfire98

   on Aug 21, 2026 – with ChatGPT Codex Connector

   More actions

   Adding an independent datapoint / request for verification because this issue is very close to behavior I noticed in my own Codex usage.

   I (Drake) first noticed around the recent compaction changes that long-running Codex sessions started consuming weekly usage much faster. I initially had a harness-side issue that could create extra work, but after fixing that and dropping GPT-5.6 Sol from medium reasoning to the default low setting, the effective usage drain still looked unusually high.

   My working hypothesis is not necessarily that the numeric weekly quota was reduced. It is that the cost per unit of useful work may have increased because Codex is retaining/reprocessing too much historical state across compactions (or otherwise losing some of the efficiency it previously had around cached/incremental context).

   I worked through this with my ChatGPT instance (GPT-5.6 Sol). I noticed the behavior first; I then asked ChatGPT to cross-check the hypothesis against the public Codex source and existing issue reports. The cross-check found several things that make the hypothesis plausible enough that I think it is worth independent testing, including:

   • Remote/local compaction paths intentionally carrying retained history/state forward rather than reducing everything to only a compact representation.
   • Existing reports around retained image/history payloads and repeated auto-compaction (Local compaction v2 retains unbounded input_image payloads, causing repeated auto-compaction #33493).
   • Full-history resend / cache-reuse edge cases in long sessions (Responses Lite: changing reasoning effort can strand a large session on “Request blocked.” until compaction #32533).
   • Multi-agent/fork history and quota-drain reports that may represent a related amplification path (Codex subagents drain full week quota overnight - usage counting broken #35463).
   • This issue itself showing very large repeated cached-context processing despite comparatively less useful tool/shell work.

   None of that proves one compaction regression is the cause of every current quota complaint, and I do not want to overstate the finding. The timing is correlation, and multiple mechanisms could be interacting. But the symptom pattern looks consistent with a regression where the quota itself is unchanged while each useful task becomes materially more expensive because more context is repeatedly processed.

   What I would really like is an outside opinion from maintainers or anyone who has instrumented this more deeply. In particular, has anyone compared before/after builds on:

   • cumulative input tokens per completed useful task;
   • cached vs. uncached input across compaction boundaries;
   • retained-history size immediately after compaction;
   • compaction frequency / headroom after compaction;
   • prompt-cache hit rate before and after a compaction;
   • whether information represented in compacted state is also being redundantly retained/reintroduced as raw ancestry;
   • effective work-per-quota before vs. after the recent compaction changes.

   A controlled A/B across a build before the complaint spike and a current build seems especially useful. If the quota limits are numerically identical but the newer path is carrying substantially more historical state or forcing more full-context processing, that would reconcile two observations that currently look contradictory: internal telemetry can show "limits unchanged" while users still experience dramatically faster depletion.

   If anyone can verify, falsify, or refine this hypothesis, I would genuinely appreciate it. I am much more interested in finding the actual mechanism than in claiming certainty about the cause.
9. amatsuki5032 commented on Aug 22, 2026

   

   amatsuki5032

   on Aug 22, 2026 – with ChatGPT Codex Connector

   More actions

   Corroborating Windows Codex Desktop datapoint from August 22, 2026. This looks very close to the cached-context reprocessing / usage-impact behavior described here.

   Environment

   • Codex Desktop: 26.818.4152.0 (updated from 26.818.3698.0)
   • Global Codex CLI: 0.149.0
   • Model: gpt-5.6-sol
   • Reasoning effort: xhigh
   • Platform: Windows
   • One long-running parent thread; this measured sequence was not subagent fan-out

   Original large-context configuration

   model_context_window = 1050000
   model_auto_compact_token_limit = 750000
   model_auto_compact_token_limit_scope = "total"

   The effective context window reported in the rollout was 828400.

   Across 300 local token-usage events at that window size:

   Metric	Value
   Average total tokens/event	210,469
   Median total tokens/event	208,127
   Maximum total tokens/event	325,965
   Average uncached input/event	3,476

   Mitigation attempt

   After updating/restarting Desktop, I reduced the configuration to:

   model_context_window = 272000
   model_auto_compact_token_limit = 220000
   model_auto_compact_token_limit_scope = "total"

   The effective window then reported 258400.

   Across 75 subsequent local token-usage events:

   Metric	Value
   Average total tokens/event	147,407
   Median total tokens/event	168,413
   Maximum total tokens/event	331,910
   Average uncached input/event	5,563

   Reducing the context setting lowered the average by about 30%, so the 1M configuration clearly amplified the impact. It did not eliminate the repeated near-full-history processing.

   Recent repeated sequence after mitigation

   Eight consecutive events, often only seconds apart, recorded:

   196338
   196423
   196616
   196797
   197143
   197230
   197359
   197552
   

   The last event contained:

   • total tokens: 197552
   • uncached input: 1084
   • output: 116
   • cached-input ratio: 99.5%
   • cumulative thread total at that point: 10.137M

   The sequence is overwhelmingly cached input rather than newly read instructions or new tool output. Small progress/re-entry cycles were repeatedly processing roughly 196k-198k tokens.

   These values are local Codex usage telemetry; I am not claiming they map one-to-one to billed tokens. The user-visible allowance nevertheless appeared to drain unusually quickly during the loop.

   Expected behavior

   • Tiny continuation/progress cycles should not repeatedly process almost the entire retained history.
   • Automatic compaction should reclaim enough headroom to prevent immediate near-threshold re-entry.
   • Codex should checkpoint, hand off, or warn when several consecutive model cycles exceed a high usage threshold with little new input/output.
   • The UI should distinguish cached replay, uncached input, output, and the amount actually charged to the user's allowance.

   #39767 may be adjacent because it documents a GPT-5.6 reasoning-accounting/compaction issue, but I am not asserting the same root cause here.

   No repository names, paths, source files, credentials, screenshots, or private task identifiers are included.
10. FromAriel commented on Aug 27, 2026

    

    FromAriel

    on Aug 27, 2026 – with ChatGPT Codex Connector

    More actions

    Cross-linking this cached-context/session amplification report to #41220, the meta tracker for abnormal Codex usage/quota depletion and usage-accounting inconsistencies. This case provides a concrete mechanism—thousands of model cycles repeatedly processing very large cached contexts—plus a historical comparison against a larger but previously cheaper/faster workload. The tracker keeps this as a workflow-amplification class rather than assuming it explains every quota-depletion report.
11. jvcleave commented on Aug 30, 2026

    

    jvcleave

    on Aug 30, 2026

    More actions

    I can corroborate this with a significantly larger reproduction from Codex Desktop on macOS.

    I analyzed the local logs for a single task, “Review audio core engine plan”, in one project. The rapid quota depletion appears to come from normal sequential model/tool continuations repeatedly processing an increasingly large retained context—not from a transport retry storm.

    Environment

    • Model: gpt-5.6-sol
    • Reasoning effort: High
    • Client: Codex Desktop / macOS
    • Task: single long-running implementation/review task
    • Feedback ID: 01a04fde-b8f2-7493-9cc6-ea24169753f1

    Observed usage

    • 296 shell/tool cycles across 6 turns
    • 40.7M input tokens processed
    • 39.7M cached input tokens
    • Cached share: ~97.5%
    • 5-hour allowance: 0% → 100% in ~35 minutes
    • After the allowance became available again: 0% → 93% in ~17 minutes
    • During that second period:
      • average input per model cycle: ~153K tokens
      • peak input per model cycle: ~230K tokens
    • One interrupted turn occurred, but I found no retry storm or repeated transport failure.
    • The task ultimately completed successfully.

    The logs suggest a pattern similar to the reproduction in this issue:

    model → tool/shell result → model with retained history → tool result → model with retained history ...

    As the task progressed, the retained context grew to roughly 150K–230K tokens. At that point even relatively small shell commands, file operations, builds, and test operations triggered another model cycle over a very large mostly-cached context.

    There was also approximately a 24K-token baseline on a fresh task from instructions/tool definitions/plugins/workspace context, but that does not appear to be the dominant cause here.

    Why this seems significant

    This reproduction is substantially larger than the one reported above:

    • This report: 40.7M input / 296 cycles
    • Original Single Terra Medium task reprocessed 10.1M input tokens (98% cached) across 76 exec turns and consumed 33% of 5-hour quota #41369 reproduction: 10.1M input / 76 exec calls

    In my case the task was doing legitimate work and was not caught in an obvious command retry or transport failure loop. The dominant usage appears to be repeated processing of accumulated context during ordinary agent/tool handoffs.

    This makes long Codex tasks unexpectedly expensive once their context becomes large. A build/test/inspect loop that is inexpensive early in a task becomes extremely quota-intensive later because each small operation can trigger another 150K–230K-token model invocation.

    Potential mitigations that seem relevant:

    • earlier pruning or summarization of completed tool output;
    • automatic context compaction based on cumulative model-input cost rather than only context-window pressure;
    • avoiding repeated verbatim inclusion of old build/test/tool output;
    • reducing unnecessary model re-entry during repetitive shell/build/test sequences;
    • warning users when per-cycle context has become large enough that continuing the task will rapidly consume quota;
    • clearer per-task reporting of total input, cached input, model cycles, and quota impact.

    I can provide sanitized log excerpts or additional aggregate measurements if useful.
12. jvcleave commented on Aug 30, 2026

    

    jvcleave

    on Aug 30, 2026

    More actions

    Additional reproduction after maintenance

    I performed another read-only analysis of Codex Desktop’s local session logs. The rapid quota depletion continued and was not caused by old session files, cache size, or a background process.

    During a fresh usage period from approximately 2:48–3:49 AM EDT:

    • Five-hour allowance: 0% → 100% in approximately 61 minutes
    • Input tokens processed: 26.7M
    • Cached input tokens: 26.1M
    • Cached share: approximately 97.5%
    • The activity came primarily from two normal Codex tasks:
      • MESS_SCENE_DICTATOR: 21.2M input across 156 model cycles
      • Add MessScene snapshots gallery: 5.6M input across 32 model cycles

    The main task used gpt-5.6-sol at xhigh reasoning effort. Its model input averaged approximately 136K tokens per cycle during this period and peaked above 209K. The snapshots task averaged approximately 174K and peaked near 237K.

    The main task performed three automatic context compactions. Each compaction successfully reduced the following request to approximately 25K–29K input tokens, but context quickly grew back above 200K. The task ultimately made 350 tool continuations and retained approximately 2.5M characters of tool output.

    I found:

    • no failed-turn loop;
    • no transport retry storm;
    • no active background task after completion;
    • no evidence that old archived or active session files were being processed independently.

    Across all recent activity from approximately 12:18–3:49 AM EDT, the logs recorded:

    • 99.5M input tokens
    • 95.3M cached input tokens
    • 755 model-usage events
    • 705 tool calls

    A newly created task also processed 14.8M input tokens across 102 cycles, showing that the issue is not limited to resuming old threads. A fresh task can become quota-intensive quickly when ordinary shell/build/test continuations accumulate context.

    This strengthens the original report: successful compaction temporarily reduces context size, but context regrows rapidly, and repeated mostly-cached model/tool continuations can still exhaust an entire five-hour allowance in about one hour.

    Potential areas for investigation remain:

    • weighting of cached input against subscription limits;
    • earlier or cost-based compaction;
    • cumulative pruning of completed tool output;
    • fewer model re-entries during repetitive shell/build/test work;
    • warnings when per-cycle input exceeds a threshold such as 100K tokens;
    • per-task reporting of model cycles, cached input, compactions, and quota impact.

    ---
13. dimasyankauskas commented on Sep 7, 2026

    

    dimasyankauskas

    on Sep 7, 2026 – with ChatGPT Codex Connector

    More actions

    Corroborating current macOS and iPhone Remote datapoint from September 7, 2026.

    Environment

    • ChatGPT/Codex Desktop 26.901.51231 build 8109
    • Bundled Codex runtime 0.153.4
    • macOS 27.0 build 26A5425a, arm64
    • ChatGPT iOS Remote client 1.2026.237
    • GPT-6 Astra/high for one coordinator and two subagents
    • GPT-5.6 Sol/high for a separate root task

    Fixed six-hour measurement

    Across four active implementation threads:

    • 1,000 distinct nonzero model-usage updates
    • 138,997,075 input tokens
    • 135,314,304 cached input tokens
    • 97.35% cached share
    • Median input per model cycle: 139,888 tokens
    • Maximum input: 242,849 tokens
    • 406,005 output tokens
    • Nine automatic compactions

    The coordinator and two subagents for one project accounted for 867 cycles and approximately 119M input tokens. This shows substantial multi-agent amplification from repeated processing of large retained context.

    Compaction was functioning: observed post-compaction requests fell from approximately 227K–278K input tokens to approximately 38K–40K. Context then grew again and subsequent tool continuations resumed processing large cached prefixes.

    Checks against alternative causes

    • No sampling-request retries, 429 responses, or rate-limit errors appeared during the fixed measurement window.
    • Repeated token-usage snapshots were excluded. For comparable updates, cumulative-counter increases matched the reported per-step usage.
    • Duplicate snapshots did not increment the cumulative counters again.
    • The tasks were performing real implementation work, but frequent tool continuations, coordinator/subagent communication, and waiting checks repeatedly invoked the model with large histories.

    Separately, iPhone Remote thread resumes produced state-reconstruction warnings, including ignored state patches without a full snapshot. Desktop logs also showed missing-conversation-state events. I have not established that these UI/session errors caused additional charged inference, so I am reporting them only as potentially relevant remote-session context.

    This reproduction supports the issue’s cached-context/workflow-amplification mechanism. It does not establish a server-side billing defect.