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

Open 💬 10 comments Opened Jul 23, 2026 by brolabitalia
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.145.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

gpt-5.4 with xhigh reasoning

What platform is your computer?

Microsoft Windows 11 Home | Version 10.0.26200 | 64 bit

What terminal emulator and version are you using (if applicable)?

Codex CLI TUI launched from PowerShell on Windows PowerShell version: 5.1.26100.8875

Codex doctor report

{
  "schemaVersion": 1,
  "generatedAt": "1784823909s since unix epoch",
  "overallStatus": "warning",
  "codexVersion": "0.145.0",
  "checks": {
    "app_server.status": {
      "id": "app_server.status",
      "category": "app-server",
      "status": "ok",
      "summary": "background server is not running",
      "details": {
        "control socket": "C:\\Users\\<USER>\\.codex\\app-server-control\\app-server-control.sock",
        "daemon state dir": "C:\\Users\\<USER>\\.codex\\app-server-daemon",
        "mode": "ephemeral",
        "pid file": "C:\\Users\\<USER>\\.codex\\app-server-daemon\\app-server.pid (missing)",
        "settings": "C:\\Users\\<USER>\\.codex\\app-server-daemon\\settings.json (missing)",
        "status": "not running",
        "update-loop pid file": "C:\\Users\\<USER>\\.codex\\app-server-daemon\\app-server-updater.pid (missing)"
      },
      "remediation": null,
      "durationMs": 0
    },
    "auth.credentials": {
      "id": "auth.credentials",
      "category": "auth",
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "auth env vars present": "<redacted>",
        "auth file": "C:\\Users\\<USER>\\.codex\\auth.json",
        "auth storage mode": "<redacted>",
        "stored API key": "<redacted>",
        "stored ChatGPT tokens": "<redacted>",
        "stored agent identity": "<redacted>",
        "stored auth mode": "<redacted>"
      },
      "remediation": null,
      "durationMs": 0
    },
    "config.load": {
      "id": "config.load",
      "category": "config",
      "status": "ok",
      "summary": "config loaded",
      "details": {
        "CODEX_HOME": "C:\\Users\\<USER>\\.codex",
        "config.toml": "C:\\Users\\<USER>\\.codex\\config.toml",
        "config.toml parse": "ok",
        "cwd": "C:\\Users\\<USER>",
        "enabled feature flags": "<redacted>",
        "feature flag overrides": "none",
        "feature flags enabled": "36",
        "log dir": "C:\\Users\\<USER>\\.codex\\log",
        "mcp servers": "1",
        "model": "gpt-5.4",
        "model provider": "openai",
        "sqlite home": "C:\\Users\\<USER>\\.codex"
      },
      "remediation": null,
      "durationMs": 0
    },
    "git.environment": {
      "id": "git.environment",
      "category": "git",
      "status": "ok",
      "summary": "git version 2.52.0.windows.1",
      "details": {
        "PATH git #1": "C:\\Program Files\\Git\\cmd\\git.exe",
        "PATH git entries": "1",
        "git build options": "git version 2.52.0.windows.1; cpu: x86_64; built from commit: 2912d8e9b8253723974b7baf1c890273b1a1c5bd; sizeof-long: 4; sizeof-size_t: 8; shell-path: D:/git-sdk-64-build-installers/usr/bin/sh; rust: disabled; feature: fsmonitor--daemon; libcurl: 8.17.0; OpenSSL: OpenSSL 3.5.4 30 Sep 2025; zlib: 1.3.1; SHA-1: SHA1_DC; SHA-256: SHA256_BLK; default-ref-format: files; default-hash: sha1",
        "git exec path": "C:/Program Files/Git/mingw64/libexec/git-core",
        "git version": "git version 2.52.0.windows.1",
        "repo detected": "false",
        "selected git": "C:\\Program Files\\Git\\cmd\\git.exe"
      },
      "remediation": null,
      "durationMs": 121
    },
    "installation": {
      "id": "installation",
      "category": "install",
      "status": "ok",
      "summary": "installation looks consistent",
      "details": {
        "PATH codex #1": "C:\\Users\\<USER>\\AppData\\Roaming\\npm\\codex",
        "PATH codex #2": "C:\\Users\\<USER>\\AppData\\Roaming\\npm\\codex.cmd",
        "PATH codex entries": "2",
        "current executable": "C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin\\codex.exe",
        "install context": "npm (package C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc, bin C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin, resources C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-resources, path C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-path)",
        "managed by bun": "false",
        "managed by npm": "true",
        "managed by pnpm": "false",
        "managed package root": "C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex",
        "npm update target": "C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex"
      },
      "remediation": null,
      "durationMs": 544
    },
    "mcp.config": {
      "id": "mcp.config",
      "category": "mcp",
      "status": "ok",
      "summary": "MCP configuration is locally consistent",
      "details": {
        "configured servers": "1",
        "disabled servers": "0",
        "stdio servers": "1"
      },
      "remediation": null,
      "durationMs": 0
    },
    "network.env": {
      "id": "network.env",
      "category": "network",
      "status": "ok",
      "summary": "network-related environment looks readable",
      "details": {
        "proxy env vars": "none"
      },
      "remediation": null,
      "durationMs": 0
    },
    "network.provider_reachability": {
      "id": "network.provider_reachability",
      "category": "reachability",
      "status": "ok",
      "summary": "active provider endpoints are reachable over HTTP",
      "details": {
        "openai API base URL": "https://api.openai.com/v1 reachable (HTTP 404)",
        "openai API route probe": "https://api.openai.com/v1/<redacted> route exists (HTTP 401)",
        "reachability mode": "<redacted>"
      },
      "remediation": null,
      "durationMs": 420
    },
    "network.websocket_reachability": {
      "id": "network.websocket_reachability",
      "category": "websocket",
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded",
      "details": {
        "DNS": "2 IPv4, 0 IPv6, first IPv4",
        "auth mode": "<redacted>",
        "connect timeout": "15000 ms",
        "endpoint": "wss://chatgpt.com/backend-api/<redacted>",
        "handshake result": "HTTP 101 Switching Protocols",
        "model provider": "openai",
        "models etag present": "true",
        "provider name": "OpenAI",
        "proxy env vars": "none",
        "reasoning header": "false",
        "server model present": "false",
        "supports websockets": "true",
        "wire API": "responses"
      },
      "remediation": null,
      "durationMs": 582
    },
    "runtime.provenance": {
      "id": "runtime.provenance",
      "category": "runtime",
      "status": "ok",
      "summary": "running npm on windows-x86_64",
      "details": {
        "commit": "unknown",
        "current executable": "C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin\\codex.exe",
        "install method": "npm (package C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc, bin C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\bin, resources C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-resources, path C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-path)",
        "platform": "windows-x86_64",
        "version": "0.145.0"
      },
      "remediation": null,
      "durationMs": 0
    },
    "runtime.search": {
      "id": "runtime.search",
      "category": "search",
      "status": "ok",
      "summary": "search is OK (bundled)",
      "details": {
        "search command": "C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex\\node_modules\\@openai\\codex-win32-x64\\vendor\\x86_64-pc-windows-msvc\\codex-path\\rg.exe",
        "search command readiness": "file exists",
        "search provider": "bundled"
      },
      "remediation": null,
      "durationMs": 0
    },
    "sandbox.helpers": {
      "id": "sandbox.helpers",
      "category": "sandbox",
      "status": "ok",
      "summary": "sandbox configuration is readable",
      "details": {
        "approval policy": "OnRequest",
        "codex-linux-sandbox helper": "none",
        "execve wrapper helper": "none",
        "filesystem sandbox": "restricted",
        "network sandbox": "restricted"
      },
      "remediation": null,
      "durationMs": 1
    },
    "state.paths": {
      "id": "state.paths",
      "category": "state",
      "status": "ok",
      "summary": "state paths and databases are inspectable",
      "details": {
        "CODEX_HOME": "C:\\Users\\<USER>\\.codex (dir)",
        "active rollout files": "268 files, 4232473473 total bytes, 15792811 average bytes",
        "archived rollout files": "0 files, 0 total bytes, 0 average bytes",
        "goals DB": "C:\\Users\\<USER>\\.codex\\goals_1.sqlite (file)",
        "goals DB integrity": "ok",
        "log DB": "C:\\Users\\<USER>\\.codex\\logs_2.sqlite (file)",
        "log DB integrity": "ok",
        "log dir": "C:\\Users\\<USER>\\.codex\\log (dir)",
        "memories DB": "C:\\Users\\<USER>\\.codex\\memories_1.sqlite (file)",
        "memories DB integrity": "ok",
        "sqlite home": "C:\\Users\\<USER>\\.codex (dir)",
        "state DB": "C:\\Users\\<USER>\\.codex\\state_5.sqlite (file)",
        "state DB integrity": "ok",
        "thread history DB": "C:\\Users\\<USER>\\.codex\\thread_history_1.sqlite (missing)",
        "thread history DB integrity": "skipped (missing)"
      },
      "remediation": null,
      "durationMs": 1711
    },
    "state.rollout_db_parity": {
      "id": "state.rollout_db_parity",
      "category": "threads",
      "status": "warning",
      "summary": "rollout files and state DB thread inventory differ",
      "details": {
        "default model provider": "openai",
        "rollout DB active files": "267",
        "rollout DB active rows": "267",
        "rollout DB archive mismatches": "0",
        "rollout DB archived files": "0",
        "rollout DB archived rows": "0",
        "rollout DB duplicate DB paths": "0",
        "rollout DB duplicate rollout thread ids": "0",
        "rollout DB malformed file names": "0",
        "rollout DB missing active rows": "0",
        "rollout DB missing archived rows": "0",
        "rollout DB model providers": "openai=267",
        "rollout DB rows": "267",
        "rollout DB scan cap reached": "false",
        "rollout DB scan error sample": "C:\\Users\\<USER>\\.codex\\sessions\\2026\\02\\03\\rollout-2026-02-03T10-05-11-<REDACTED_THREAD_ID>.jsonl (rollout at C:\\Users\\<USER>\\.codex\\sessions\\2026\\02\\03\\rollout-2026-02-03T10-05-11-<REDACTED_THREAD_ID>.jsonl has no usable header record)",
        "rollout DB scan errors": "1",
        "rollout DB sources": "cli=264, subagent:thread_spawn=3",
        "rollout DB stale rows": "0"
      },
      "issues": [
        {
          "severity": "warning",
          "cause": "rollout scan was incomplete or found bad files",
          "measured": "1 scan errors, 0 malformed names, scan cap reached: false",
          "expected": "rollout directories are fully scannable",
          "remedy": "Check file permissions and unexpected files under CODEX_HOME sessions.",
          "fields": []
        }
      ],
      "remediation": null,
      "durationMs": 424
    },
    "system.environment": {
      "id": "system.environment",
      "category": "system",
      "status": "ok",
      "summary": "OS language it-IT",
      "details": {
        "EDITOR": "not set",
        "VISUAL": "not set",
        "os": "Windows 10.0.26200 (Windows 11 Core) [64-bit]",
        "os language": "it-IT",
        "os type": "Windows",
        "os version": "10.0.26200"
      },
      "remediation": null,
      "durationMs": 2
    },
    "terminal.env": {
      "id": "terminal.env",
      "category": "terminal",
      "status": "warning",
      "summary": "width 56 cols - output may wrap (recommended >=80)",
      "details": {
        "WT_SESSION": "present",
        "color output": "enabled",
        "console input code page": "850",
        "console output code page": "850",
        "stderr console mode": "0x00000007 (VT processing: true)",
        "stderr is terminal": "true",
        "stdin is terminal": "true",
        "stdout console mode": "0x00000007 (VT processing: true)",
        "stdout is terminal": "true",
        "terminal": "Windows Terminal",
        "terminal size": "56x30"
      },
      "issues": [
        {
          "severity": "warning",
          "cause": "width 56 cols - output may wrap (recommended >=80)",
          "measured": "56 x 30",
          "expected": ">= 80 columns",
          "remedy": "resize the window to at least 80 columns",
          "fields": [
            "terminal size"
          ]
        }
      ],
      "remediation": null,
      "durationMs": 1
    },
    "terminal.title": {
      "id": "terminal.title",
      "category": "title",
      "status": "ok",
      "summary": "terminal title default",
      "details": {
        "terminal title activity": "true",
        "terminal title items": "activity, project-name",
        "terminal title project source": "cwd",
        "terminal title project value": "<USER>",
        "terminal title source": "default"
      },
      "remediation": null,
      "durationMs": 0
    },
    "updates.status": {
      "id": "updates.status",
      "category": "updates",
      "status": "ok",
      "summary": "update configuration is locally consistent",
      "details": {
        "cached latest version": "0.145.0",
        "check for update on startup": "true",
        "last checked at": "2026-07-23T04:46:19.354953300Z",
        "latest version": "0.145.0",
        "latest version status": "current version is not older",
        "npm update target": "C:\\Users\\<USER>\\AppData\\Roaming\\npm\\node_modules\\@openai\\codex",
        "update action": "npm install -g @openai/codex",
        "version cache": "C:\\Users\\<USER>\\.codex\\version.json"
      },
      "remediation": null,
      "durationMs": 565
    }
  }
}

