Context compaction regression in CLI v0.118 — 2x more frequent compactions cause token usage explosion
Environment:
- CLI: v0.118.0-alpha.2 (regression compared to v0.116.0-alpha.10)
- Model: gpt-5.3-codex
- OS: macOS (Darwin 25.4.0)
- Reasoning effort: xhigh
Summary:
After upgrading from CLI v0.116 to v0.118, context compaction triggers approximately twice as frequently, causing a cascading re-read loop that doubles or triples total token consumption for identical tasks.
Hard data from session analysis:
| Metric | v0.116 (Mar 23) | v0.118 (Apr 4) |
|--------|-----------------|----------------|
| Compaction interval | ~697 events | ~313–574 events |
| Compactions per session | 4 | 12–26 |
| Token usage (comparable tasks) | 89M | 160–185M |
| Function calls between compactions | 120–280 | 87–174 |
Root cause analysis:
The compaction threshold appears to have been lowered in v0.118. This creates a token amplification loop:
- Agent reads large context files (project docs, OpenAPI specs, analysis docs) → context fills up
- Compaction triggers (now ~2x more often) → file contents are evicted from context
- Agent re-reads the same files to continue work → context fills up again
- Goto 2
In a session with 26 compactions (v0.118), the same ~150KB of essential context files were re-read after every compaction, multiplying actual token consumption by 10-20x compared to the "useful" work done.
Specific session comparison (same project, same config, same reasoning effort):
- v0.116 session (analysis task): 89M tokens, 4 compactions, 372 file reads, 113 unique files
- v0.118 session (review task): 185M tokens, 12 compactions, 849 file reads, 297 unique files
- v0.118 session (gap analysis): 160M tokens, 26 compactions, 424 file reads, 183 unique files
Developer instructions diff between versions:
Only change is 6 new git-directive emit lines (+773 chars). No functional change that would explain the compaction frequency increase.
Impact:
- Token costs roughly doubled for the same type of work
- Projects with structured documentation (large analysis docs, API specs, architecture docs) are disproportionately affected
- The compaction-reread cycle is self-reinforcing — more compactions → more re-reads → faster next compaction
Expected behavior:
Compaction frequency should remain consistent across CLI versions when the same model, reasoning effort, and project are used. If compaction behavior was intentionally changed, a configuration option (e.g., compaction_threshold in config.toml) would help users control the trade-off.
Reproduction:
Any project with >100KB of essential context files (that the agent needs to re-read after compaction) will exhibit this pattern. The larger the essential context, the worse the amplification.
Possibly related issues:
- #9287 —
estimate_token_countunits bug causing ~4x overcount, which triggers compaction at ~25% context usage instead of 100%. If this fix was partially reverted or regressed in v0.118, it would explain the doubled compaction frequency. - #13946 — Compaction can loop indefinitely when it fails to reduce token usage below the threshold. The 26-compaction session in my data may be hitting this.
- #14589 — Compaction discards all tool outputs and assistant reasoning, leaving only ~20K tokens of user messages + one summary. This explains why the agent must re-read all files after each compaction — the file contents are gone.
- #15848 — Feature request for autonomous compaction after task phases, which would be a better strategy than the current threshold-based approach for long-running sessions.
Data available:
I have full session JSONL logs for both v0.116 and v0.118 sessions and can provide them on request. Analysis was done by extracting exec_command function calls and compacted events from the session files.
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Not a duplicate of any of the suggested issues:
The core contribution of this issue is the before/after comparison showing that compaction frequency doubled between CLI versions while project, config, and reasoning effort remained identical — plus the analysis of the resulting re-read amplification loop.
Thanks for the detailed report. I checked the client source between v0.116.0-alpha.10 and v0.118.0-alpha.2 and couldn’t find a compaction-threshold reduction.
gpt-5.3-codexstill has context_window=272000. Auto-compaction still derives 90% of that when no override is set, and the trigger remainstotal_usage_tokens>=auto_compact_limit.Your analysis used "event counts", but the number of events is not considered when determining compaction triggers. It's the estimated token count that matters. Event contents can vary in size. I suspect what's happening is that the two sessions you compared have different average event content sizes, but without access to the rollout files I can't confirm. Another possible difference is the inclusion of images (or a different number of images) in one of the rollouts. Token estimates for images tends to be conservative to prevent context overflows.
Thanks for investigating. I checked the three points you raised against my session data.
1. "Different average event content sizes" — Content sizes per compaction cycle are comparable:
| Session | Avg content per cycle | Compactions |
|---------|----------------------|-------------|
| v0.116 (89M) | 713K chars / 178K tokens | 4 |
| v0.118 (185M) | 596K chars / 149K tokens | 14 |
| v0.118 (160M) | 780K chars / 195K tokens | 26 |
The v0.118 185M session actually has less content per cycle than v0.116 — yet compacts 3.5x more often.
2. "Inclusion of images" — Ruled out. None of the three sessions contain image data. The only "image" matches are text references in the Codex Desktop
<app-context>system instructions. Purely text/code project.3. Re-read amplification after compaction — Confirmed. Key files are systematically re-read after compaction:
Additional data point: Average time between compactions dropped from 31.5 min (v0.116) to 5.8 min (v0.118 160M session). That means the entire context is being rebuilt every 6 minutes.
The core question remains: If the threshold is still 90% of 272K, and per-cycle content is comparable or even lower — what changed in v0.118 that causes compaction to trigger earlier? Could the token estimator behave differently, or could the compaction summary itself be larger now, leaving less headroom before the next trigger?
I've prepared an metrics export (2.3 MB JSON — only event types, sizes, timestamps, no code or project content) that I can share if it helps with debugging.
I'm not able to repro the issue as reported, and we haven't received any other reports of increased compaction rates. I've asked codex to review commits between 116 and 118 for any that could impact compaction rates, and it didn't find anything. It's possible that some change had an indirect impact on rollout events, but nothing stands out. We haven't changed the token estimator during this timeframe.
The compaction summary is generated by a model, and its size will differ based on session content, including the mixture of tool outputs, user prompts, and model outputs. That might explain the difference you're seeing.
Do you have a deterministic repro? If so, could you try 0.117.0 as a mid-point? And if you're able/willing to build from source, you could further bisect to locate the commit that's responsible for the behavioral difference you're seeing.
Following up with results from a controlled test.
Test setup: Identical prompt, same config (gpt-5.3-codex, xhigh), same workspace, read-only sandbox. The prompt reads ~2 MB of files (docs, OpenAPI spec, source code, tests) across 10 steps with two re-read verification passes.
Results:
| Metric | v0.116 | v0.118 |
|--------|--------|--------|
| Compactions | 3 | 2 |
| Function calls | 218 | 140 |
| File reads | 207 | 116 |
| openapi.yaml reads | 53x | 26x |
| Total output | 3489 KB | 1915 KB |
v0.116 compacted more than v0.118 on the same prompt. Your hypothesis about task complexity as the driver was confirmed by the test — the token explosion in my earlier sessions was driven by a large multi-feature concept (93 KB analysis + 58 KB plan + 610 KB OpenAPI spec), not a compaction threshold change.
The underlying problem though — the re-read loop after compaction — is real regardless of the trigger. In both versions, the OpenAPI spec was re-read 26-53 times because compaction drops all tool outputs. I've opened a separate feature request for this: I'll link it below.
Thanks for taking the time to dig into this. Closing as not-a-bug.
Closed as not-a-bug. Feature request for the underlying re-read problem: #16839