𝐗𝐀𝐈 𝐂𝐨𝐧𝐭𝐫𝐨𝐥

XAI Router 让你告别 Codex tokens 余量不足的焦虑

Posted March 29, 2026 by XAI 技术团队 ‐ 16 min read

如果你最近在用 Codex，应该很容易理解一种很真实的焦虑：

明明只是继续同一件编码任务，为什么每一轮看起来都要重新“烧”掉一大段 prompt tokens？

这不是错觉。

在真实的 Codex 工作流里，请求前缀里往往包含大量重复内容：

  1. 长 system / developer instructions
  2. 工具定义与工具 schema
  3. 仓库上下文与会话状态
  4. 同一任务反复出现的约束、风格和规则

如果这些重复前缀能够稳定命中缓存，用户看到的就不是“每轮都重新付全价”的使用体验，而是更低延迟、更低成本、更可持续的编码工作流。

这正是 OpenAI 官方 Prompt Caching 想解决的问题，也是 XAI Router + Codex-Cloud 最近持续投入优化的重点。

上线验证后，我们在真实生产链路里已经看到：无论物理通道是 WebSocket 还是 HTTP，只要会话与前缀稳定，Codex 类请求的 cache 命中占比可以稳定达到 90%+。这对用户最直接的意义，就是大幅缓解“tokens 余量不足”的焦虑。

先说结论：我们做的不是“伪造缓存”，而是让官方缓存真正命中

先把最重要的一句话说清楚：

XAI Router 并没有发明一套与 OpenAI 不同的缓存规则。

我们做的事情，是在 多 Key 网关 + 协议兼容 + 长上下文编码场景 里，把那些原本会破坏官方 Prompt Caching 命中的因素尽量消掉，让官方缓存自己工作起来。

这也是为什么我们把核心原则定得很明确：

  1. 尽量保持与 OpenAI 官方技术语义一致
  2. 尽量不破坏 Codex 原生请求的透传特性
  3. 只在真正影响 cache 命中的地方做稳定化处理

OpenAI 官方 Prompt Caching 到底在做什么

根据 OpenAI 官方 Prompt Caching 文档，Prompt Caching 的核心规则并不复杂，但非常严格：

  1. 只有完全相同的 prompt 前缀才有机会命中 cache
  2. 要把静态内容放前面，把动态内容放后面
  3. 图片、工具定义、结构化输出 schema 也都属于可缓存前缀的一部分
  4. 请求达到 1024 tokens 以上，才会真正进入有效缓存区间
  5. prompt_cache_key 可以帮助平台把共享同类前缀的请求更稳定地路由到更可能已有缓存的机器

换句话说，Prompt Caching 不是“某个模型天生优惠”，也不是“平台帮你猜同义请求”。

它更像：

你给我稳定前缀，我给你稳定命中。

OpenAI 官方文档还明确指出：

  1. Prompt Caching 最多可将延迟降低到 80%、将输入 token 成本降低到 90%
  2. 缓存命中只和 前缀稳定性、路由稳定性、请求分桶稳定性 有关
  3. prompt_cache_key 与前缀 hash 会一起影响路由
  4. Cache 不会改变最终输出结果，缓存的是 prompt 预填充，不是把回答“直接抄上次的结果”
  5. Prompt cache 不会跨组织共享

这几个点非常关键，因为它直接解释了为什么很多“看起来已经接入 OpenAI”的代理方案，实际 cache 率并不理想。

为什么很多普通代理方案，cache 率并不高

在理想状态下，官方单 Key 直连的体验通常最好：

  1. 同一会话天然落到同一账号体系
  2. 请求前缀变化可控
  3. 会话连续性天然更强

但在真实产品里，经常不是这种结构。

很多用户最终面对的是：

Codex / Chat API / 兼容客户端 -> 多 Key 网关 -> 上游模型服务

如果中间层处理不好，就会出现几个典型问题。

1. 同一会话在不同 Key 间漂移

如果一个多 Key 网关只按“用户”做路由，而不是按“会话”做路由，那么同一个编码任务在不同轮请求里，可能会落到不同的下游 Key。

这会导致：

  1. 上游看到的会话不连续
  2. Prompt Caching 难以积累
  3. 同样的长前缀一遍又一遍重新预填充

2. 兼容层把 prompt 前缀搅乱

有些兼容层会额外注入很长的桥接提示、无关 developer prompt、变化较大的工具 remap 文本。

这样做也许能让“协议跑通”，但会直接破坏官方 Prompt Caching 最看重的那件事：

前缀稳定。

3. 过度改写请求语义

