时效性提醒：本文基于 2026 年 9 月中旬对 codex-state-kit 工具的实际运行观察和社区反馈。OpenAI 随时可能调整相关机制，届时本文描述的方法可能部分或完全失效。文中会明确区分"已观察到的事实"和"推测"。

前言

最近社区里 ChatGPT 和 Codex 的体验集体恶化，主要是三类问题：

1. 降智：同一个 Pro 账号，前一天还能写出完整的多文件重构方案，第二天同样的 prompt 返回的东西逻辑链断裂、上下文丢失、代码质量断崖式下跌。
2. Overload：Codex 的 cloud agent 频繁弹 “overloaded, please try again later”，排队半小时是常态。
3. 429 限流：API 调用返回 429 Too Many Requests，明明刚开始用、远没触及速率上限。

这三个现象大面积出现，不是个别用户的网络或 prompt 问题。社区里的共识是 OpenAI 的服务端调度出了状况。

最近有人逆向出了一个关键机制——292 响应和 current_turn_state——并做成了工具实现稳定绕过。本文拆解这个机制的工作原理。

一、292 和 current_turn_state

已观察到的事实

向 ChatGPT 的 chat completion 接口发请求时，在特定条件下会收到一个 292 响应（标准 HTTP 规范里没有这个状态码，是 OpenAI 自定义的）。这个 292 响应中携带一个 current_turn_state 字段。

实际运行中观察到的行为：

• 请求携带有效的 current_turn_state 时，模型输出质量正常、不触发 overload
• 请求不携带 state 或 state 过期时，更容易遇到降智和 overload
• state 的有效期约 1 小时（从实测中 keeper 的倒计时推断）
• state 过期后需要重新获取

截图中可以看到一个实际运行的例子：使用美国住宅宽带，第一次请求就拿到了 292，state 写入凭据文件，倒计时显示约 59 分钟剩余。

292 不是免死金牌——312 降智信号

拿到 292 并不意味着这一个小时内高枕无忧。OpenAI 会在使用过程中主动下发 312 响应，312 是一个降智信号：即使你手上的 292 state 还没过有效期，一旦收到 312，当前 state 实质上已经失效——后续请求会开始降智。

这说明 OpenAI 的调度不是"发了 292 就不管了"，而是持续评估的。292 给你的只是一个初始通行证，服务端保留了随时撤销的能力。312 就是撤销信号。

因此，正确的应对不是"拿到 292 就等一小时再续"，而是同时监控 312：一旦检测到 312，立即重新采集 292，不用等倒计时归零。

这意味着什么

OpenAI 在 chat completion 的响应中嵌入了一套双向信号机制：

• 292：通行证签发，携带 current_turn_state，表示当前资源充足、可以获得完整服务
• 312：通行证撤销，表示服务端决定降级你的后续请求，需要立即重新获取 292

降智"时好时坏"的原因就在这里：你拿到 292 后体验正常，但中途可能被 312 打断；或者 state 过期后没能续上新的 292。用户的感知就是"刚才还好好的怎么突然变蠢了"——你不知道是 state 到期了还是被 312 撤销了，表现完全一样。

二、怎么拿到 292

这是需要诚实讲的部分：目前没有公开的、确定的条件清单说明 292 的签发逻辑。以下是从 codex-state-kit 的实际运行和社区反馈中观察到的规律，不代表完整的因果关系。

观察到的规律

IP 类型有影响。 codex-state-kit 在采集 292 时会专门切换到住宅 IP 或原生 V6。截图中的记录显示"美国真家宽第一次请求就出了 292"，采集完成后切回香港 IPLC 日常使用。工具的设计者显然认为 IP 类型是一个重要变量。

但要注意：这不等于"住宅 IP 就一定能拿到 292"，也不等于"数据中心 IP 就一定拿不到"。可能还有其他因素在起作用：

• 账号类型和订阅等级：截图中使用的是 20X / 个人号。不同订阅等级是否影响 292 签发，没有对照实验
• 请求的模型：工具限定使用 gpt-6-astra。不同模型是否有不同的签发策略，不确定
• 请求频率和历史行为：是否存在基于账号历史的风控评分，不确定
• OpenAI 服务端的实时负载：同样的条件在不同时段可能结果不同
• 292 / 10 块中"10 块"的含义：截图中出现了这个表述，可能是响应中的某个配额字段，具体含义不明

不要想当然的部分

我没法告诉你"用美国住宅 IP 就能稳定拿到 292"，因为我没有足够的对照数据。工具的作者选择用住宅 IP 采集，可能是基于他们的大量测试经验，也可能只是一个足够好的经验做法。真正的签发逻辑在 OpenAI 的服务端，外部只能通过黑盒测试去逼近。

对使用者来说，实用建议是：照着工具的配置来——它让你切住宅 IP 就切，能跑通就行。“为什么"的问题可以后续慢慢验证。

三、注入原理

这是整个方案中最确定的部分——截图里有清晰的描述，逻辑也直接。

核心思路

1. 打一条请求，拿到 292 响应中的 current_turn_state
2. 把 state 写入本地文件
3. 后续所有 Codex / ChatGPT 请求经过本地代理，代理读取文件，把 state 注入到请求中
4. 代理同时监控响应：如果收到 312，立即触发重新采集
5. 即使没收到 312，到期前也自动续期

两个触发续期的条件：312 降智信号（立即续）和TTL 倒计时不足 5 分钟（定时续）。两条线并行，哪个先触发就先续。