What issue are you seeing?

I am seeing what appears to be a serious Codex/model operational regression affecting latency, agent loops, context processing, and credit usage during long coding sessions.

The affected workload is BROMIND, a comparatively small narrative game project. Codex has recently become dramatically slower and more expensive even for limited patches, visual corrections, and read-only audits.

I compared the affected July workload against April-June sessions used for AFTERFALL, a much larger and substantially more intensive MMORPG project involving server, client, website, database, Linux migrations, builds, dungeons, maps, and cross-component dependencies.

The historical AFTERFALL workload was objectively more intensive:

  • April-June: 47,484 tool calls
  • April-June: 42,513 shell commands
  • April-June: 6,146 build/operations signals
  • April-June: 4,526 non-zero command exits

July had:

  • 15,677 tool calls
  • 11,290 shell commands
  • 2,966 build/operations signals
  • 975 non-zero exits

Despite the smaller operational workload, July consumed:

  • 2,516,506,098 total tokens
  • 2,406,631,040 cached input tokens
  • 96.07% cached share
  • 14,342 model cycles
  • 175,464 average tokens per model cycle

Only about 98.42M input tokens were new. The dominant behavior was repeated processing of a very large cached context.

One affected gpt-5.4 session, created on July 17 and continued until July 23, recorded:

  • 358,699,857 total tokens
  • 356,208,797 input tokens
  • 325,309,568 cached input tokens
  • 30,899,229 estimated new input tokens
  • 2,491,060 output tokens
  • 1,116,234 reasoning output tokens
  • 2,259 unique model cycles
  • average 158,787 tokens per cycle
  • context occupancy reaching 94.8%