还有一些方案为了追求更高 cache，会主动强改：

  1. store
  2. stream
  3. instructions
  4. session / conversation 语义

这类方案有时确实能把缓存数据“做漂亮”，但代价是：

你得到的已经不再是一个尽量接近官方原生语义的代理。

XAI Router + Codex-Cloud 做了什么

我们的设计目标不是“把一切都重写一遍”，而是：

在尽量保留官方请求语义的前提下，把真正影响 cache 命中的工程问题逐个补齐。

一、XAI Router：把“用户级粘性”升级为“会话级粘性”

在路由层，XAI Router 不再只看“这个用户是谁”，而是会尽量识别：

  1. session_id
  2. conversation_id
  3. prompt_cache_key

然后在 /v1/responses、/responses、/v1/chat/completions、/chat/completions 这些 OpenAI 风格路径上，做 session-aware sticky。

这意味着：

  1. 同一用户的不同会话可以合理分散到不同 Key
  2. 但同一会话内部，会尽量稳定地落到同一个 Key

这是一个很重要的变化。

以前很多网关更像：

“一个用户尽量长期绑在一个 Key”

现在我们更接近：

“一个会话尽量长期绑在一个 Key”

对 Codex 来说，后者才是更重要的。

二、YAI-Sticky-Session：内部会话锚点，不污染上游协议

为了让 HTTP 路径也尽量靠近 WebSocket 那种连续会话效果，我们在 XAI Router 到 Codex-Cloud 之间引入了一个内部专用 header：

YAI-Sticky-Session

这个 header 的用途很单纯：

  1. 只作为 内部链路 的稳定会话锚点
  2. 不暴露给用户
  3. 不继续透传到真正 upstream

这样做的好处是：

  1. HTTP 路径也能把稳定会话信号传给下一层
  2. Codex-Cloud 不需要为了补会话而去重写 body
  3. 保持了“增强稳定性”与“保持协议干净”之间的平衡

三、Codex-Cloud：原生 /responses 尽量零改写，兼容入口做最小必要优化

这部分是我们特别看重的一点。

对于 原生 Responses API，Codex-Cloud 仍然尽量保持：

  1. body 透传
  2. 流式转发
  3. 不主动改写 store / stream / instructions

也就是说，原生 /responses 仍然尽量像官方原始请求。

但与此同时，我们在真正影响 cache 的点上做了必要增强：

  1. header 级 identity hardening
  2. 缺失 session_id / conversation_id 时消费 YAI-Sticky-Session
  3. 对兼容入口派生稳定的 prompt_cache_key
  4. 减少工具桥接 prompt 对前缀稳定性的污染
  5. 透传 prompt_cache_retention

一句话总结就是：

原生路径尽量透传，兼容路径尽量稳定。

为什么 WebSocket 和 HTTP 现在都能做到很高的 cache 率

很多人第一次看到我们的验证结果会以为：

是不是 WebSocket 天生比 HTTP 更容易命中 cache？

答案是：

不是协议本身更神奇，而是稳定会话更容易建立。

WebSocket 之所以天然有优势，是因为：

  1. 长连接天然维持会话连续性
  2. 一条连接内部更容易固定同一个 Key
  3. previous_response_id 与增量输入的语义更自然

但这不代表 HTTP 做不到。

只要你把下面几件事也做对：

  1. 路由按会话稳定
  2. 上游 session / conversation 语义稳定
  3. prompt_cache_key 稳定
  4. 前缀保持稳定

那么 HTTP 一样可以把 cache 命中率做得非常高。

这正是我们上线后实测观察到的现象：

WS 与 HTTP 都能在长上下文 Codex 工作流里把缓存命中占比推到 90%+。

这也是为什么我们更愿意说：

XAI Router 是在多 Key 架构里，尽量逼近“单 Key 官方直连”的体验。

和其他方案相比，XAI Router 的优势是什么

下面这张表，基本可以概括不同思路的差异：

方案Cache 友好度原生语义保真多 Key 稳定性HTTP / WS 一致性
官方单 Key 直连高最高无多 Key 弹性高
普通多 Key 代理常常一般中容易会话漂移经常不稳定
激进重写型代理可能较高较低中高高，但侵入大
XAI Router + Codex-Cloud高高高高

我们的优势不在于“把请求改得比官方还像另一个协议”，而在于：

  1. 尽量不破坏 Codex 原生体验
  2. 尽量让 OpenAI 官方 Prompt Caching 真正发挥作用
  3. 同时兼容 HTTP 与 WebSocket 两种工作方式