采集和使用可以在不同的网络环境下进行。 截图明确显示：采集时切到住宅 IP，采完切回 IPLC，后续使用都在 IPLC 上。state 在切换 IP 后依然有效——至少在当前的观察中是这样。

注意：这并不意味着 OpenAI 没有做 IP 绑定。可能是没做，也可能是做了但绑定范围比较宽松（比如只绑定国家/ASN 而不是精确 IP），也可能是做了但还没生效。我们只能说"当前实测中，切 IP 后 state 仍然有效”。

注入流程

     [采集 — 292 过期前 或 收到 312 时]

  Clash 切到住宅/原生V6
       |
  keeper → 发一条 chat/completions (gpt-6-astra)
       |
  收到 292 → 提取 current_turn_state → 写入文件
       |
  Clash 切回日常线路


     [使用 — 持续]

  Codex 发请求
       |
  inject_proxy 拦截 → 读 state 文件 → 注入到请求
       |
  请求到达 OpenAI → state 有效 → 正常响应
       |
  如果响应是 312 → 通知 keeper 立即续期

对 Codex 完全透明。不需要重启 Codex，不需要改 Codex 的配置（除了把 Base URL 指向本地代理）。state 文件更新了，下一次请求自动用新的。

四、codex-state-kit 架构

截图中展示了一个已经工程化的实现，由四个组件协作：

keeper 的行为

从截图中可以确认：

• keeper 持续运行，大约每 45 秒检查一次 state 状态
• 当 state 剩余时间不到 5 分钟时触发续期
• 续期过程：切住宅/原生/V6 → 打一条 gpt-6-astra → 拿到 292 → 写入 current_turn_state
• 采不到 292 就会出现"空窗"——state 过期且无新 state 的时段
• 日志路径：~/codex-state-kit/logs/keeper.log

伪代码还原 keeper 的核心循环：

while True:
    remaining = state_expires_at - now()
    got_312 = check_312_signal()    # inject_proxy 检测到 312 时写入信号
    
    if remaining > 5 minutes and not got_312:
        sleep(45)
        continue
    
    # 续期（两种触发：TTL 不足 5 分钟 或 收到 312）
    if got_312:
        log("312 detected, immediate renewal")
    
    clash.switch_to("住宅/原生V6")
    resp = chat_completion(model="gpt-6-astra", messages= [...])
    
    if resp 包含 292:
        save(resp.current_turn_state)
        clear_312_signal()
        log("292 acquired")
    else:
        log("failed, will retry in 45s")
    
    clash.switch_back()

注意 312 触发的续期是立即的，不等 45 秒轮询周期。inject_proxy 在检测到 312 响应时写入一个信号文件（或通过进程间通信），keeper 下一次循环检查到信号就立刻启动采集。

客户端配置

截图中直接给出：

Base URL: http://127.0.0.1:3001/v1 
API Key: ~/codex-state-kit/config.json 里的 gptload.access_key 
模型: gpt-6-astra

Codex 或其他兼容 OpenAI API 的客户端把 Base URL 指向本地代理即可。

五、已知的限制和坑

5.1 空窗期

两种情况会导致空窗：state 到期续不上，或者收到 312 但新的 292 采不到。后者更棘手——312 可能在你工作到一半的时候突然出现，如果此时住宅 IP 不可用或 OpenAI 全局限流，你的 Codex 会立刻降智，直到采到新的 292。

keeper 会持续重试，但空窗期内没有什么可以补救的。

5.2 模型要对齐

截图中明确标注"限定模型 gpt-6-astra"。采集时用什么模型、使用时用什么模型，需要一致。跨模型的 state 是否有效，没有看到相关信息。

5.3 账号绑定

state 和账号关联。一个账号的 state 不能注入到另一个账号的请求中。多账号场景需要每个账号单独跑 keeper。

5.4 “10 块”

截图中提到"292 / 10 块"。这个"10 块"可能是 292 响应中的某个配额或分片参数，但截图里没有更多细节。如果你自己抓包研究，留意一下这个字段。

六、和社区其他方案的对比

社区针对降智和 overload 还有几种常见做法：

292 注入的区别在于它不是在应用层碰运气，而是直接拿到了服务端用来做调度决策的凭据。

七、关于技术严谨性的说明

写这篇文章时我刻意区分了三类信息：

确认的事实（截图直接显示 + 工具实际运行 + 用户反馈）：

• 292 响应存在，携带 current_turn_state
• 312 响应存在，是服务端主动下发的降智信号，收到后需立即重新采集 292
• 292 state 的名义有效期约 1 小时，但可被 312 提前撤销
• state 可以被提取、存储、注入到后续请求
• 注入后确实可以避免降智和 overload
• 采集时使用住宅 IP，使用时可以在其他 IP 上
• codex-state-kit 的组件架构和 keeper 的续期行为

合理推断（基于观察但没有直接证据）：

• IP 类型是影响 292 签发的因素之一（工具作者选择切 IP 采集，说明他们认为这有用，但缺少对照实验）
• state 没有严格绑定 IP（当前实测切 IP 后有效，但不排除有宽松绑定或未来收紧）

不知道的（没有信息、不做猜测）：

• 292 签发的完整条件列表
• “10 块"的确切含义
• 不同订阅等级、不同模型对 292 签发的影响
• OpenAI 内部调度器的具体实现
• 这个机制未来会不会被修改

如果你在实际使用中发现了更多规律，欢迎交流。

原文：blog.caowo.de/posts/chatgpt-codex-292-state-anti-degradation-2026