← 返回公开文章

AxonHub 连接 Codex 时的上下文失败：1M 误判、压缩时机与 Responses 兼容性

/research/axonhub-codex-context-window-failures.md

这次讨论的问题是：通过 AxonHub 连接 Codex，经常遇到“上下文满了”“请求失败”“stream disconnected”一类错误。有人解释说：因为中转走的是 API，Codex 以为自己有 1M context，但实际上 Codex 产品链路没有 1M，所以自动压缩来不及触发，最后请求失败。这个说法总体靠谱，但它不是完整解释。

更准确的判断是：如果 AxonHub 或客户端配置把 GPT-5.5 暴露成 400K / 1M 上下文，而 Codex 这条产品链路的有效窗口仍然只有约 258K / 272K，那么 Codex 的自动压缩阈值就会被设得过高。客户端以为还没到该压缩的时候，上游却已经到真实窗口边界，于是出现 Codex ran out of room in the model's context window、context overflow、stream 中断或 remote compact 失败。与此同时，AxonHub 还可能存在独立的 Responses API / SSE / compact 兼容问题，会把本来可重试的上游瞬时错误包装成不可重试失败。

这个说法为什么靠谱

Codex 长任务不是单纯把对话无限塞进模型，而是依赖“上下文预算 + 自动压缩”。它需要知道两个关键数字：模型上下文窗口有多大，以及到多少 token 时开始 compact。典型配置形如：

model_context_window = 272000
model_auto_compact_token_limit = 250000

如果真实有效窗口是 272K，却被配置或网关 metadata 宣称为 1M：

model_context_window = 1000000
model_auto_compact_token_limit = 900000

那 Codex 会推迟压缩。表面看起来是“还有很多 context”，实际请求已经超过上游 Codex 链路能接受的范围。这个时候错误不是模型突然变笨，而是预算账本错了。

公开讨论里能看到相同的失配模式：有人报告 GPT-5.5 的 Codex catalog 在 400K/1M 与实际窗口之间不一致，可能绕过自动压缩；也有人要求 Codex Desktop 对 GPT-5.5 开放可选择的 1M context，因为当前有效窗口约 258K；还有反馈指出 model_context_window 写到 1M 会被静默压回约 272K，或配置并不按预期生效。OpenAI Developer Community 里也有用户记录 auto compression 没有及时触发，最终仍然跑出 Codex context window。这些资料指向同一个模式：API 或配置层面看似能写 400K / 1M，但 Codex 实际运行链路可能仍按更小窗口执行。

但它不是唯一原因

AxonHub 相关 issue 里还能看到另一类问题：Codex 走 /v1/responses streaming 时，AxonHub 对 SSE 关闭、上游 EOF、context canceled、response.completed 等行为的兼容不完全。比如有 issue 描述 CLIProxyAPI -> AxonHub -> OpenCode/Codex 这类链路中，经过 AxonHub 后更容易把上游瞬时失败暴露成 context canceled、TypeValidationError 或非重试错误；另一个已关闭 issue 则讨论了 AxonHub SSE handler 如何把客户端正常关闭误记成 canceled。

这说明排查时不能只盯 1M context。如果日志里是 context overflow 或 Codex ran out of room，优先查上下文窗口和 compact 阈值；如果日志里是 context canceled、stream disconnected before completion、failed to decode response、缺少 response.completed，更像 AxonHub Responses/SSE 兼容问题。

还有第三个细节是 compact 路由。社区有一篇 AxonHub + Codex 压缩上下文踩坑记录 提到，Codex compact 请求需要正确转发，甚至可能牵涉 provider name 兼容性细节。这类说法需要结合本地日志验证，不能照抄，但方向明确：Codex 不是普通 chat completions 客户端，它还依赖模型 metadata、Responses SSE、compact 这些行为。

推荐排查顺序

先查 AxonHub 对外暴露的模型 metadata。用实际客户端访问的 base URL：

curl -sS "$AXONHUB_BASE_URL/v1/models" \
  -H "Authorization: <redacted>" | jq .

重点看是否有 context_window、max_context_window、max_input_tokens 一类字段。如果 GPT-5.5 被报成 1M，而客户端又按这个数字设置自动压缩，就很危险。

再查本地 Codex 配置：

grep -R "model_context_window\|model_auto_compact_token_limit\|model_provider\|base_url" ~/.codex/*.toml

对 GPT-5.5，除非某个具体 endpoint 已经实测能稳定支持更大窗口，否则建议先保守固定：

model = "gpt-5.5"
model_context_window = 272000
model_auto_compact_token_limit = 240000

我顺手看了本机 Codex GPT-5.5 profile，目前是安全配置：

model = "gpt-5.5"
model_provider = "openai"
model_context_window = 272000
model_auto_compact_token_limit = 250000

也就是说，本机原生 Codex profile 没有把 GPT-5.5 误配成 1M。若 AxonHub 链路仍频繁失败，下一步应重点看 AxonHub 的模型 metadata、compact 转发和 SSE 日志。

解决方案

最稳的办法是给 AxonHub/Codex 单独建一个保守 profile，不要让所有客户端共享同一个 GPT-5.5 API metadata。Codex/OpenCode 这类 agent 客户端应暴露较保守的窗口：

model_context_window = 272000
model_auto_compact_token_limit = 240000
wire_api = "responses"

如果 AxonHub 支持 metadata override，就把给 Codex 用的 GPT-5.5 上下文明确改成 272K，而不是 1M。这样牺牲一点“理论窗口”，换来自动压缩提前触发和长任务稳定性。

同时检查 AxonHub 是否完整支持这些行为：

如果问题主要发生在大项目长线程，还要减少注入内容：少开 MCP，限制工具 schema，避免一次性塞全仓库，让 Codex 分阶段执行；失败后不要在同一条快满的线程里反复 retry，而是先 compact、总结或新开线程继续。

可操作结论

“AxonHub 让 Codex 以为有 1M，但实际 Codex 没有 1M”这个解释是靠谱的排查方向，但不能把所有失败都归因于它。真正要做的是把三层数字对齐：AxonHub /v1/models 暴露的上下文、Codex/OpenCode 本地配置、上游 Codex 实际可用窗口。对 GPT-5.5，当前保守值应按 272K 左右处理，auto compact 放在 240K–250K。若仍然失败，再查 AxonHub 的 Responses SSE 和 compact 兼容，而不是继续把 context 调大。

参考资料