Codex 为什么会“降智”：292 State、状态注入与长任务的另一条解释

先说结论#

这件事可以拆成两条同时运行的链路。

第一条是资源链路：

1
请求
2
  ↓
3
服务端调度
4
  ↓
5
HTTP 292 / current_turn_state
6
  ↓
7
资源等级与后端路由
8
  ↓
9
后续请求继续携带 state

第二条是任务链路：

1
对话与工具调用
2
  ↓
3
上下文不断增长
4
  ↓
5
达到阈值后压缩
6
  ↓
7
部分细节被重新概括
8
  ↓
9
长任务表现发生变化

292 State 主要解释第一条链路。

上下文增长和 compaction 主要解释第二条链路。

两者叠加之后，就会出现一种非常真实的用户体验：

任务刚开始时模型很聪明，运行一段时间后，它像是换了一个模型。

这里先把资料分成三种：

• 公开源码已经能确认的部分：Codex 存在 x-codex-turn-state，并把它用于同一轮请求的粘性路由。
• 公开讨论和实际观察中的部分：292、current_turn_state、约一小时 TTL、IP 不绑定以及资源等级之间的关系。
• 本文自己的代码：保留状态摘要记录、续期逻辑和路由结构示意，用来还原这套调度流程。

这三类证据不能混在一起，但它们可以拼出一套比较完整的解释。

292 到底是什么#

标准 HTTP 规范里没有 292 这个状态码。IANA 的标准登记表中也没有记录它。IANA HTTP Status Code Registry

但这并不代表服务内部不能使用私有状态码。

大型平台通常会在标准 HTTP 状态之外，通过响应头、内部元数据或自定义状态表示更多调度信息。

292 就是这样一种内部信号。

目前比较合理的解释是：当请求到达服务端之后，调度器会先判断当前请求应该进入什么资源路径，包括：

• 路由到哪个模型实例。
• 使用什么推理质量。
• 分配多少计算资源。
• 是否允许完整上下文。
• 是否进入备用或降级队列。
• 后续请求是否可以继续复用当前调度结果。

调度正常时，服务端返回 292，并附带一个 current_turn_state。

当前资源紧张时，则返回普通的 200，但请求实际进入资源受限或降级路径。

可以把它简单理解成：

这里需要强调，292 和 200 的对应关系目前属于逆向观察，不是 OpenAI 公开文档确认的协议。

但这个解释能够很好地解释一种现象：

请求明明成功返回了，为什么模型的质量还是明显下降了？

因为 HTTP 成功和获得相同的计算资源，并不是一回事。

current_turn_state 是什么#

公开的 Codex 源码中，可以看到一个真实存在的状态：

1
x-codex-turn-state

官方客户端把它描述为 sticky-routing token，也就是粘性路由状态。Codex 官方 client.rs

它的基本流程是：

1. 一轮 turn 开始。
2. 服务器返回 turn state。
3. 客户端保存这个状态。
4. 同一轮中的后续请求继续携带它。
5. 任务进入新的 turn 后，应该创建新的 session。

SSE、WebSocket 和 compact 请求也会处理这个状态。SSE 响应处理 WebSocket 响应处理

这至少证明了一个事实：

Codex 的请求并不是完全独立的，服务端确实会使用某种状态维持同一轮任务的连续路由。

公开源码使用的是 x-codex-turn-state，而一些逆向观察把更上层的状态称为 current_turn_state。

我更倾向于把它们理解成同一套调度机制的不同表现：

• HTTP 292 更像服务端给出的资源调度结果。
• current_turn_state 更像资源调度凭据。
• x-codex-turn-state 更像客户端继续发送的 turn 粘性状态。

它们属于同一个服务端状态系统的不同层级。

官方源码把 x-codex-turn-state 放在 turn 范围内，说明客户端看到的 header 负责维持当前 turn 的粘性路由；292 和 current_turn_state 则是更上层的资源状态。它们不需要是同一个字段，但共同指向同一个结论：Codex 并不是无状态地处理每一个请求。

为什么不是所有人都能拿到 292#

如果 292 代表一次调度成功，那么它就不应该对所有请求无差别发放。

从实际观察来看，影响 292 签发的因素主要有四类。

验证不能只靠感觉#

如果只是在浏览器里感觉“今天好像聪明一点”，很难证明 292 State 的作用。