Individual tasks in this session consumed between approximately 13.7M and 18.1M tokens, sometimes for work lasting only 40-75 minutes.

The same session also produced a 1.9 GB local JSONL file. Fifty compacted records occupied about 1.748 GB. Approximately 1.737 GB consisted of inline base64 images repeatedly serialized inside payload.replacement_history.

Forty-two distinct image messages appeared 1,026 times across compactions, with the same screenshot copied as many as 28 times.

The image duplication does not appear to correspond one-to-one with billed backend tokens, but it causes extreme local session growth and indicates problematic compaction/session handling.

The backend consumption problem appears broader: the dominant cost is repeated processing of cached context across thousands of model cycles. Compactions account directly for only a small percentage of tokens, but tasks containing compactions account for most of the expensive saturated-context phase.

There were also many timeouts, failed commands, and repeated tool loops while the context was close to its limit. These caused additional model cycles to process nearly the same large context.

Observed user impact:

  • Severe slowdown compared with earlier Codex usage
  • Small patches taking 40-75 minutes
  • Repeated tool loops in 90-95% saturated contexts
  • Frequent timeouts and failed-command recovery cycles
  • Disproportionate credit consumption
  • Multi-gigabyte local session files
  • A single read-only comparative audit reduced the observed credit balance from 724 to 709 while it was running

