图片 2xx 带 error 仍按 n 张计费；CLIProxyAPI 的会话绑定还只在内存里
sub2api v0.2.17 遇到 200 带顶层 error 的图片响应时仍按请求里的 n 张计费，CLIProxyAPI 的会话绑定只在内存里，两张补丁都还没合。
上一期在北京 16:31 发出，到现在四家仓库都没有新版本：CLIProxyAPI 停在 v8.0.38，sub2api 停在 v0.2.17，codex-proxy 停在 v2.1.20-beta.0543eaa，codex2api 停在 v3.1.1。1234
这半小时的动静全在补丁和 dev 分支上。三条主线各回答一件事：图片的账按什么记、重启丢掉什么、dev 上那笔会带过去什么。
2xx 带着 error 回来，账还是按 n 张记
所以一张图都没出、客户端要了 4 张时，账单上记的是 4 张。
Ops 面板也发现不了。整条路径没有写上游错误事件，这条请求在面板里是成功的。5
v0.2.17
backend/internal/service/openai_images.go 第 742–800 行：第 744 行先取 parsed.N，第 793–794 行只在数到图时覆盖它。截图取自 v0.2.17 标签。#8279 把这类响应当成带内失败：计数记 0，补一条上游错误事件，
CountTowardsSLA 与非流式标记一并写上，对客户端的状态码和正文仍按上游原样返回。5判定条件是三件事同时成立：状态码 2xx、正文有顶层
error、数不到任何图片输出。8没有
error 的 2xx 不改行为，仍按 n 兜底。同一张单还加了第二个开关
images_strip_upstream_urls，默认关。开了之后，已经带 b64_json 的图片项会删掉所有值是 http(s) 链接的字段，url、native_url 这类上游私有字段一起清。5这一条是另一件事。#8279 的说明里写，有的上游回图时还附一个自己存储的链接，通常是裸 IP 的 http 地址，不鉴权就能下载。客户端默认要的是 base64，这些地址等于白送到手里。
#8279 头分支
backend/internal/service/openai_images.go 第 978–1010 行：先数图，数到 0 才去判 error 字段，命中就置 inBandFailed 并写 Ops 事件。这张单现在还是 open，
mergeable_state 为 unstable。5今晚能做的有四件。把客户端的
n 收小，虚计的张数跟 n 成正比。抓一次上游原始响应，看见 200 配顶层 error 就知道自己踩在这一类上。别指望监控替你发现，v0.2.17 不记这类失败。对账单时拿请求日志里的张数跟上游实际张数比，差额就是这一类的量。会话绑定还活在内存里
CLIProxyAPI 的会话亲和把「哪个会话归哪个凭据」记在内存里。v8.0.38 的
session_cache.go 里没有落盘代码。9进程一重启，绑定就没了。同一段对话的下一次请求可能落到另一个凭据上，上游那一侧的 prompt cache 从这里开始整段失配。
这个开关默认还关着：v8.0.38 的示例配置里
session-affinity 是 false，TTL 一个小时。10没开亲和的实例本来就不保证同一段对话落在同一凭据上，重启前后没有差别。开了的才有这个落差。
#6875 想把这份状态写进磁盘，开关叫
routing.session-affinity-persistence。默认 false，要求 session-affinity 为真，Home 模式下忽略。11文件落在
<auth-dir>/.runtime/session-affinity.cache。每 5 秒写一次，worker 停止时再写一次；写临时文件、同步、再原子替换，权限只给本人。12落盘的东西比会话别名多。还有 Guardian 的父选择历史、LCP 分组，后者带 fork 与压缩产生的血缘、环境摘要和独立的尾部指纹。11
恢复时会丢掉过期与非法记录，恢复出来的到期时间不超过当前 TTL，容量上限照旧。
写失败不影响内存里的路由，下一轮重试。读失败或版本对不上就用内存缓存，v1 的旧快照仍能读。12
#6875 头分支
sdk/cliproxy/auth/session_cache_persistence.go 第 66–100 行：第 80 行起每 5 秒一个 tick，第 97–100 行在停止信号或 tick 上各刷一次。现在改不到。v8.0.38 的示例配置里没有这个键，整包里也没有；这张单 18 个文件、+1754/−15，仍是 open。11
今晚能做的：开着会话亲和的实例，发版尽量分批，别整池一起重启。客户端如果本来就能带固定会话标识，把亲和打开才有意义，否则绑定根本不存在。
dev 上的快照继承已经落地，守卫还在评审
d5816d5e 今天上午 10:37 落进 dev，13 个文件、+1195/−11。13
它做两件事。watcher 读到一份被丢弃的文件快照，会重新读一次；文件快照被应用时，把旧的运行态搬到新对象上。13
搬的是
Status、StatusMessage、LastError、Unavailable、NextRetryAfter、Quota、cooldownRecordedSeq、模型状态和刷新退避。14搬的时候不看凭据换没换。auth 文件被整份重写——换 provider、换另一个 Codex 账号、换 Vertex 服务账号、插件存储轮换——路径派生的 ID 不变，新凭据就把旧的错误和冷却接了过去，一直不可选。14
#6853 本来就是修这个的。今天 16:38 它 rebase 到 dev 9e79552f，正文写明：搬运与重读那半已经进了 dev，这单只剩身份守卫。14
守卫是一个条件：
carryRuntime := isFileSnapshot && !credChanged && 同 provider。CredentialsChanged 也扩到了 codex 的 account_id、Vertex 的 project 与服务账号、插件 storage 的原始 JSON。四个测试分别覆盖换 provider、换 token、换 Codex 账号、删掉
account_id。改动收敛到 3 个文件、+461/−4。14发行版没有这两段。v8.0.38 的
clients.go 601 行里搜不到 rereadDiscardedFileSnapshot，conductor_lifecycle.go 里搜不到 isFileSnapshot。1516
dev 分支
internal/watcher/clients.go 第 223–255 行：先确认是同一份快照，再让自身与同路径的兄弟对象失效（第 245–249 行），最后重读这个文件（第 253 行）。跑 v8.0.38 及更早的实例不受影响，不用动。跑 dev 的实例今晚别在 auth 目录里整文件替换账号，换号走管理接口，或者等 #6853 合了再说。已经踩上的，去管理端把该凭据的冷却清掉，再让它重新参与调度。
上游读数
OpenAI 那条事件在北京 16:50 转成 resolved，最后一条更新写的是「All impacted services have now fully recovered.」。状态页现在全绿。17
它影响的是印度、日本、韩国用户，前后挂了六个半小时。
Google 那边，AI Studio 的应用封禁正在被批量恢复。论坛里带 staff 标记的 Pooja_Kapse 在 16:36 到 16:44 之间连发五条「Your app has been re-activated and should now open again in Google AI Studio.」，更早一批同形态的回复从 13:36 起就在发。18
这是应用封禁那一条线，和上一期讲的 API 项目受限不是同一件事。今天 16:36 又有一例项目受限：Free 档、
models.list 能过、generateContent 回 403 PERMISSION_DENIED，原文仍是「Your project has been denied access.」。19顺带两条同源的额度读数：一位 Google AI Pro（5TB）订阅用户的 Antigravity 显示 Starter Quota 与「ineligible for higher rate limits」；另一位的账号两天前被停用，申诉两天没有回执。2021
Codex 的重置还没落地。codex-reset 首页写「Our monitor: not landed yet」，最近一次已验证的全局重置仍是 10 月 20 日 14:33（北京），累计 56 次、banked 10 次，节奏约每两天一次。22
Tibo 的 Day 17 帖还挂着，跟帖给的是「Lands tomorrow before 10am PST」，折成北京 10 月 23 日 01:00 之前。23
今晚四件事
- 把图片客户端的
n收小；对账出现无图却计费的，先按「200 带顶层 error」这一类去核。 - 抓一次上游原始响应留底；这类失败在 v0.2.17 的 Ops 里是成功的，事后只能靠上游报文。
- 开着会话亲和的实例分批重启；没开亲和的，重启换号是常态，不必当故障追。
- 跑 dev 的实例今晚别整份替换 auth 文件，等 #6853 合并；Codex 重置落地后先看
/status的窗口行，再看本地冷却。
References
- 1CLIProxyAPI releases
github.com
- 2sub2api releases
github.com
- 3codex-proxy releases
github.com
- 4codex2api releases
github.com
- 5
- 6
- 7
- 8#8279 头分支 openai_images.go#L978-L1010
github.com
- 9CLIProxyAPI v8.0.38 session_cache.go
github.com
- 10
- 11
- 12
- 13CLIProxyAPI commit d5816d5e
github.com
- 14
- 15CLIProxyAPI v8.0.38 clients.go
github.com
- 16
- 17Elevated ChatGPT conversation and Responses API errors
status.openai.com
- 18Google AI Developers Forum 检索 re-activated
discuss.ai.google.dev
- 19403 PERMISSION_DENIED on Free tier despite API being enabled
discuss.ai.google.dev
- 20Account ineligible for higher rate limits despite active Google AI Pro
discuss.ai.google.dev
- 21Antigravity suspension false positive
discuss.ai.google.dev
- 22Codex Reset
codex-reset.com
- 23Tibo on X
x.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.