codex - 💡(How to fix) Fix Make context compaction use a configurable model independent of the active session model [3 comments, 2 participants]

What variant of Codex are you using?

CLI

What feature would you like to see?

Please allow Codex CLI to configure the model used for context compaction independently from the active session model.

Context compaction is a different job from normal interactive coding or planning. The active session model is optimized for reasoning, tool use, code edits, and following the current task. Compaction is a background/system summarization task whose main requirement is to preserve task state faithfully and predictably across long sessions.

Because those jobs have different cost, latency, and quality tradeoffs, users should be able to choose a separate compaction model and reasoning effort.

For example:

model = "gpt-5.5"
model_reasoning_effort = "high"

[compaction]
model = "gpt-5.4-mini"
reasoning_effort = "low"
fallback = "session_model"

A minimal flat config would also work:

model = "gpt-5.5"
compaction_model = "gpt-5.4-mini"
compaction_reasoning_effort = "low"

Problem this solves

Long-running Codex sessions often compact multiple times. Each compaction affects all future turns, so the compaction path is part of the core reliability story for the CLI, not just an implementation detail.

Today, users who want a high-capability model for real work appear to also pay that same model/cost/latency profile for compaction. That is not always the best tradeoff:

• A strong main model may be unnecessarily expensive for summarization-only compaction.
• A slower or higher-reasoning main model can make compaction feel more disruptive.
• A model that is excellent for coding/tool use may not be the model a user trusts most for conservative state compression.
• Repeated compactions can amplify summary quality issues, so users need a way to tune this path separately.
• When compaction fails or degrades, session continuity suffers even if the main model is otherwise working well.

Expected behavior

If a compaction model is configured:

1. Manual /compact uses the configured compaction model.
2. Automatic compaction uses the configured compaction model.
3. If compaction.reasoning_effort is configured, it is applied only to compaction requests.
4. If the configured compaction model is unavailable, Codex falls back to the active session model and shows/logs a clear warning.
5. /status, debug logs, or trace output show which model and reasoning effort handled the most recent compaction.
6. If no compaction-specific config is set, Codex keeps the current behavior.

Why this matters

This gives users practical control over the main long-session tradeoffs:

• cost: use an expensive model for coding, a cheaper model for compaction
• latency: use a faster model for background summarization
• reliability: choose a model that behaves well for conservative state summaries
• debuggability: make compaction model selection visible instead of implicit
• workflow fit: match model selection to task phase, rather than forcing one model to do everything

This also aligns with adjacent requests for per-phase/per-role model selection in Codex.

Related issues and signal

This is a more explicit version of #13739, which was closed because it did not receive enough upvotes. I understand maintainers need a triage signal, but this particular feature can be under-voted even when it is valuable: many users only notice the need after they have spent hours in a long session and hit compaction cost, latency, failure, or quality problems.

Related context and model-selection issues:

• #4106 — control over auto-compaction parameters
• #5558 — separate model selection for Plan vs Execute modes
• #11795 — configure subagent model and reasoning_effort
• #16140 — model-aware context window and auto-compaction settings
• #18007 — asynchronous/background compaction
• #22335 — remote compaction failures and session continuity problems
• #14589 — compaction information loss across long coding sessions

These are not all the same request, but together they show that context compaction and per-phase model control are recurring workflow pain points.

Possible acceptance criteria

• Add documented config for compaction model selection.
• Add documented config for compaction reasoning effort, if supported by the selected model.
• Keep backwards-compatible default behavior when no compaction config is present.
• Add tests that verify compaction requests use the configured model instead of the active session model.
• Add fallback behavior and tests for unavailable compaction models.
• Surface the effective compaction model in /status or logs.

Additional information

This can be treated as an advanced/opt-in setting if maintainers are concerned about exposing too many knobs. Even an experimental config flag would be useful for users who run long-lived Codex sessions and need to tune compaction separately from the main model.