This does not look explainable by project complexity alone. AFTERFALL generated substantially more real tool and shell activity and was subjectively much faster and more effective.

I suspect a regression in Codex/model operational behavior, agent orchestration, cached-context handling, or the session/compaction pipeline. Local logs cannot isolate which internal component changed behind the public model name.

What steps can reproduce the bug?

Uploaded thread: 019f6ec7-885b-7e42-a73d-23ef210d4e20

What is the expected behavior?

Codex should avoid repeatedly reprocessing nearly the entire historical context for every tool-loop step.

After compaction:

  • old inline image payloads should be replaced by references, hashes, placeholders, or concise textual summaries;
  • the same base64 image should not be serialized repeatedly into every new replacement_history;
  • completed historical tool loops should be summarized instead of repeatedly reintroduced;
  • cached-context size should remain bounded;
  • small follow-up patches should not require hundreds of model cycles or tens of millions of tokens;
  • failed commands and timeouts should not cause repeated near-full-context inference loops;
  • users should receive a warning or automatic session rotation recommendation before context saturation becomes extremely expensive.

A long session should remain usable without growing to multiple gigabytes locally or consuming hundreds of millions of backend tokens.

Additional information

I performed three read-only local audits using streaming analysis rather than loading the JSONL files into memory.

Attached report:

