同一会话，两台副本各钉一个号：v8.0.42 的粘性只在进程内
上游把额度重置押在 PST 午夜前，同时本刊核到 v8.0.42 的会话粘性只在进程内：多副本下同一会话会散到多个账号，prompt 缓存与思考签名一起作废，另有一条 commentary 回放丢块。
北京时间 11:32 到 12:25 这个窗口，四个仓库都没有新版本。CLIProxyAPI 停在 v8.0.42，sub2api 停在 v0.2.18，codex-proxy 停在 v2.1.20，codex2api 停在 v3.1.1。
主干也没有新提交，窗口内没有新开或新合并的条目。今天值得看的，一条在上游，一条在本机。
上游那侧：11:39 与 11:40，Tibo 连发两条，第二条只有一句「By midnight PST」。这是本轮唯一新增的额度信号。
本机这侧：v8.0.42 的会话粘性默认关着，打开也只活在当前进程里。多开一台副本，同一个会话就会被钉到不同账号上，上一轮的 prompt 缓存与思考签名一起作废。
午夜前（PST）是今天下午几点
「PST」这个写法本身有歧义。按字面（UTC−8）算，午夜是北京时间今天 16:00；美国西岸现在实际在夏令时（UTC−7），则是 15:00。两个数都落在今天下午。
追踪站已经把它记成待验证的信号。codex-reset 的 feed 把最新帖时刻更到北京时间 11:40:04，这条事件的状态是 pending；首页的预测栏也直接引用了这句「Official signal: By midnight PST」。34
帖子里没有说已经放完，两家站也都还挂着 pending。落地要等它们把状态改成已验证。
两家的累计口径仍然对不上，引用时按站分开写。codex-reset 记 57 次已验证重置、10 次已存、节奏约每两天，最近一次已验证的全局重置在北京时间 10-23 凌晨 01:10。
opentherank 记 66 次、中位间隔 3 天、最长 68 天，最近一次记的是北京时间 10-24 凌晨 01:00，并注明「按公告落地、Tibo 未单独确认」。5
会话粘性：默认关，开了也只活在本进程
额度回来之后，缓存能不能立刻接上，取决于这一处。
config.example.yaml 第 156–186 行：第 162 行 session-affinity: false，第 175 行 session-affinity-subagents: true，第 174 与 181 行都写明「affinity 关掉时这一项被忽略」。6默认配置下，每一轮都交给轮询或加权选择器，同一个会话可以一轮一个号。子代理继承那条默认 true，生效要看母开关，第一处容易看错的就是这里。
打开之后，选择器才会被包一层。7
粘性本身是一张进程内的表：map 加读写锁，带 TTL 与容量上限。进程退出，这张表就跟着没了。8
session_cache.go 第 31–43 行：entries 是 map[string]sessionEntry，mu 是 sync.RWMutex，结构体里没有任何持久化字段。8键的拼法是
provider::会话ID::模型。命中就直接用绑定过的那个号；没命中才交给底层选择器挑一个，再把这个结果写回表。9
selector.go 第 1166 行拼键，第 1199 行查表，第 1203 行打 cache hit，第 1208 行才是落选之后的重新挑选。9结论因此很直接：N 台副本就是 N 张互不相通的表。同一会话在 A 机上钉了 1 号，到 B 机第一次进来会重新挑，可能挑到 3 号。
散掉的代价分两层。一层是 prompt 缓存：前缀一个字节没变，换了账号就是全价重算。
另一层是思考块：上一轮由 1 号签发的 thinking，下一轮带着 1 号的签名发给 3 号。
第二层本刊只核到一半。签名清洗只到 provider 这一层，Claude 的签名会留给 Claude 上游，认不出是哪个账号签的。10
能不能过，由上游判。PR 作者把这类失败写成
end_user_binding_mismatch；本刊在 v8.0.42 整包里搜不到这个字符串，它来自上游回执，属于上游的措辞。客户端不带会话头呢？那就退回内容哈希。
computeSessionHash 用 system 与首条用户消息算 FNV-1a，同一段对话在各台机器上算出的 ID 相同，这一层跨机一致。11缺口在更前面。没有显式会话 ID 时，选择器先走「最长公共前缀」匹配器，那个匹配器只在本进程里。
会话头缺席时走的是另一条路，落点仍然只在本机。
PR #6954 能补什么、补不了什么
今天凌晨 01:43 开出的 #6954 正是为这件事：九文件、五笔提交、open、非 draft、mergeable clean、base 是 dev。12
它的做法是把选择改成无状态：对会话标识与每个凭证 ID 一起做 SHA-256，取分数最高的那个。每台副本看到的凭证集合相同，算出的第一名就相同，副本之间不用互相通信。
边界写在 PR 说明里，五条要记住：
fill-first不参与，它本来就是确定性的。- Home 模式不参与：
home.enabled为真时派发走 Home，本地选择器不被调用。 - Codex 的 websocket 请求只在「开了 websocket 的凭证」里排。一个会话既走 ws 又走 HTTP 时，仍可能用两个号。
session-affinity-ttl只用来让缓存条目过期，不再决定路由；session-affinity-rebind-on直接失效。- 客户端可以枚举会话 ID：试到某个 ID 把自己的目标号排到第一，大约 N 次里成一次。
它现在还是一张 open 的 PR。仓库的自动评审那次没跑完，状态是 failed；人工评审也还没有。
另一处「历史少一段」：commentary 回放时整块没了
第二条与额度无关，但同属「上一轮记不住」。
这个块没有签名。测试里直接断言「commentary block carries no signature」，因为按设计，加密内容只属于 reasoning 项，不属于这段开场白。
回放时问题出现。
appendReasoningContent 拿到空签名，CodexReplaySignatureForTarget 返回 false，默认分支直接 return，整段文本不进请求体。14
codex_claude_request.go 第 173–196 行：第 185–190 行是那个分支，默认翻译丢弃；compat 模式下写成 encrypted_content: ""，文本同样丢。14后果是：Claude 格式客户端打 Codex 上游这条路上，每来一轮「commentary → 工具调用 → 工具结果」，模型就看不到自己上一轮的开场说明。账照记，行为会漂。
报障单 #6966 在北京时间 06:52 开出、06:56 自己关成 not planned，零回复，属于那批十六张同批关闭的单。15
这一条只能等上游改。眼下能做的，是把这一轮任务的关键上下文写进提示或文件，别指望历史里那句开场白。
上游与社区
三家状态页这一窗口都是绿的。OpenAI 全系统正常、零降级组件，最近一条事件是 10-24 早上恢复的 CIMD 连接异常。16
Anthropic 最近一条是 Fable 5 与 5.1 的错误升高，10-24 13:53（北京）恢复。17
Google Cloud 仍是八条历史事件，最新一条的最后更新停在 10-23 凌晨（北京）。18
社区这一窗口没有额度或封号相关的实质新帖。OpenAI 开发者社区 Codex 分区最新仍是 10-25 03:34（北京）那条「100% 掉到 4%」的账单帖。19
Google 官方论坛窗口内两条新帖分别是界面问题与模型体验，与中转运维无关；Reddit 三个板块的新帖是使用体验与作品分享。
今天能做的三件事
- 先确认 affinity 到底开没开：翻自己那份配置的
routing.session-affinity。默认值 false，等于每轮换号，session-affinity-subagents写了 true 也不生效。 - 多副本先看负载均衡：按会话头或 API key 做粘性，才有机会把同一会话留在同一台；否则打开 affinity 也只是每台各自钉一个号，最多散到 N 个。
- 重置落地后手动清一次：上游的额度重置不会自动清掉本地的凭证级冷却，成功请求也会保留未到期的
credential_quota。20要提前恢复就逐个调POST /v8/management/routing/cooldown/reset，body 传{"auth_index": "..."}。21
References
- 1
- 2Tibo：By midnight PST
x.com
- 3codex-reset 的 feed
codex-reset.com
- 4codex-reset 首页
codex-reset.com
- 5opentherank：Codex reset
opentherank.com
- 6v8.0.42 config.example.yaml 第 156–186 行
github.com
- 7v8.0.42 service_config.go 第 105–121 行
github.com
- 8v8.0.42 session_cache.go 第 31–43 行
github.com
- 9v8.0.42 selector.go 第 1166、1199–1204 行
github.com
- 10
- 11v8.0.42 selector.go 第 2058–2070 行
github.com
- 12PR #6954
github.com
- 13提交 376015c3
github.com
- 14
- 15issue #6966
github.com
- 16OpenAI 状态页
status.openai.com
- 17Anthropic 状态页
status.anthropic.com
- 18Google Cloud 状态页
status.cloud.google.com
- 19OpenAI 开发者社区 Codex 分区
community.openai.com
- 20
- 21v8.0.42 管理端路由表
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.