codex - 💡(How to fix) Fix Codex CLI 在 OpenAI 兼容中转未实现 /responses/compact 时缺少降级策略，导致任务直接失败 [3 comments, 3 participants]

背景

目前不少 OpenAI 兼容中转站 / relay / gateway，只实现了基础的 Responses API，例如：

• POST /v1/responses

但并没有实现完整的长会话压缩接口，例如：

• POST /v1/responses/compact

这类中转站通常已经足以支持大部分普通推理请求，但在 Codex CLI 的长会话场景里，一旦触发 compaction，CLI 会尝试调用远端 /responses/compact，此时就可能直接失败。

问题现象

在使用 OpenAI 兼容中转时，Codex CLI 报错如下：

Error running remote compact task: unexpected status 502 Bad Gateway: error code: 502, url: https://sub2api.qiyue.dev/responses/compact, cf-ray: 9f99eeb17b451e3b-SIN

从实际表现看，Codex CLI 在将 provider 识别为 OpenAI / Azure 风格后，会直接依赖远端 /responses/compact，但当中转站没有实现这个接口时：

• 没有明显的能力探测
• 没有自动回退到本地 compaction
• 没有可配置的显式开关来禁用 remote compaction

最终结果是：一次本可继续的上下文压缩动作，直接变成整个任务失败。

复现条件

比较容易复现的条件如下：

1. 配置一个 OpenAI 兼容 provider
2. 该 provider 支持 POST /v1/responses
3. 该 provider 不支持 POST /v1/responses/compact
4. 在 Codex CLI 中进行足够长的对话，触发 compact

此时就会出现 remote compact task 失败。

实际影响

这个问题在真实环境中的影响比较大：

• 很多“OpenAI 兼容”中转只做了基础 Responses 转发，没有补齐 compact 接口
• 用户通常只能在长会话运行到一半时才发现不兼容
• 失败方式是“任务中断”，而不是“能力降级”
• 这使得 Codex CLI 对第三方兼容 provider 的容错性偏弱

换句话说，当前行为隐含了一个较强假设：

只要是 OpenAI-compatible provider，就应该完整支持 /responses/compact

但现实里这个假设并不成立。

期望行为

希望 Codex CLI 至少具备以下任一能力：

1. 在使用 remote compaction 前，先探测 provider 是否支持 /responses/compact
2. 当 /responses/compact 不可用时，自动回退到本地 compaction
3. 提供显式配置项，允许用户关闭 remote compaction
4. 支持 provider 级能力声明，例如标记“不支持 remote compaction”

建议方案

方案一：失败后自动回退本地 compaction

这是最直接、对用户最友好的方式。

建议行为：

• Codex 优先尝试远端 /responses/compact
• 若返回 404、400、405、501、502 等明显不支持的结果
• 自动切换到本地 compaction
• 仅记录 warning，不中断主任务

优点：

• 对现有用户最透明
• 不要求所有中转站补齐接口
• 能显著提升 CLI 在兼容 provider 场景下的韧性

方案二：增加 provider 能力开关

例如允许在配置中声明：

[model_providers.myrelay]
name = "myrelay"
wire_api = "responses"
base_url = "https://example.com/v1"
env_key = "MYRELAY_API_KEY"
requires_openai_auth = false
supports_remote_compaction = false

当 supports_remote_compaction = false 时，Codex 直接使用本地 compaction，不再请求 /responses/compact。

优点：

• 行为明确
• 易于调试
• 适合第三方 provider 与 relay 场景

方案三：启动时或首次请求时做能力探测

例如在 provider 初始化或首次 compact 前，检测：

• 是否支持 /v1/responses/compact
• 是否返回可识别的“unsupported endpoint”响应

然后把结果缓存到当前会话。

优点：

• 自动化程度更高
• 不要求用户手工理解所有 provider 差异

缺点：

• 实现比配置开关更复杂
• 仍建议配合 fallback 一起使用

建议优先级

如果只能先做一个改动，建议优先实现：

“远端 compaction 失败时自动回退本地 compaction，而不是直接让任务失败”

这是收益最大、对兼容性改善最明显的一步。

补充说明

这个问题不一定是某个具体中转站的 bug。核心矛盾在于：

• Codex CLI 当前对 OpenAI-compatible provider 的能力假设偏强
• 现实中的兼容 provider 往往只实现了部分 Responses API
• 缺少 fallback 机制后，局部能力缺失会放大成整体任务失败

因此这里更像是一个 Codex CLI 的兼容性和降级策略问题。

希望确认的问题

也希望官方能明确以下几点：

1. POST /v1/responses/compact 是否已经被视为 Codex CLI 的强依赖
2. 是否存在当前未公开的配置方式，可以禁用 remote compaction
3. 后续是否计划为 OpenAI-compatible provider 增加能力声明或 fallback 机制