Compaction related issues/observations when using agentic-api with Codex-CLI

[noobHappylife]

Problem statement / motivation

While validating codex CLI (v0.146.0) against agentic-api as a Responses provider, I traced and live-tested the full compaction interaction.

I found 2 issues, and 2 observations related to this.

1) With the recommended setup, compaction silently falls back to client-side (local) compaction

What happens

Codex's compaction dispatch (codex-rs/core/src/tasks/compact.rs) is:

  supports_remote_compaction() == is_openai() || azure_url_markers
  ├─ true  → remote (V2 by default in v0.146.0, see Issue 2)
  └─ false → LOCAL compact: in-process summarization turn on /v1/responses

supports_remote_compaction() (model-provider-info/src/lib.rs:417) is config-only — provider name == "OpenAI" (case-sensitive) or Azure URL markers (codex-api/provider.rs:106). The documented agentic-api setup uses name = "agentic-api" → false → local compact:

2) V2 remote compaction doesn't work; only V1 works

What happens

In codex v0.146.0, RemoteCompactionV2 is Stage::Stable, default_enabled: true (codex-rs/features/src/lib.rs:1434). With name = "OpenAI", codex uses V2: it appends a compaction_trigger item to /v1/responses input and requires the response stream to contain exactly one compaction item.

agentic-api has no compaction_trigger input variant (deserializes to Unknown), runs a normal inference turn, the model emits no compaction item, and codex fatals:

Error running remote compact task: Fatal error: remote compaction v2 expected exactly one compaction output item, got 0 from 2 output items

(collect_compaction_output, codex-rs/core/src/compact_remote_v2.rs:421)

Workaround (V1 works)

[features]
remote_compaction_v2 = false

forces the V1 path (POST /v1/responses/compact), which agentic-api implemented.

Proposed solution

1. Perhaps, if we want to let the user to use remote compaction, then need to update the setup to name="OpenAI" (case sensitive). And to turn off v2 compaction now.

2. For the v2 compaction, it seems that it's only a native concept in codex cli, and it's not found in OpenAI documentations (https://developers.openai.com/api/docs/guides/compaction, https://developers.openai.com/api/docs/guides/websocket-mode#compaction-and-creating-new-responses).

Alternatives considered

No response

Additional context

Here are the 2 observations I observed, when using with Codex CLI.

1. — Assistant messages are dropped; many consecutive user messages remain

• For client side/local compaction. After a compaction triggered, Codex-CLI will send the request with following shapes (assistant messages before the compaction will all be dropped, leaving user messages)
• Example:

  [
    {"type":"message","role":"user","content":[{"type":"input_text","text":"..."}]},
    {"type":"message","role":"user","content":[{"type":"input_text","text":"..."}]},
    {"type":"message","role":"user","content":[{"type":"input_text","text":"[The compacted summary/checkpoint messages]"}]},
    {"type":"message","role":"developer","content":[{"type":"input_text","text":"[re-injected current instructions, personality, skills, world state]"}]},
    {"type":"message","role":"user","content":[{"type":"input_text","text":"..."}]}
  ]

2. Using v1 compaction, compaction summary becomes the first message as an assistant message

• For v1 compaction, after triggered, Codex-CLI will send the request with following shapes (the compaction summary becomes an assistant message and is slot to the beginning)

  [
    {"type":"message","role":"assistant","content":[{"type":"output_text","text":"**CONTEXT CHECKPOINT - 2026-08-04** …"}]},
    {"type":"message","role":"developer","content":"…"},
    {"type":"message","role":"user","content":"new message"}
  ]