[Feature]: allow an explicit routed compaction provider when canonical OpenAI quota is exhausted #5012

Area

Proxy and routing

What are you trying to accomplish?

Continue a long Codex Desktop thread through an explicitly selected routed provider even when the native ChatGPT/Codex quota is exhausted.

The concrete workflow is:

• the existing thread is opened/forked and the execution model is changed to an independently credentialed provider, e.g. agent-space/gpt-5.6-sol;
• fresh threads through that provider work;
• the long existing thread needs a pre-sampling compaction before the next turn;
• I want that compaction to be handled by an explicitly selected routed provider, rather than being blocked by an unrelated exhausted canonical OpenAI quota.

This is not a request to bypass or modify OpenAI quota enforcement. The routed provider has its own credentials, billing/quota, and data-sharing boundary.

What prevents this today?

The current compaction routing keeps the canonical OpenAI reservation whenever an enabled openai provider exists.

In my reproduced case, the thread itself was recorded as routed through OpenCodex with model agent-space/gpt-5.6-sol, but resuming it caused Codex to enter PreCompact. The request then failed after five reconnect attempts with a 429.

The proxy log identified the failing request as:

provider: openai
model: gpt-5.6-luna
requestedModel: gpt-5.6-luna
errorCode: rate_limit_exceeded
upstreamError: The usage limit has been reached.

At the same time, fresh requests through agent-space succeeded.

This matches the current router behavior: routeCompactionModel() only falls back to defaultProvider for a bare OpenAI-family compaction model when canonical openai is absent or disabled. If openai is enabled but quota-exhausted, the compact request remains bound to it.

#2901 fixed the no-canonical-OpenAI case and explicitly invited a follow-up if an explicit compaction-provider override was still needed. This is that concrete case.

What should OpenCodex do?

Please provide an explicit, opt-in way for compaction to use a routed provider/model even when canonical openai is configured.

Observable requirements:

1. A user can select a qualified provider/model for compaction independently of ordinary canonical OpenAI availability.
2. The selection applies to both POST /v1/responses/compact and compaction_trigger paths.
3. If a routed long-running thread requires compaction while native OpenAI quota is exhausted, compaction can complete through the explicitly selected provider instead of failing before the routed turn begins.
4. Existing behavior remains unchanged when no override is configured.
5. Account-qualified routes and provider credentials remain isolated; no native ChatGPT bearer or account state is forwarded to the external provider.
6. The UI/CLI should make the privacy and billing consequence explicit because compaction may send a large portion of conversation history to the selected provider.

An implementation could reuse the qualified model selector mechanism discussed in #2901, but the exact config/API shape is up to the project.

Example usage or interface

One possible interface, using the selector shape previously discussed in #2901:

{
  "responsesCompactionModel": "agent-space/gpt-5.6-luna"
}

Equivalent CLI/UI behavior could be:

Compaction route: agent-space/gpt-5.6-luna
Ordinary thread route: agent-space/gpt-5.6-sol
Canonical OpenAI provider: still configured, but not required for this compact turn

Expected result:

long routed thread -> PreCompact
                   -> explicit compaction provider
                   -> compact succeeds
                   -> next routed turn continues

Without the setting, current routing should remain unchanged.

Alternatives or workarounds

• Wait for native OpenAI quota to reset, let the pre-sampling compact finish there, and then continue the routed thread. This preserves current behavior but keeps long external-provider threads dependent on native quota.
• Start a fresh routed thread and manually carry forward a summary. This works but loses the existing thread continuity.
• Temporarily make the routed provider the OpenCodex default and disable canonical openai, which activates the No way to set compaction provider. #2901 default-provider compaction fallback. This is a global configuration workaround with unnecessary blast radius and requires careful restoration afterward.
• Automatically fall back on every 429. That may have privacy/billing implications, so an explicit selector/opt-in is preferable.

Additional context

Related issues:

• No way to set compaction provider. #2901 — bare native compaction model falls back to defaultProvider only when canonical openai is absent/disabled. The closing comment asks for a follow-up if a separate explicit compaction provider is still needed.
• [Feature]: opt into Codex client compaction without disabling V2 routing #3978 — client-side compaction compatibility mode; related compaction ownership problem, but not a substitute for choosing the routed summarizer provider in this case.
• [Feature] Explicit per-thread external-provider routing during Codex Desktop Luna Reserve #4869 — broader per-thread external-provider routing during native quota exhaustion. This report is narrower: the routed model is already selected and working; only the pre-sampling compact remains pinned to canonical OpenAI.

Observed client: Codex Desktop / CLI 0.153.4 on macOS. Secrets, request credentials, and account identifiers are intentionally omitted.

Checks

• I searched existing issues and documentation.
• This request describes a concrete OpenCodex workflow rather than merely naming a desired technology.
• I removed secrets and personal data.