Repository navigation
[Bug] Codex Desktop replays ~150k cached input per tool call and rapidly drains Plus usage #44386
Description
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT/Codex Desktop 26.903.61454 (build 8378); bundled Codex CLI 0.153.4.
What subscription do you have?
ChatGPT Plus.
What platform is your computer?
Darwin 25.6.0 arm64 arm
What issue are you seeing?
A short Codex Desktop conversation with small user messages rapidly consumes the 5-hour allowance because the full cached context is replayed for every model/tool step.
In the affected session:
- Input tokens: 5,690,989
- Cached input tokens: 5,511,680 (~96.9%)
- Output tokens: 17,161
- Reasoning output tokens: 8,582
- Per-call input near the end: ~158,000 tokens
- Per-call cached input near the end: ~157,000 tokens
- Effective model context window reported by the rollout: 258,400 tokens
- 5-hour usage increased from 11% to approximately 30% during a short diagnostic conversation
The user messages themselves were short. The dominant usage was repeated cached-input replay across tool calls.
This is on gpt-5.6-sol with model_reasoning_effort = "medium" and default service tier.
The local user Skill directory contains only .system; no personal Skill is installed there. However, codex plugin list --json reports nine OpenAI bundled/runtime plugins as installed and enabled:
codex-app-tools@openai-bundledunified-computer-use@openai-bundledchrome@openai-bundledvisualize@openai-bundleddocuments@openai-primary-runtimepdf@openai-primary-runtimespreadsheets@openai-primary-runtimepresentations@openai-primary-runtimetemplate-creator@openai-primary-runtime
codex-app-tools eagerly exposes a large Codex Desktop MCP tool surface. Its bundled MCP configuration has no deferred-tool configuration. unified-computer-use contains omit_tools_from = ["code_mode", "deferred"].
The feature inventory reports:
skill_search stable true
tool_search removed false
executor_capability_discovery under development false
recommended_plugins stable false
Despite recommended_plugins reporting false, codex debug prompt-input shows that a 3,315-character <recommended_plugins> block is still injected into a fresh prompt.
For a fresh prompt containing only seven user characters, codex debug prompt-input reports 17,349 characters of message context before the actual user text:
skills instructions 5,307 chars
permissions 362 chars
apps instructions 646 chars
plugins instructions 1,014 chars
multi-agent instructions 2,535 chars
recommended plugins 3,315 chars
AGENTS.md 3,438 chars
environment context 422 chars
This 17k-character message context does not include the separately supplied tool schemas. Actual model requests in the affected Desktop thread reached ~158k input tokens.
codex doctor --summary reports that the configuration loads successfully with zero configuration warnings, so this does not appear to be a malformed config file.
What steps can reproduce the bug?
- Use Codex Desktop 26.903.61454 on macOS with the OpenAI bundled/runtime plugins above enabled.
- Use
gpt-5.6-solwith medium reasoning. - Start a new projectless Codex conversation and send a few short questions about Codex configuration or usage.
- Let Codex perform several normal web/shell inspection calls.
- Inspect the current rollout JSONL
token_usage_recordandtoken_countevents. - Observe that each model step replays an increasingly large cached context (~150k tokens in this reproduction), while the 5-hour usage percentage rises rapidly.
- Run
codex debug prompt-input 'test'and observe that the recommended-plugin block is present even though the feature inventory reportsrecommended_plugins = false.
Affected session ID:
01a08919-3f68-7412-baee-d58708d7718d
The raw rollout is not attached publicly because it contains conversation and local-environment details, but it can be provided privately to OpenAI maintainers if needed.
What is the expected behavior?
- Bundled plugin tools should use progressive disclosure/tool search rather than eagerly supplying a large tool schema catalog.
- Cached context should not drain a Plus allowance this quickly during ordinary short conversations and inspection calls.
- A disabled
recommended_pluginsfeature should not inject the full unavailable-plugin list. - Codex Desktop should expose per-turn quota attribution for uncached input, cached input, output, reasoning, and tool/schema overhead.
- Context should be compacted or pruned before repeated tool calls replay ~150k tokens.
Additional information
This appears related to, but is not identical to:
- [Bug] Code Mode nested exec output truncation causes repeated context growth and extreme cached-token quota consumption #40897 — repeated context growth and extreme cached-token quota consumption during tool calls
- Codex 5-hour usage meter appears to consume much faster than comparable historical usage #28823 — 5-hour usage meter consuming much faster than comparable historical usage
- Usage runs out much faster than normal & abnormal context window usage #24896 — abnormal context usage in a session started with a simple
hi - Monthly usage limit drains abnormally fast (25% → 5% within ~15 tool calls in one session) #33634 — usage draining rapidly across a small number of ordinary tool calls
The distinguishing details here are Codex Desktop, OpenAI-bundled plugins, the absence of personal Skills, eager app-tool exposure, and recommended_plugins=false not preventing prompt injection.
Activity
github-actions commentedon Sep 10, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
sbrin commentedon Sep 11, 2026
Seeing something very similar on Codex Desktop / CLI 0.153.4 with ChatGPT Plus, but using gpt-6-astra.
I inspected the local rollout JSONL files after a short session took my 5-hour allowance from 100% available to 0% within roughly several minutes of heavy agent activity.
Across 6 related rollouts I found:
7,556,639 input tokens
6,831,744 cached input tokens (~90.4%)
only 42,784 output tokens
The pattern is similar to this issue: model → tool → model → tool, with the growing context replayed on each model continuation.
pvlbgtrv commentedon Sep 13, 2026
Token usage: total=4 755 738 input=4 245 994 (+ 133 349 888 cached) output=509 744 (reasoning 222 759)
codex plus, model sol-luna medium, 5h limit for 20 minutes
joosequezada commentedon Oct 19, 2026
I'm experiencing a similar issue with Codex Desktop on macOS. Since the changes to the 5-hour usage limits, my available usage seems to drain considerably faster than it did previously.
I investigated this using local Codex session logs and compared older sessions with recent ones.
Environment
macOS (Apple Silicon)
Codex Desktop:
26.1013.40934Bundled runtime:
0.163.0-alpha.10.2Codex CLI stable:
0.160.1Model:
gpt-5.6-solChatGPT Plus
Findings from local session logs
October 16 — Long-running Desktop session:
Total tokens: 35,626,999
Input tokens: 35,541,247
Cached input tokens: 34,679,808 (~97.6% of input)
Output tokens: 85,752
Token usage measurements: 274
Tool calls: 258
Maximum input tokens in a single measurement: 204,477
Model context window: 258,400
Compaction events: 2
The initial input size was approximately 34k tokens, eventually reaching over 200k tokens per measurement.
Historical comparison:
Date | Runtime | Total tokens | Token measurements -- | -- | -- | -- Aug 22 | 0.148.0-alpha.9 | 54.47M | 407 Aug 26 | 0.150.0-alpha.8 | 17.84M | 269 Sep 10 | 0.153.1 | 10.62M | 86 Oct 16 | 0.163.0-alpha.10.2 | 35.63M | 274All sessions used
gpt-5.6-sol.These historical logs show that high token volumes existed before October. Therefore, I cannot establish a token-efficiency regression solely from these totals.
Controlled benchmark
I created a clean project directory and ran three small Go programming tasks in separate Codex Desktop sessions:
Generate a function and unit test: 35,527 tokens
Analyze a concurrency issue: 71,845 tokens
Create and execute a simple Go program: 142,985 tokens
Total: 250,357 tokens.
The 5-hour quota usage indicator increased from 0% to 5% across these three tasks.
I also tested Codex CLI stable
0.160.1using the same model. Two CLI sessions recorded 69,305 and 115,981 tokens, respectively. However, those sessions contained additional turns, so the results are not directly comparable to the Desktop benchmark.Additional observation
On October 18, Codex Desktop generated 11 rollout files within approximately one second, some containing hundreds of events. Their metadata showed
history_mode: legacy, with no parent thread ID or agent role.This may reflect history reconstruction or migration rather than actual model requests. I have not established that these events consumed quota.
Questions for the Codex team
Are cached input tokens weighted differently against the 5-hour or weekly usage limits after the recent quota changes?
Is repeatedly processing 150k–200k cached input tokens during tool calls expected behavior?
Could changes in quota accounting explain why the same general development workflow now exhausts usage faster?
Is there any known difference in quota consumption between Codex Desktop alpha and the stable CLI when using the same model?
Could session restoration or history migration cause unexpected model requests or quota consumption?
I haven't confirmed a quota-accounting bug, but the local telemetry shows substantial cached-context reuse, and the available usage now feels significantly more restrictive than before.
I can provide sanitized per-request token data, timestamps, and session logs if needed.
Thank you for investigating.