续轮绑不住凭证、410 不触发换号：本地那两层判定没被调用
两件今天就能处置的事：v8.0.44 不把 previous_response_id 当会话键，只带它的续轮会换凭证；sub2api 的兼容入口把上游 410 原样透传，账号错误策略整层不跑。
北京时间 12:26 到 13:42，四仓没有新版本，主干也没有新提交。窗口里只有两件事，形状却一样：本地那层本该做判断的代码，在默认路径上根本没被调用。
一件在 CLIProxyAPI：客户端拿上一条回复的 id 往下说，代理认不出这是同一条会话，粘性不生效1。
一件在 sub2api：上游回 410，请求从兼容入口原样出站，账号错误策略整层跳过2。
上一条 response 的 id，在 v8.0.44 里不是会话键
现在的 Responses 客户端多轮对话有两种写法：一种把整段历史重发，一种是只发新一句，带上
previous_response_id。后一种在代理这边要靠会话键才能钉住凭证。v8.0.44 的
ExtractSessionInfo 里没有这个键。
sdk/cliproxy/session/info.go 第 782–806 行：这段读 conversation 对象（conv: 前缀，第 785–794 行）与 prompt_cache_key（pck: 前缀，第 796–806 行），pck 优先于 conversation。整份文件搜不到 previous_response_id。1* 它认的键排下来是：Claude Code / Codex / OpenCode / pi 的显式会话头、
prompt_cache_key、conversation.id、metadata.session_id 这一类3。只带
previous_response_id 的续轮，这些都没有。它掉到兜底那层：先把请求开头几条消息算成指纹，去做「最长公共前缀」匹配，再退回旧的派生哈希4。续轮里只看得到新写的一句，前缀与已存的会话对不上。于是这条请求在选号时被当成新会话，池子里有第二张凭证，它就可能落到第二张上。
落到别处会怎样，仓库自己写过一句话。WebSocket 那条路径在同一个 response id 找不到时会回
previous_response_not_found，提示「把完整对话重发一遍，不要带 previous_response_id」5。HTTP 这条路没有这句提示，换号之后继续发出去，只是上一条回复在那张凭证下不存在。
还有两处会让这件事看起来「有时好有时坏」。
Codex 与 xAI 两个执行器在出站前会把这个字段删掉——
codex_executor_execute.go 第 67 行、codex_executor_stream.go 第 69 行、xai_executor_request.go 第 103 行6。两层叠起来：默认没开会话亲和；就算开了，也认不出这个键。这就是为什么有些站的 Responses 多轮一直很稳——它只有一张凭证，或客户端同时带了
prompt_cache_key。今天能改的那一个键
给请求带一个稳定的会话键，比等发行版快。
三个都行，按优先级从高到低：
prompt_cache_key（任意稳定字符串，同一段对话保持不变）、conversation（字符串或 {"id": …}）、metadata.session_id。然后把
routing.session-affinity 打开。打开之后，同一会话的后续请求才会继续走同一张凭证，session-affinity-ttl 默认 1 小时。代价写在同一个文件里：绑定的凭证不可用之前不会被优先级抢走，等于用「新会话的冷启动更集中」换「老会话的缓存不丢」。
有人提了补丁，但补丁自己被挑出两处
PR #7044 在 12:48 开出，base 指 dev，1 提交、7 文件 +221/−3，
mergeable 为 clean9。它的改法是四步：加一个
session_affinity_response_id 的元数据键；在插件执行器里从非流式 body 与 SSE 的 response.completed 抓 response.id；绑定成功时用 SetAliases 把「上一条会话键」和「response:<id>」一起指到同一张凭证；ExtractSessionInfo 里认 previous_response_id，前缀 response:10。
af04dc5 的 sdk/cliproxy/session/info.go 第 690–706 行：第 693 行注释写明这是给 Responses 续轮用的，第 694–697 行从顶层或嵌套的 request 取 previous_response_id，第 700 行拼成 response: 前缀后直接返回。这段插在「OpenAI thread」判定之后，所以带 thread_id 的请求仍先走线程那条。10* 自动评审在 13:03 给出四条，前两条是 P1。
第二条：Home 模式下多凭证派发走的是另一条路，别名只落在本地
SessionCache 里，Home 那侧不知道这个 response id 属于哪个会话。两条 P2 是工程细节：多行 SSE 里
response.id 出现在后一行时会被提前标成「已抓取」；插件按块投递、块内没有换行时，缓冲会一直涨。结论对运维很简单：今天别等它。带一个
prompt_cache_key 就能把这件事按住，而且这键在 v8.0.44 里已经生效。顺带一提，仓库里还有一张更早的单在讲同一处：PR #6705 说 Codex 的 HTTP 路径把
previous_response_id 删掉却不重建上下文，18 文件 +1255/−13，10-17 开到现在仍是 open12。上游回 410，账号错误策略整层不跑
第二件事在 sub2api，13:34 开出的一张单，作者 QLHazyCoder，环境 v0.2.17，作者按同样方法在 main 上复核过2。
现象是一张 Anthropic API Key 账号的
base_url 还指着旧域名，上游回 410 Gone，body 里写「Service moved: set your base URL to https://…」。同一个账号、同一个上游错误，三个入口给出三种结果：
/v1/messages 回 502，/v1/chat/completions 与 /v1/responses 把 410 和上游原文原样吐给客户端。更关键的是账号侧：走兼容入口那两次，账号没有被禁用、没有冷却、也没有换号，于是一直被调度。
根因是换号白名单。v0.2.18 的
shouldFailoverUpstreamError 只有 401、403、429、529 和 ≥500 这几种，410 不在里面13。
backend/internal/service/gateway_forward.go 第 42–58 行：第 47 行是 shouldFailoverUpstreamError 的定义，第 49 行列出 401/403/429/529 四个码，第 52 行用 statusCode >= 500 兜住 5xx。410 两条都不满足。13* 410 于是落到这个判定之外的分支。
backend/internal/service/gateway_forward_as_chat_completions.go 第 150–184 行：第 158 行判是否换号，命中才在第 159 行记 ops 事件、第 172 行调 HandleUpstreamError。没命中就直落第 181 行 writeGatewayCCError(mapUpstreamStatusCode(...))，第 182 行返回错误。这一支既不记 ops，也不调账号策略。14* mapUpstreamStatusCode 只做一件事：≥500 抬成 502，其余原样15。410 就这样出去了。/v1/responses 那条一样，同一处判断在第 193 行。为什么 /v1/messages 是另一种结果
Anthropic 格式那个入口走的是
handleErrorResponse。它在判换号之前就先调一次 HandleUpstreamError，账号级规则（自定义错误码、临时不可调度）因此有机会生效。然后它还有一层兜底：
applyErrorPassthroughRule 先匹配全局透传规则，没命中再按状态码给文案，未知 4xx 一律落 502「Upstream request failed」17。所以同一个上游错误，在 messages 入口是一句话加 502，在兼容入口是裸 410 加上游原文。
这不是「410 该不该换号」的新问题
OpenAI 平台那条路的白名单是 401、402、403、405、429、529 与 ≥500——402 和 405 都在，410 不在18。
也就是说两条内置白名单里都没有 410。上游这次给的是域名迁移的提示，正好整批撞在这条缝上。
报障人给的说法更能说明代价：那张号累计 100 多次 410 之后才被人手动设成不可调度；上层网关在 chat 入口看到 410、在 messages 入口看到 502，也没法统一做重试。
今天能做的三件，按顺序：
- 先把
base_url改成上游给的新域名，这是根因，改完 410 就消失。 - 迁不完的号，在分组里手动停用；不要指望自定义错误码或临时不可调度规则在这条路上生效。
- 排障时别去 sub2api 的 ops 面板找这条 410，它没有记录；要看上游网关自己的访问日志。
修复单目前没有。sub2api 最近开放的十张 PR 里，没有一张碰这两个兼容入口的错误处理。
版本与上游
四仓窗口内零新版本。CLIProxyAPI 仍是 v8.0.44（10-26 23:48 发布，dev 头停 10-27 10:29）19；sub2api v0.2.18（10-23 15:44）20；codex-proxy v2.1.21-beta（10-27 02:42）21；codex2api v3.1.1（10-17 05:46）22。codex-proxy 与 codex2api 窗口内零条目，sub2api 只有一张四月旧帖被顶起。
上游三家没有新事件。OpenAI 全绿，最近一条仍是 10-27 02:19–02:30 的 Ads POST 错误率23；Claude 全绿，最近是 10-25 16:17 起的 Fable 5.1 报错24；GCP 最新仍是 10-23 00:19 的 europe-west225。
重置侧也安静。Tibo 最近一条真发帖是 03:24 的 Day 22（讲 Terra 回归），不含重置承诺；11:29 那条只是对别人的一句回复，追踪站把它标为只计可见性。最近一次观测到的全局重置仍是 10-26 14:08，追踪站记成
reset_observed，验证状态却还停在 pending26。接下来要做的三件事
- 抓一条 Responses 续轮的请求体，看有没有
prompt_cache_key、conversation或metadata.session_id。一个都没有，就补一个稳定的，再把routing.session-affinity打开。 - 查池子里有没有账号的
base_url还指着旧域名。有就今天改掉，这是一次性动作，改完 410 不会再回来。 - 用
/v1/messages与/v1/chat/completions各打一次同一个坏号，确认你现在看到的是 502 还是裸 410——两者的处置方式不一样。
References
- 1v8.0.44 的会话键读取
github.com
- 2sub2api issue #8370
github.com
- 3同一段之前的通用会话键
github.com
- 4v8.0.44 Pick 的注释与分支
github.com
- 5openai_responses_websocket.go 第 1040 行
github.com
- 6codex_executor_execute.go 第 60–70 行
github.com
- 7会话头的读取位置
github.com
- 8config.example.yaml 第 168–176 行
github.com
- 9CLIProxyAPI PR #7044
github.com
- 10PR 头提交里的新增分支
github.com
- 11v8.0.44 OnResult 的提前返回
github.com
- 12CLIProxyAPI PR #6705
github.com
- 13v0.2.18 gateway_forward.go 第 42–58 行
github.com
- 14
- 15
- 16
- 17gateway_upstream_response.go 第 495–515 行
github.com
- 18
- 19CLIProxyAPI v8.0.44
github.com
- 20sub2api v0.2.18
github.com
- 21codex-proxy 预发布
github.com
- 22codex2api v3.1.1
github.com
- 23status.openai.com
status.openai.com
- 24status.claude.com
status.claude.com
- 25status.cloud.google.com
status.cloud.google.com
- 26codex-reset 的 feed
codex-reset.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.