Make context compaction use a configurable model independent of the active session model

[zergzorg]

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:

• Control over auto-compaction parameters #4106 — control over auto-compaction parameters
• Separate model selection for Plan vs Execute modes (e.g., GPT-5-high for planning + GPT-5-Codex execute) #5558 — separate model selection for Plan vs Execute modes
• Allow configuring subagent model and reasoning_effort in config #11795 — configure subagent model and reasoning_effort
• Make context window and auto-compaction settings model-aware #16140 — model-aware context window and auto-compaction settings
• Support asynchronous/background compaction in Codex CLI #18007 — asynchronous/background compaction
• CLI remote compaction repeatedly fails and leaves resumed threads without task continuity #22335 — remote compaction failures and session continuity problems
• Compaction silently discards all tool outputs and assistant reasoning #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.

[emersonbusson]

Strong feature request — the cost asymmetry between "primary reasoning model" and "summary-only compaction model" is real, and it gets worse on long sessions that compact several times.

A quick map of where this would land in the current code, in case it helps scope:

• Compaction model is resolved from turn_context.model_info (e.g. codex-rs/core/src/compact_remote.rs::run_remote_compact_task_inner_impl at the compact_conversation_history(..., &turn_context.model_info, ...) callsite, and similarly in codex-rs/core/src/compact.rs::run_compact_task_inner_impl). Today turn_context is built once per turn from the session model, so there's no seam for a per-compaction model override.
• ConfigToml in codex-rs/config/src/config_toml.rs already carries a compact_prompt: Option<String> field for prompt overrides — adding a sibling compact_model: Option<String> (plus compact_reasoning_effort) is the obvious shape for the flat TOML you proposed, and mirrors the existing override pattern.
• Inside the compaction entrypoints, turn_context could be cloned with .with_model(compact_model, &sess.services.models_manager) (which already exists for the model-downshift path at codex-rs/core/src/session/turn.rs::maybe_run_previous_model_inline_compact). That gives a turn-scoped TurnContext with the alternate model without touching the main session model.

A few open design questions the team would probably want to settle before scoping:

1. Fallback behavior — your fallback = "session_model" suggestion is nice but the current model resolver doesn't have a "model not available, fall back" path; it errors. So the fallback would need to be implemented at config-resolution time (validate compact model availability on startup) or at runtime in the compaction wrapper.
2. Remote vs inline split — compact_conversation_history (remote) sends the model slug to the compact endpoint; the endpoint may not accept arbitrary models. The inline path is more permissive. So model selection might need to also pick the implementation path (remote when supported, inline otherwise).
3. Reasoning effort split — already routed through CompactConversationRequestSettings { effort, summary, ... } for remote and through Prompt.personality for inline. Both are derived from turn_context so the with_model clone above carries them naturally if config provides them.

Not opening a PR for this — just leaving the code map in case it's useful as the team prioritizes.

[zergzorg]

Thanks, this code map is very helpful. The remote vs inline split and fallback behavior are good points; even an opt-in inline-only implementation would already be useful if remote compaction cannot support arbitrary models yet.

[emersonbusson]

Agreed — inline-only opt-in is probably the lowest-risk first cut. The seam is already there in practice: run_inline_auto_compact_task → run_compact_task_inner → run_compact_task_inner_impl all thread a TurnContext that could be cloned via the existing with_model(...) helper (used today for the model-downshift path). So a single compact_model: Option<String> in ConfigToml, resolved at compact-time and swapped in before that callsite, would cover the bulk of the requested behavior without touching the remote path or the model resolver itself.

[hoteye]

One angle from building a multi-provider coding-agent runtime: compaction feels more like a role-specific route than just another call to the active session model. Main planning, tool follow-up, final synthesis, background tasks, and context maintenance often have different cost/latency/reliability needs.

For Codex, an opt-in compact_model with unchanged defaults, visible fallback to the session model, and /status/debug visibility would cover the core need without turning this into a broad routing system. I’m exploring this kind of per-role routing in AgentHub as well: https://github.com/hoteye/AgentHub