Feature request: allow a separate model for context compaction

Resolved 💬 4 comments Opened Mar 6, 2026 by alexx-ftw Closed Apr 18, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

CLI

What feature would you like to see?

Add a dedicated configuration option to let Codex use a different model for context compaction than the main conversation model.

Today compaction appears to use the same model path / session model that is handling the main thread. That makes compaction expensive and, depending on the selected model, can also reduce reliability or throughput for long-running sessions.

A separate compaction model would make it possible to keep a strong main model for normal work while using a smaller / cheaper / faster model for summarization-only compaction work.

Examples:

main thread: gpt-5-codex
compaction: gpt-5-codex-mini

main thread: high-capability planning / execution model
compaction: lightweight summarization model

Potential config shapes:

model = "gpt-5-codex"
compaction_model = "gpt-5-codex-mini"

[compaction]
model = "gpt-5-codex-mini"

Nice-to-have related controls:

optional reasoning_effort override for compaction
explicit fallback to main model if the compaction model is unavailable
visibility in /status or logs showing which model handled the most recent compaction

Why this would help:

reduces cost for long-lived sessions
can make compaction faster
lets users tune quality vs cost separately for summarization work
matches other requests for per-role / per-phase model selection in Codex

Additional information

I searched for an existing issue specifically about using a separate model for compaction and did not find one. The closest related issues I found were:

#4106 (Control over auto-compaction parameters)
#5558 (Separate model selection for Plan vs Execute modes)
#11795 (Allow configuring subagent model and reasoning_effort in config)

Those are adjacent, but this request is narrower and specifically about the compaction path.

View original on GitHub ↗

4 Comments

Xynonners · 5 months ago

This seems like a good idea too to allow using gpt-5.3-codex for compactions and gpt-5.4 for real work, considering that gpt-5.4 compacting too many times leads to it getting confused and a death spiral where it starts to repeat previous messages instead of responding to the current one.

Playitcooool · 4 months ago

What I wanna do is gpt 5.3 codex medium for execution and gpt5.4 xhigh for planning.Because gpt 5.3 codex is good at terminal programming and costs less tokens and 5.4 is a universal model for better planning.But there is no such a feature can switch between models and reasoning effort smoothly.

etraut-openai contributor · 4 months ago

This feature request hasn't received enough upvotes, so I'm going to close it.

olegKusov · 3 months ago

This feature request hasn't received enough upvotes, so I'm going to close it.

I understand that maintainers need some way to triage feature requests, but closing this one primarily because it did not receive enough upvotes feels like a very weak product signal.

This is not a cosmetic preference. Context compaction is a core part of long-running Codex CLI sessions. Being able to configure a separate model for /compact would give users better control over cost, latency, reliability, and quality.

GitHub reactions are not a reliable measure of usefulness. Many users who would benefit from this feature may never see the issue, may not react, or may not even understand yet why compaction model selection matters until they hit the problem in real work.

In 2026, for a developer tool from OpenAI, I would expect feature prioritization to be based on product impact, technical value, and real workflow pain — not mostly on how many likes an issue got.

Please reconsider this request. It is well-scoped, practical, and directly related to the quality of long-running Codex sessions.