Files
magpie/docs
yetone 9275abcddb gateway: Codex's compaction on a CC Switch relay table that magpie points at /v1 completes, with a summary magpie makes, instead of failing "remote compaction v2 expected exactly one compaction output item, got 0 from 1 output items" (#1301, ylacmilan)
Codex compacts remotely (compaction v2: a compaction_trigger item on
/responses, and exactly one compaction item back) for any provider table
named "OpenAI" (codex-rs ProviderCapabilities::from_config, is_openai), and
CC Switch names its relay tables so. While a magpie model is on, magpie
points those tables at /v1 (takeTables). /v1/responses relayed the trigger
as it came; the relay answered with a message, and Codex counted 0
compaction items out of 1. Only CodexPath turned the trigger into a summary
request (codexInput, codexCompact).

handle now does the same for a Responses request on /v1 that carries a
compaction_trigger: the model summarises, and the summary goes back as
magpie's compaction item. A later turn's magpie1: compaction item reaches
the model as the summary's text, not as an item the relay can't open.

TestCodexCompactionTriggerOnV1 fails without the change (one
output_item.done of type "message", the relay's reply, where Codex needs one
"compaction") and passes with it.

Real use: codex-cli 0.160.1 in a sandbox CODEX_HOME with
[model_providers.custom] name = "OpenAI", base_url = magpie's /v1 (built
from this tree, `magpie serve` in a sandbox HOME on 127.0.0.1:3592), model
token/gpt-6.1-sol on a fake Responses relay that reports 90K tokens and
model_auto_compact_token_limit = 1000. Old build: `codex exec resume`
printed the reporter's exact error, and the relay got the
compaction_trigger. New build: "context compacted", the relay got Codex's
compaction prompt, and the next two turns went on with the summary as a
message. go test ./internal/gateway, go vet (darwin, GOOS=linux,
GOOS=windows) pass. Not tried: the reporter's own relay and CC Switch
version.
2026-10-08 19:16:29 +08:00
..