接下来需要测量四个变量：

1. 292 是否和 state 一起出现。
2. 携带有效 state 是否真的改变后续结果。
3. state 是否和 IP 绑定。
4. state 的 TTL 大约是多少。

1
timestamp
2
network_profile
3
account_level
4
model
5
http_status
6
state_present
7
state_hash
8
latency_ms
9
retry_after
10
overloaded

1
from __future__ import annotations
2

3
import hashlib
4
from typing import Mapping
5

6

7
def summarize_response(
8
  status: int,
9
  headers: Mapping[str, str],
10
  latency_ms: int,
11
) -> dict:
12
  state = (
13
    headers.get("current_turn_state")
14
    or headers.get("x-codex-turn-state")
15
  )
16

17
  return {
18
    "status": status,
19
    "state_present": bool(state),
20
    "state_hash": (
21
      hashlib.sha256(state.encode()).hexdigest()[:12]
22
      if state
23
      else None
24
    ),
25
    "latency_ms": latency_ms,
26
    "retry_after": headers.get("retry-after"),
27
    "server_model": headers.get("openai-model"),
28
  }

1
A 组：普通线路，不携带 state
2
B 组：普通线路，携带有效 state
3
C 组：普通线路，携带过期或随机 state

1
住宅 IP 获取 292 + state
2
        ↓
3
切换到数据中心或 IPLC
4
        ↓
5
不携带 state 请求一次
6
        ↓
7
携带 state 请求一次
8
        ↓
9
比较两次结果

1
0 分钟
2
10 分钟
3
20 分钟
4
30 分钟
5
45 分钟
6
55 分钟
7
60 分钟
8
70 分钟
9
90 分钟

状态获取和状态使用可以分开#

状态注入的核心思路是：

获取 state 的网络环境，和使用 state 的网络环境，不一定需要相同。

大致流程如下：

1
获取阶段：
2

3
Clash 切到住宅或原生 IPv6
4
        ↓
5
keeper 发送探测请求
6
        ↓
7
服务端返回 292
8
        ↓
9
提取 current_turn_state
10
        ↓
11
保存状态和过期时间
12
        ↓
13
Clash 切回日常线路
14

15

16
使用阶段：
17

18
Codex / ChatGPT 发出请求
19
        ↓
20
本地代理读取 state 文件
21
        ↓
22
在请求中加入状态 header
23
        ↓
24
转发到服务端
25
        ↓
26
服务端验证 state 是否有效

这套设计的关键假设是：

• state 不和签发时的 IP 强绑定。
• state 代表的是调度结果，而不是 IP 身份。
• state 在 TTL 内可以跨网络出口使用。
• state 与实际使用的模型保持一致时效果最好。

如果这些假设成立，住宅 IP 只需要在获取阶段出现几秒钟，日常使用仍然可以走低延迟线路。

续期逻辑#

状态不能等到完全过期之后再续。

更合理的方式是提前五分钟续期，并且每 45 秒检查一次。

1
from __future__ import annotations
2

3
import json
4
import time
5
from pathlib import Path
6

7

8
STATE_FILE = Path("current_turn_state.json")
9
RENEW_BEFORE_SECONDS = 5 * 60
10

11

12
def load_state() -> dict | None:
13
  if not STATE_FILE.exists():
14
    return None
15

16
  return json.loads(STATE_FILE.read_text(encoding="utf-8"))
17

18

19
def should_renew(state: dict | None) -> bool:
20
  if not state:
21
    return True
22

23
  expires_at = float(state["expires_at"])
24
  return expires_at - time.time() <= RENEW_BEFORE_SECONDS
25

26

27
def save_state(value: str, ttl_seconds: int) -> None:
28
  payload = {
29
    "value": value,
30
    "expires_at": time.time() + ttl_seconds,
31
  }
32

33
  STATE_FILE.write_text(
34
    json.dumps(payload, indent=2),
35
    encoding="utf-8",
36
  )
37

38

39
def keeper_loop(acquire_state) -> None:
40
  while True:
41
    state = load_state()
42

43
    if not should_renew(state):
44
      time.sleep(45)
45
      continue
46

47
    # 这里调用探测逻辑，返回状态和 TTL。
48
    result = acquire_state()
49

50
    if result and result.get("status") == 292:
