Remote compaction fails when using `gpt-5.5` because `/responses/compact` does not appear to support the model

Summary

When Codex is configured to use gpt-5.5, remote conversation compaction fails because Codex sends the same active model slug to the /responses/compact endpoint. The normal Responses API request works with gpt-5.5, but the compact endpoint appears not to support this model yet.

This causes long-running Codex sessions to fail during auto-compaction or manual /compact.

Error

Example error:

Error running remote compact task: unexpected status 502 Bad Gateway: error code: 502, url: /responses/compact

The failure appears to be caused by the compact endpoint rejecting or not supporting gpt-5.5.

Expected behavior

Codex should not fail compaction when the active inference model is supported by normal /responses but not by /responses/compact.

Possible expected behaviors:

1. Codex should know which models support remote compaction and fall back to local compaction when unsupported.
2. Codex should allow configuring whether remote compaction is used.
3. Codex should allow configuring a separate model for remote compaction.
4. The upstream /responses/compact endpoint should support gpt-5.5 if Codex is expected to use it with that model.

Actual behavior

Codex decides whether to use remote compaction based on the provider, not on the model.

For OpenAI/Azure-like providers, Codex uses the remote compact endpoint:

pub(crate) fn should_use_remote_compact_task(provider: &ModelProviderInfo) -> bool {
    provider.supports_remote_compaction()
}

Then the compact request body uses the current turn model directly:

let payload = ApiCompactionInput {
    model: &model_info.slug,
    input: &input,
    instructions: &instructions,
    tools,
    parallel_tool_calls: prompt.parallel_tool_calls,
    reasoning,
    text,
};

So when the session model is gpt-5.5, Codex sends:

{
  "model": "gpt-5.5",
  "...": "..."
}

to:

/v1/responses/compact

There does not seem to be a separate compact model, model capability check, or fallback path if the compact endpoint does not support the active model.

Relevant code

Remote vs local compaction selection:

codex-rs/core/src/tasks/compact.rs
codex-rs/core/src/session/turn.rs

Provider-based remote compaction check:

codex-rs/core/src/compact.rs
codex-rs/model-provider-info/src/lib.rs

Compact request payload:

codex-rs/core/src/client.rs
codex-rs/codex-api/src/endpoint/compact.rs
codex-rs/codex-api/src/common.rs

Specifically, compact_conversation_history uses model_info.slug as the compact request model.

Why this is a problem

This makes remote compaction brittle for newly released or experimental models. A model can be usable for normal Codex turns but still break long-running sessions once compaction is triggered.

This is especially problematic because auto-compaction can happen during normal usage, so the user may not explicitly request /compact but still hit the failure.

Workaround

A current workaround is to make the provider not be detected as OpenAI/Azure, which causes Codex to use local compaction instead of /responses/compact.

However, this is not ideal because the choice of remote vs local compaction is indirectly controlled by provider identity rather than an explicit configuration option.

Proposed fixes

Any of the following would help:

1. Add a config option such as:

use_remote_compaction = false

or:

remote_compaction = "auto" # auto | always | never

1. Add a dedicated compact model config:

compact_model = "gpt-5.4"

1. Make remote compaction model-aware and only use /responses/compact for models known to support it.

1. If /responses/compact returns a model unsupported error, fall back to local compaction automatically.

Environment

• Codex with Responses API provider
• Active model: gpt-5.5
• Remote compact endpoint: /v1/responses/compact
• Normal Responses requests with gpt-5.5 work
• Remote compact requests with gpt-5.5 fail

Additional context

This may either be an upstream OpenAI API rollout gap or an intentional limitation of the compact endpoint. Either way, Codex currently assumes that if the provider supports remote compaction, the active model also supports remote compaction, which is not always true.

---