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

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.

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.

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.

I ran into the same class of problem from a latency/reliability angle: I want normal turns to keep their usual quality profile, but compaction to use a faster/lower-reasoning path.

I prepared a narrower implementation that does not yet add a separate compaction model, but does add compaction-specific reasoning_effort and service_tier:

model_reasoning_effort = "high"
service_tier = "default"

compact_model_reasoning_effort = "low"
compact_service_tier = "fast"

Branch:
https://github.com/Cccceb/codex/tree/compact-specific-reasoning-service-tier

Commit:
https://github.com/Cccceb/codex/commit/64b6b1e00ad40558c9e4d78c4a6d17b4d01f3b7a

Summary:

• add optional compact_service_tier and compact_model_reasoning_effort config fields
• use those compact-specific settings for local compact, legacy remote compact, and remote compaction v2
• keep existing behavior unchanged when the compact-specific fields are unset
• normalize compact_service_tier = "fast" through the same fast-mode service-tier normalization path as regular service_tier

Testing:

• cargo fmt --check
• env CARGO_HOME=/private/tmp/codex-cargo-home cargo test -p codex-core config_toml_compact_
• env CARGO_HOME=/private/tmp/codex-cargo-home cargo test -p codex-core remote_manual_compact_uses_compact_specific_service_tier_and_reasoning_effort

I tried opening this as a PR, but PR creation is restricted to collaborators on this repo. Happy to adjust the branch if maintainers think this narrower config surface is a useful first step toward the broader compaction-model proposal.

Concrete economic evidence: compaction should not automatically inherit the premium session route

I have now encountered this as part of a wider investigation into Codex request-pipeline economics.

One analysed GPT-5.6 Sol / High / Standard session contained:

• 121 Sol model invocations;
• 15.64M input tokens;
• 87.6k output tokens;
• one compaction; and
• an estimated 333.6 credits at the published Sol rate.

The session was doing load-bearing architecture/specification work, so selecting Sol was deliberate.

What was not deliberate was making that choice implicitly apply to mechanically different pipeline phases such as context compaction.

Cost asymmetry is now substantial

At the current Codex rate card:

                 uncached input   cached input   output
Sol                    125            12.5        750
Terra                   50             5          300
Luna                     5             0.5         30

Therefore, for the same token mix:

Terra ≈ 40% of Sol cost
Luna  ≈  4% of Sol cost

This means a Luna compaction request can theoretically cost about 96% less than the same request routed through Sol, before considering a lower reasoning effort.

Obviously summary fidelity matters. I am not suggesting blindly replacing all compaction with the cheapest model.

I suggest treating compaction as a small governed pipeline:

conversation history
        ↓
deterministic extraction
    - requirements
    - unresolved decisions
    - prohibitions
    - paths / hashes / IDs
    - completed work
    - outstanding work
        ↓
Luna / low reasoning
semantic synthesis
        ↓
deterministic completeness checks
        ↓
PASS ───────────────► install compacted history

FAIL
  ↓
Terra / stronger synthesis
  ↓
FAIL
  ↓
active session model

The premium model becomes a fallback for difficult compression rather than the default merely because it was selected for the surrounding coding task.

Suggested configuration

[compaction]
model = "gpt-5.6-luna"
reasoning_effort = "low"
service_tier = "default"
fallback_model = "session"

I would explicitly not default compaction to Fast mode. Compaction is normally throughput-insensitive and input-heavy, while Fast mode increases GPT-5.6 credit consumption.

Telemetry

Whichever implementation is chosen, I strongly suggest exposing:

compaction_model
compaction_reasoning_effort
compaction_service_tier
context_tokens_before
uncached_input_tokens
cached_input_tokens
output_tokens
reasoning_tokens
summary_tokens
compression_ratio
validation_result
fallback_used

That matters because users currently see the cost of compaction only indirectly as part of overall session consumption.

Broader architectural lesson

The issue is not simply “let users choose a cheaper summariser”.

Codex currently tends to associate a model with a session or turn. Economically, model selection needs to occur at the work-phase boundary.

The user should be able to reserve Sol for the part of the workflow where Sol-level reasoning creates value without necessarily purchasing Sol-level reasoning for evidence preparation, waiting, deterministic validation and context maintenance.

The existing opt-in proposal in this issue would be an excellent first step and can remain fully backwards compatible.