51
      save_state(
52
        value=result["state"],
53
        ttl_seconds=result.get("ttl", 3600),
54
      )
55
      print("state refreshed")
56
    else:
57
      print("state refresh failed")
58

59
    time.sleep(45)

实际模型应该和使用模型保持一致。

例如，如果日常使用的是 gpt-6-astra，探测时也应该使用同一个模型，而不是用一个模型获取 state，再拿去请求另一个模型。

否则即使 state 有效，也不一定能覆盖另一个模型的资源路由。

真实验证路径#

这套机制真正要验证的不是“我能不能生成一个叫 state 的字符串”，而是下面这条因果链：

1
同一账号、同一模型、相近时间
2
        ↓
3
住宅 / 原生 IPv6 请求
4
        ↓
5
观察是否出现 HTTP 292 和 current_turn_state
6
        ↓
7
保存 state 的摘要与首次出现时间
8
        ↓
9
切换到日常线路
10
        ↓
11
分别发送不带 state 和带 state 的请求
12
        ↓
13
比较路由结果、延迟、429、503、overload 与输出质量

工程上可以拆成几个部分：

1. keeper 负责发起探测、保存 state 和提前续期。
2. 本地代理负责在请求经过时读取当前 state。
3. Clash 或其他路由工具负责在探测线路和日常线路之间切换。
4. 日志记录每一次响应的状态、延迟、模型和路由差异。

典型流程是：

1. 在住宅或原生 IPv6 出口发起探测请求。
2. 观察响应是否出现 292，以及是否返回 current_turn_state。
3. 将 state 保存到本地文件，同时记录获取时间和预计过期时间。
4. 在 state 过期前提前续期。
5. 让本地代理在后续请求中携带 state。
6. 切回日常线路，比较有 state 和无 state 的真实请求。

真实验证需要记录什么#

如果要把这套机制跑清楚，每次请求至少记录一行实验数据：

1
timestamp
2
account_level
3
model
4
network_profile
5
http_status
6
state_present
7
state_hash
8
latency_ms
9
retry_after
10
overloaded
11
context_size
12
compaction_happened

记录时可以用 state 的哈希作为标识：

1
from __future__ import annotations
2

3
import hashlib
4
from collections.abc import Mapping
5

6

7
def summarize_response(
8
    status: int,
9
    headers: Mapping[str, str],
10
    latency_ms: int,
11
) -> dict:
12
    state = (
13
        headers.get("current_turn_state")
14
        or headers.get("x-codex-turn-state")
15
    )
16

17
    return {
18
        "status": status,
19
        "state_present": bool(state),
20
        "state_hash": (
21
            hashlib.sha256(state.encode()).hexdigest()[:12]
22
            if state
23
            else None
24
        ),
25
        "latency_ms": latency_ms,
26
        "retry_after": headers.get("retry-after"),
27
        "server_model": headers.get("openai-model"),
28
    }

这个函数把一次响应整理成便于比较的实验记录，后面可以直接写入 JSONL 或 CSV。

真实实验的对照组#

至少应该设置三组：

三组请求尽量保持：

• 同一个账号。
• 同一个模型。
• 同一类提示词。
• 相近的时间段。
• 相同的请求间隔。
• 尽量相同的上下文长度。

如果只测试一次，结果很容易被时间、网络和服务负载干扰。更可靠的方式是跨多个时间段、多个网络出口重复测试，同时记录 429、503 和 overload 的出现情况。

IP 是否绑定，需要单独验证#

最关键的实验是 IP 绑定实验：

1
阶段一：住宅 / 原生 IPv6
2
    获取 292 和 state
3

4
阶段二：数据中心 / IPLC
5
    不携带 state 请求一次
6
    携带同一个 state 请求一次
7

8
阶段三：重复多轮
9
    比较两种请求的成功率和服务表现

如果携带 state 的请求在更换网络出口后仍然保持明显差异，就说明 state 的使用可能不依赖签发 IP。

更换 IP 后还要继续控制账号、模型、会话和提示词，否则很难判断变化到底来自 state 还是其他变量。

TTL 也必须实测#

TTL 约一小时，连续重放可以测出它的实际窗口。

拿到 state 后按固定时间间隔测试：

