Allow adaptive context-window expansion based on compaction feedback

What variant of Codex are you using?

Codex CLI and ChatGPT desktop app

What feature would you like to see?

Summary

I would like Codex to support an opt-in adaptive context budget that starts conservatively and uses the result of each automatic compaction to decide whether to expand the available context.

The expansion would always remain within the model's real context window and catalog limits.

Problem

A fixed usable context window forces users to apply the same context policy to very different tasks:

• A small task does not necessarily need a large active context.
• A long debugging, research, or implementation task may repeatedly trigger compaction while still retaining a large amount of necessary context.
• A globally configured threshold cannot adapt to the actual context retained by each thread.
• Changing global configuration can also make resumed threads behave differently from when they were created.

The missing signal is the amount of active context that remains after compaction. This result can help Codex determine whether the current context budget is sufficient and whether it should expand.

Proposed behavior

Each thread maintains a versioned, ordered set of soft context-budget tiers.

For example:

272K → 487K → 872K

For a current budget B, automatic compaction triggers near floor(0.90 × B). After a successful Auto + ContextLimit compaction, Codex recomputes the remaining context usage U_after and adjusts the tier based on U_after / B:

• Below 45%: keep the current tier.
• From 45% to below 65%: expand after two consecutive results.
• At or above 65%: expand immediately.

The policy values should be configurable. Expansion only moves upward and must remain within the model's usable context window and catalog limits.

Persistence and thread behavior

The policy and current tier should be persisted per thread in session/compaction metadata.

Resume, fork, and rollback should preserve this state, while global configuration changes should not silently alter existing threads. Incompatible model switches should be rejected, and the current soft budget should be exposed separately from the model's hard context window in token-usage events and the UI.

Expected outcome

Short tasks could remain on a conservative context tier, while genuinely context-heavy threads could gain more room based on observed post-compaction pressure.

This would make automatic compaction policy responsive to the individual thread instead of relying only on a fixed global threshold.

Additional information

I implemented an experimental reference version in my public fork:

• Reference implementation: https://github.com/rhan637/codex/tree/codex/local-dev
• Core commit: https://github.com/rhan637/codex/commit/045a3465c49cb2df2d18a9c3aff8ee4cecb24b5c
• Documentation:
  • https://github.com/rhan637/codex/blob/codex/local-dev/ADAPTIVE_CONTEXT_BUDGET_USAGE.md
  • https://github.com/rhan637/codex/blob/codex/local-dev/ADAPTIVE_CONTEXT_BUDGET_DEVELOPMENT.md

The prototype is disabled by default. It provides model-aware adaptive context tiers, compaction feedback, per-thread checkpoint persistence, rollback-aware resume and fork handling, model-switch compatibility checks, and protocol/app-server/TUI token-budget reporting, with automated test coverage.

The implementation was originally based on upstream commit:

https://github.com/openai/codex/commit/6be2a6ca95

I am sharing the fork as a concrete reference for design discussion, not as an external pull request.

Finally, As a user, I find it frustrating that long-running tasks are always limited by a 272K default context window. Requiring users to manually predict task complexity and configure larger limits goes against the spirit of agent automation.

Read ADAPTIVE_CONTEXT_BUDGET_USAGE.md and ADAPTIVE_CONTEXT_BUDGET_DEVELOPMENT.md in the linked reference branch, then compare its core commit with upstream. Trace the compaction and session metadata behavior alongside protocol, app-server, TUI, and token-budget reporting. Done means the adaptive policy, persistence rules, compatibility checks, and reporting behavior are agreed and covered by tests.