CODEX_SESSION_PERFORMANCE_AUDITS_SANITIZED.md

CODEX_SESSION_PERFORMANCE_AUDITS_SANITIZED.md

Important distinction:

  • The approximately 1.9 GB JSONL growth is primarily caused by duplicated inline images in compacted replacement histories.
  • The backend token/credit consumption is primarily caused by repeated processing of very large cached contexts across thousands of model cycles.
  • These are related but not identical defects.

The original affected JSONL is approximately 1.9 GB and may contain private project history, so I have not attached it publicly. I can provide targeted redacted records or hashes of duplicated image entries if requested by an OpenAI maintainer.

The issue appears as a regression in practical Codex behavior compared with earlier, objectively more intensive workloads. The available local data cannot determine whether the internal cause is the model snapshot, routing, agent loop, tool orchestration, session management, or context-compaction backend.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34915
  • #33760
  • #34176

Powered by Codex Action

grtninja · 1 month ago

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.

grtninja · 1 month ago

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.

Nielsony · 1 month ago

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.

shleder · 9 days ago

The multi-gigabyte rollout expansion from repeated inline images inside compacted replacement histories is a primary storage hazard modeled by Codex Rescue. Rescue uses bounded chunk streaming so it can profile disk footprints and inspect oversized JSONL records (>16 MiB / >1 GB) without memory exhaustion.

You can inspect session disk footprints and large payload distributions locally using:

npx --yes codex-rescue storage

Or diagnose whether any rollout records exceed bounded reader thresholds:

npx --yes codex-rescue doctor --latest

It operates strictly read-only and local-first with zero telemetry. If you run it against your heavy session, the storage distribution output would be great field validation.

Nielsony · 7 days ago

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.

drakerfire98 · 6 days ago

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 (#33493).
  • Full-history resend / cache-reuse edge cases in long sessions (#32533).
  • Multi-agent/fork history and quota-drain reports that may represent a related amplification path (#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.

amatsuki5032 · 6 days ago

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.

shleder · 1 day ago

Corroborating datapoint from my side, plus a measurement suggestion: repeated cached-context reprocessing correlates with runaway rollout growth, so per-session byte tracking is useful evidence. vetto rescue --json scan gives those numbers read-only if anyone wants to attach concrete sizes to their reproductions.

FromAriel · 12 hours ago

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.