[Regression] Codex repeatedly reprocesses massive cached context in long sessions, causing severe latency, timeouts, JSONL growth, and excessive credit usage
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.
10 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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:
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:
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.
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.
Corroborating report from Codex Desktop on macOS, observed on July 24, 2026.
Environment
26.721.410590.146.0-alpha.3.1gpt-5.6-solmediumandxhighAggregate observation
Across four long-running tasks during one 24-hour window:
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
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
/feedbacksubmission was attempted, but automated access to the Codex Desktop feedback dialog was unavailable and the bundled CLI treated/feedbackas ordinary conversation input; no feedback receipt was produced.Private repository names, paths, task IDs, and transcripts are intentionally omitted.
The multi-gigabyte rollout expansion from repeated inline images inside
compactedreplacement 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:
Or diagnose whether any rollout records exceed bounded reader thresholds:
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.
I can reproduce the local-storage aspect on Codex Desktop/macOS in a separate workload.
Before cleanup, a read-only local scan reported:
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.
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:
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:
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.
Corroborating Windows Codex Desktop datapoint from August 22, 2026. This looks very close to the cached-context reprocessing / usage-impact behavior described here.
Environment
26.818.4152.0(updated from26.818.3698.0)0.149.0gpt-5.6-solxhighOriginal large-context configuration
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:
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:
The last event contained:
197552108411699.5%10.137MThe 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
#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.
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 scangives those numbers read-only if anyone wants to attach concrete sizes to their reproductions.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.