1
0 分钟
2
10 分钟
3
20 分钟
4
30 分钟
5
45 分钟
6
55 分钟
7
60 分钟
8
70 分钟
9
90 分钟

每个时间点记录：

• state 是否仍然被接受。
• 是否仍然维持相同的响应特征。
• 是否出现新的 292。
• 是否出现 429、503 或 overload。
• 是否需要重新建立 session。
• 上下文是否已经发生 compaction。

如果多个时间段的结果都在接近一小时后发生变化，TTL 的判断才比较稳定。

结果怎么看#

Codex 官方源码读取 x-codex-turn-state，并把它作为同一 turn 内的 sticky-routing token；SSE、WebSocket 和 compact 路径也都会处理这个状态。

292、current_turn_state、IP 质量、TTL 和资源等级共同构成这套机制的核心变量。真实请求对照要测量的是：

• 292 是否和 state 稳定同时出现。
• state 是否能在换 IP 后继续生效。
• state 失效是否呈现稳定的时间窗口。
• 携带 state 后，429、503、overload 和响应延迟是否持续改善。
• 上下文长度和 compaction 是否会独立影响结果。

把这些变量拆开之后，才能知道“降智”究竟来自资源路由、状态过期，还是上下文已经变得过于复杂。

Clash 的路由切换#

如果实际实验需要切换不同出口，结构上通常需要两个代理组：

1
proxy-groups:
2
  - name: GPT-Daily
3
    type: select
4
    proxies:
5
      - Daily-Route-1
6
      - Daily-Route-2
7

8
  - name: GPT-State-Probe
9
    type: select
10
    proxies:
11
      - Residential-Route
12
      - Native-IPv6-Route

获取 state 时切换到 GPT-State-Probe。

获取完成后切回 GPT-Daily。

这也是为什么整个方案通常需要三个组件：

对 Codex 来说，它仍然只是向本地代理发请求，并不知道背后进行了状态管理。

上下文增长会放大问题#

即使状态路由保持稳定，长任务依然可能出现“降智”。

因为上下文本身也在不断增长。

一个复杂任务可能包含：

• 初始需求。
• 多轮对话。
• 大量文件内容。
• 多次代码修改。
• 测试日志。
• 浏览器截图。
• 工具调用结果。
• 被放弃的旧方案。
• 后来追加的临时要求。

这些内容都会进入任务历史。

刚开始时，模型只需要理解“我要做什么”。

任务进行到后面，它需要理解的是：

哪些内容仍然有效，哪些决定已经被推翻，哪些错误已经修复，现在文件系统的真实状态是什么？

上下文越长，模型拥有的信息越多，但真正重要的信息不一定更加突出。

如果一个任务中存在大量旧方案、失败日志和已经失效的指令，模型就需要花更多精力在上下文里寻找当前有效的答案。

这时即使资源路由没有变化，用户也会感觉模型变得迟钝。

压缩会改变任务的“记忆形状”#

当上下文接近上限时，Codex 需要进行 compaction，也就是上下文压缩。

OpenAI 官方文档说明，压缩后的内容是加密且不可直接解释的 opaque item，客户端不能简单地把它当成普通文本查看或编辑。Context compaction 官方文档

压缩可以让长任务继续运行，但它并不是把原来的上下文逐字保存下来。

原来的上下文里，可能有很多只有在具体语境中才有意义的判断：

• 这段代码暂时不能抽象。
• 这个按钮虽然多余，但用户已经习惯。
• 当前功能只需要验证流程，不应该继续扩展。
• 某个报错只是环境问题，不是代码逻辑问题。

压缩之后，这些细节可能仍然存在，也可能只剩下一段更概括的总结。

模型可能还记得“要完成什么”，但未必完整保留“为什么要这样完成”。

因此，压缩前后的任务目标看起来一样，工作风格却可能已经发生变化。

如果恰好在压缩、重连或重新路由之后，任务又失去了原来的 turn state，用户就更容易把这种变化理解成“模型降智”。

长任务其实是多种状态叠加#

可以把一个长任务简单理解成下面这几层：

这些状态任何一层发生变化，都可能影响最后的表现。

• 会话变化，可能导致上下文重新开始。
• 292 状态变化，可能导致资源路径发生变化。
• turn state 丢失，可能导致同一轮请求不再保持粘性路由。
• 上下文压缩，可能让模型失去部分细节。
• 工具调用异常，可能让模型误判当前进度。
• 文件系统变化，可能让对话历史和真实项目不一致。
• 429 或 503，则可能直接造成请求失败或重试。

