Client-side Codex compaction does not match configured compactionRouting override #8089

Client or integration

Codex CLI

Area

Proxy and routing

Summary

With codexClientCompaction: true, Codex can send a local Responses compaction request with request_kind: compaction and compaction.trigger: auto in the turn metadata, but without an input item of type compaction_trigger. OpenCodex 2.96.0 requires that input item when applying compactionRouting on /v1/responses, so the configured compaction target is silently bypassed and the source model handles the summary.

Expected: honor an explicitly configured compaction target for this verified local checkpoint request. Ordinary generation requests must remain on the source model. The local checkpoint expects a normal text summary; it must not be converted to a remote compaction_trigger request with a different output contract.

Reproduction

1. Enable codexClientCompaction and configure compactionRouting for the source model with an explicit target and both auto and manual triggers.
2. Start a Codex CLI session through OpenCodex with the source model and a temporary model_auto_compact_token_limit below the size of a synthetic input.
3. Submit the input and ask Codex to perform a harmless read-only tool call, then answer.
4. Inspect the automatic compaction request and OpenCodex request records.

Observed: both the x-codex-turn-metadata header and client_metadata report request_kind: compaction, with compaction.trigger: auto, implementation: responses, phase: mid_turn, and strategy: memento. The input ends in a local checkpoint summary prompt without compaction_trigger. The proxy records the compaction against the source model, not the configured target.

In an isolated port 10101 candidate, a narrow local fix recognized that checkpoint prompt together with consistent compaction metadata and implementation: responses. A synthetic approximately 398k-token session executed a read-only tool call, then routed the summary request to openai/gpt-6.1-terra (264,388 input tokens) and continued on the original third-party model (61,139 input tokens). The continuation retained the test tool result and two markers. Negative checks passed for ordinary turns, missing metadata, incorrect implementation and an unrelated prompt; the existing remote-trigger case remained accepted. This is one controlled end-to-end test, not a general reliability claim. Related: #5012 concerns configuring a target; this issue concerns a local client request failing to match the existing policy.

Version

OpenCodex 2.96.0; Codex CLI 0.166.0-alpha.5.1.

Operating system

macOS.

Provider and model

Source: IkunCode Gemini 4 Argon via OpenAI Chat adapter. Configured compactor: OpenAI GPT-6.1 Terra.

Logs or error output

The summary request completed successfully, but the usage records showed the source provider/model as its route rather than the configured compactor. The detailed request shape and the isolated candidate results are described above.

Redacted configuration

{
  "codexClientCompaction": true,
  "compactionRouting": {
    "model": "gpt-6.1-terra",
    "sourceModels": ["ikuncode-gemini-chat/*"],
    "reasoningEffort": "high",
    "triggers": ["manual", "auto"]
  }
}

Checks

• I searched existing issues and documentation.
• I removed secrets, tokens, account details, request credentials, and personal data.