这点对于真正长期使用 Codex 的用户很重要。

因为你需要的不只是某一轮命中漂亮，而是：

整条工作流持续稳定。

https://api.xairouter.com：与官方技术语义保持一致，同时支持 WS / HTTP

目前通过 https://api.xairouter.com，你可以按非常接近官方的方式使用：

  1. POST /v1/responses
  2. POST /v1/chat/completions
  3. wss://api.xairouter.com/v1/responses

对于 WebSocket 模式，我们保持与 OpenAI 官方 WebSocket Mode 的关键语义一致：

  1. 单连接允许多次 response.create
  2. 同一连接内顺序执行
  3. 一次仅一个 in-flight response
  4. 不做 multiplexing

对用户来说，这意味着：

  1. 你可以继续按自己熟悉的 HTTP 工作流接入
  2. 也可以在需要更长会话、更强连续性的场景切换到 WebSocket
  3. 两条路径都能得到很高的 cache 命中表现

两份可直接使用的 Codex CLI 配置

下面给出两份可直接复用的配置。

先准备环境变量：

export XAI_API_KEY="你的 XAI Router API Key"

方案一：WS 协议配置

如果你偏好更强的长会话连续性、更多轮工具调用、更接近官方 WebSocket 工作流，推荐这份：

model_provider = "xai"
model = "gpt-5.4"
model_reasoning_effort = "xhigh"
plan_mode_reasoning_effort = "xhigh"
model_reasoning_summary = "none"
model_verbosity = "medium"
model_context_window = 1050000
model_auto_compact_token_limit = 945000
tool_output_token_limit = 6000
approval_policy = "never"
sandbox_mode = "danger-full-access"
suppress_unstable_features_warning = true

[model_providers.xai]
name = "OpenAI"
base_url = "https://api.xairouter.com"
wire_api = "responses"
requires_openai_auth = false
env_key = "XAI_API_KEY"
supports_websockets = true

[features]
responses_websockets_v2 = true

方案二：HTTP 协议配置

如果你更偏好简单直接、环境兼容性更广的接入方式，可以使用这份：

model_provider = "xai"
model = "gpt-5.4"
model_reasoning_effort = "xhigh"
plan_mode_reasoning_effort = "xhigh"
model_reasoning_summary = "none"
model_verbosity = "medium"
model_context_window = 1050000
model_auto_compact_token_limit = 945000
tool_output_token_limit = 6000
approval_policy = "never"
sandbox_mode = "danger-full-access"

[model_providers.xai]
name = "OpenAI"
base_url = "https://api.xairouter.com"
wire_api = "responses"
requires_openai_auth = false
env_key = "XAI_API_KEY"

你可以把其中一份保存为 ~/.codex/config.toml，重启 Codex 后直接开始使用。 如果配置里使用了 env_key = "XAI_API_KEY"，还需要同时在系统里写入同名环境变量：Linux 建议写入 ~/.bashrc，macOS 建议优先写入 ~/.zshrc，Windows 建议写入用户环境变量并重开终端。部分较老的 macOS、旧终端或某些 IDE 会话如果仍沿用 bash 登录环境，除了 ~/.zshrc 之外，最好再同步写入 ~/.bash_profile，必要时也补一份到 ~/.bashrc，避免 Codex 启动后读不到变量。

给用户最直接的意义：少一点 token 焦虑，多一点持续编码

很多人真正焦虑的，其实不是“模型能不能答”，而是：

  1. 长上下文一轮又一轮重复计费
  2. 工具链一旦拉长，prompt 开销迅速膨胀
  3. 会话做得越久，越担心 tokens 余量掉得过快

而当 cache 能真正稳定命中以后，用户的体感会很明显：

  1. 第二轮开始延迟显著下降
  2. 重复前缀不再反复全量计费
  3. 长任务更敢继续做，不用不停担心“还剩多少 token”

这就是标题里所说的：

“告别 Codex tokens 余量不足的焦虑。”

这不是营销话术，而是一个非常具体的工程结果。

现在就开始使用

如果你希望：

  1. 保持与 OpenAI 官方技术语义高度一致
  2. 同时获得多 Key 网关的稳定性与弹性
  3. 在 Codex 的 WS / HTTP 工作流里都尽量吃满 Prompt Caching 的收益

那么现在就可以直接把 Codex 指向：

https://api.xairouter.com

如果你准备开通包月或注册体验入口，可直接前往：

XAI Router 包月订阅 / 注册入口

参考资料

  1. OpenAI Prompt Caching
  2. OpenAI WebSocket Mode
  3. OpenAI Responses API Reference