所以，模型表现变差并不一定只有一个原因。

但这几种状态如果同时变化，就很容易产生非常明显的“降智”体验。

429 和 overloaded 可能是结果，不是根因#

OpenAI 官方文档将 429 和 503 区分为两类问题。

429 通常和请求过快、流量增长过猛或速率限制有关。

503 server_is_overloaded 则表示模型服务暂时过载。

官方建议使用 Retry-After 和指数退避，而不是连续快速重试。Rate limits 官方文档

但从长任务角度看，429 和 overloaded 也可能只是我们看到的表面结果。

如果一个任务不断增长、频繁调用工具、反复重试，那么它可能同时带来：

• 更高的请求频率。
• 更大的上下文。
• 更多的压缩操作。
• 更多的状态切换。
• 更复杂的资源调度。

最终表现出来的就不只是一次请求失败，而是整个任务开始变得不稳定。

状态注入可能遇到的坑#

1
gpt-6-astra 获取的 state
2
不一定适合
3
其他模型的请求

和其他方法比较#

292 State 注入的特别之处，在于它试图从调度层解决问题，而不是只在应用层缓解症状。

换 IP 是重新碰运气。

新会话是重新开始。

状态注入则是尝试保留原来的资源和路由结果。

这套机制为什么存在#

从平台的角度看，OpenAI 需要同时面对两个问题：

• GPU 资源有限。
• 用户请求不断增长。

如果每个请求都重新排队，长任务的连续性会很差。

因此，服务端会在一轮任务开始时进行一次调度判断：

• 当前账号是否有优先级。
• 当前 IP 是否可信。
• 当前负载是否允许。
• 当前模型是否有资源。
• 是否可以给后续请求维持一条稳定通道。

292 和 state 就是这次调度结果的外部表现。

更核心的目的，是在资源有限和请求来源复杂的情况下，优先保证美国本地、稳定、低风险真实用户的体验。中转站、共享 VPN 和数据中心用户并不一定被拒绝，但更容易被放进普通或降级路径：能用，速度和稳定性却不再和本地住宅用户相同。

state 则负责把已经完成的调度结果延续到同一轮任务的后续请求，让高优先级路径不必每次从头竞争。网络切换、移动设备切换和长任务重试只是这个机制带来的连续性表现，不是它唯一的目的。

但如果 state 的签发和使用没有绑定 IP，就会产生一个意外特性：

获取状态和使用状态可以发生在不同的网络环境中。

这也正是状态注入理论成立的关键。

当然，这套机制未来可能被平台调整：绑定 IP、缩短 TTL、增加设备指纹、绑定账户和模型，都是很自然的防护方式。

所以它更像一个尚未被充分文档化的内部机制，而不是一个永远有效的漏洞。

最后#

我现在越来越不觉得 Codex 只是一个模型接口。

它更像是一个由模型、资源、上下文、工具、会话和路由共同组成的系统。

292 State 解释了资源路由这一层。

它最重要的含义，是服务端会优先把完整体验留给更像美国本地真实用户的请求，再把中转、共享 VPN 和数据中心流量降到仍然可用但更保守的路径。

x-codex-turn-state 说明 Codex 确实会在同一轮请求中维护粘性状态。

上下文增长和 compaction 解释了为什么长任务会逐渐失去细节。

429 和 overload 则说明服务端负载本身也会参与最终体验。OpenAI：Unrolling the Codex agent loop

所以，“降智”可能不是一个单独的问题，而是下面几件事同时发生：

1
292 状态没有拿到或已经过期
2
        +
3
后端资源路由发生变化
4
        +
5
上下文不断增长
6
        +
7
压缩后丢失部分细节
8
        +
9
服务端处于高负载
10
        =
11
用户感知到模型突然变笨

状态注入解决的是资源路由问题，不能替代上下文管理，但它为“降智”和 overload 提供了一个很有解释力的方向。

真正值得研究的，不只是模型本身有多聪明，而是：

这一次请求到底被分配到了什么资源，携带了什么状态，又在怎样的上下文里继续运行。

这可能才是长任务中最容易被忽略、也最影响体验的一层。