一页 HTML 403 被记成封号：Codex 抖一下，中转空转半小时
Codex 上游回的一页 HTML 403 会被本地记成凭证被拒、同一张凭证恢复后仍要等 30 分钟；本期给出三条判据与清冷却的接口，另附 sub2api 负数 max_tokens 静默 200、v8.0.48 显式档位被换成预算两条代码事实。
这一轮最该看的是 CLIProxyAPI 的 #7134。Codex 上游在边缘故障时回一页 HTML 403，中转把它当成凭证被拒，这个模型在每张凭证上冷却 30 分钟，客户端随后一直收到 503
auth_unavailable。同一张凭证其实早就恢复了。1
另外三条：sub2api 对负数
max_tokens 静默返回 200；v8.0.48 把 Antigravity Claude 5.5 的显式档位换成了数字预算；OpenCode 压缩后的检查点在 WebSocket 走 HTTP 上游时不被识别。四个仓库这一轮仍然没有新版本，也没有主干提交。
一页 HTML 403，被记成凭证拒绝
internal/runtime/executor/codex_executor_terminal.go 第 313–333 行：第 326 行 errCode := statusCode，只有配额与容量两类会被改写成 429，函数里没有任何 HTML 判断。2现象是这样的：用 Codex OAuth 凭证打单个模型，上游边缘抖一下、回了一页 HTML 403，中转侧把这一次当成凭证被拒。
接下来 30 分钟里，这个模型在这张凭证上一律不可选。池子里所有凭证往往同时中招——同一条出口、同一个边缘——客户端拿到的就是 503。
回执形状值得记住：
{"error":{"code":"auth_unavailable","message":"no auth available"}}，带一个 Retry-After，值是剩余冷却秒数。3三条判据
- 冷却正好 30 分钟，不是 429 那条按次翻倍的阶梯；
- 面板里那个号、那个模型的状态消息是一段 HTML，因为 403 原文被整段写进了
StatusMessage4； - 拿同一张凭证直接打上游，能通。
第二条里有个坑。走凭证级那条分支时，403 会被标成
payment_required，看到这个标签别先当成欠费。5代码走的是哪一步
v8.0.48 的
newCodexStatusErrWithHeadersAndCooling 只认两类错误：isCodexUsageLimitError 与 isCodexTransientCapacityError。两类都不命中时，
errCode 保持传入的状态码。403 就这样原样成为一个 403 的 statusErr。再往下，冷却的 switch 把 401、402、403 合成一个 case。没开
disable-cooling 时，它给的恢复时刻是 now.Add(30 * time.Minute)。
v8.0.48 的
sdk/cliproxy/auth/conductor_cooldown.go 第 1096–1112 行：第 1103 行 case 401, 402, 403:，第 1107 行 next := now.Add(30 * time.Minute)。6补丁给的东西
#7134 加了一条前置判断 IsCodexHTMLForbidden。它只看 403，只看正文前 64 字节，去掉 BOM、转成小写后要求以 <html 或 <!doctype html 开头，且后面紧跟分隔符。7命中就换成 502，错误体是
upstream_html_rejection，重试提示 5 秒。上游若给了更长的 Retry-After，用上游那个。关键是它不再写凭证级状态，也不进配额。补丁不刷新 token、不重启进程，也不加后台探测。
局限要写清楚：只认这一种页型。以注释开头、或者包在 JSON 里的 403，仍然走原来那条路。
单子现在是 open、非 draft、mergeable 是 clean，3 个文件 +175/−0，1 个提交，对着 dev。自动评审开单后四分钟跑完，没有 finding。1
今晚能做的四件
- 见到 503
auth_unavailable，先看Retry-After是不是整 30 分钟。 - 去面板看那个号、那个模型的状态消息。HTML 片段就是这条。
- 清掉它：
POST /v8/management/routing/cooldown/reset，body 写{"auth_index": "..."}。空值回 400，找不到回 404。8 - 别为这个打开
routing.cooldown.disable-cooling。它把全局冷却一起关掉，真 429 也不再记。9
sub2api：负数 max_tokens 被静默丢掉
OpenAI 对同样请求回 400
invalid_request_error。这是报障人给的对照，本刊没有在官方文档里找到负数取值的专门说明。影响在两头。客户端把
-1 当「不限」的老习惯会静默生效，输出长度与账单都不受控；参数写错也不会有人告诉你。
backend/internal/pkg/apicompat/chatcompletions_to_responses.go 第 58–78 行：第 69 行的条件是 maxTokens > 0，负值进不去，上限就不写进 max_output_tokens。11单子 open、2 个文件 +117/−0、mergeable 是 unstable，评论只有两条 CLA 回签。
补丁没合之前，这层校验只能自己加：反代或网关层拒掉负数，或者让客户端别再把
-1 当「不限」。v8.0.48：显式档位被换成数字预算
Antigravity 的
claude-opus-5-5-high 与 claude-sonnet-5-5-high，请求里带 thinkingLevel: "high"，到上游变成 thinkingBudget: 24576。low 变 1024，medium 变 8192。14原因在模型表。两个条目的
thinking 只有 min、max、zero_allowed、dynamic_allowed，没有 levels。
internal/registry/models/models.json 第 4086–4122 行：claude-opus-5-5-high 与 claude-sonnet-5-5-high 的 thinking 段只有四个预算字段。15档位就在这个分支里被
ConvertLevelToBudget 换掉，模式也从 level 改成 budget。17对声明了
supportsAdaptiveThinking 的模型，档位与预算不是一回事。你以为在给 high，实际给的是 24576 这个上限。#7133 目前只有报障，没补丁。报障人给了本机复现命令，也说明流式与非流式都成立，Gemini 模型不受影响。核对方法只有一个：看请求日志里最终发出的 body，别看自己发出去的那份。
短讯：压缩检查点没被识别
OpenCode 把压缩后的对话包在
<conversation-checkpoint> 里发回来。Responses 的 WebSocket 走 HTTP 上游时，这段被当成普通 user 消息追加到旧历史。旧输出里还挂着的
function_call 被带着重发，没有对应的 output，上游回 No tool output found for function call ...。18#7132 给 shouldReplaceWebsocketTranscript 加了一个判定：response.create、没有 previous_response_id、输入只有 user/developer 消息、checkpoint 标签成对且 <summary> 有序。19命中就走已有的整段替换路径。2 个文件 +396/−4，open、mergeable 是 clean。
这一轮没有版本要升
| 仓库 | 当前版本 | 发布时间（北京） |
|---|---|---|
| CLIProxyAPI | v8.0.48 | 10 月 30 日 22:37 |
| sub2api | v0.2.19 | 10 月 28 日 18:16 |
| codex-proxy | v2.1.21 | 10 月 28 日 04:48 |
| codex2api | v3.1.2 | 10 月 28 日 04:40 |
窗口内四个仓库都没有新 tag，也没有主干提交。CLIProxyAPI 的 tag、main、HEAD 是同一个提交，dev 比它多一笔，停在今天 10 点 04 分。24
sub2api 的 main 头停在 10 月 30 日 10 点 44 分。25
上游这边三处都清。OpenAI 全绿，最近一条已恢复事件是 10 月 31 日 05 点 14 分结束的搜索报错。26
Anthropic 也全绿，最近一条是 10 月 29 日凌晨的 Google Calendar 连接器故障，从 00 点 19 分到 04 点 05 分。27
Google Cloud 最新一次更新停在 10 月 28 日 08 点 38 分。28
Codex 的额度重置今天 UTC 还没发生。最近一次已验证的全局重置是 10 月 28 日 14 点 35 分，累计 61 次全局、10 次 banked，节奏约每两天一次。29
13 点 42 分有一条新帖值得存着：Codex 的负责人写「Next two days will be resets… banked」。追踪站把它记成候选，
explicit_reset_claim 是 false。3031社区：Gemini 的额度读数
临近窗口起点还有一条 11 点 59 分的：Pro 用户在 task 模式用 Argon，分析到第 17 只股票时撞了日限额。34
三条新帖都只是自述，没有官方口径。要把它们当阈值之前，先看自己账号
/v1beta/models 返回里的 quotaInfo。未闭合
#7134 会不会被合、合了要等哪个 tag；#8460 会不会被接，/v1/responses 上的负数上限有没有同样问题（本刊没核）。#7133 什么时候给两个条目补上 levels。上游那句「未来两天」会在哪一天兑成能观测到的重置。References
- 1CLIProxyAPI PR #7134
github.com
- 2
- 3v8.0.48 auth/errors.go 第 233–242 行
github.com
- 4
- 5
- 6
- 7PR #7134 全量补丁
patch-diff.githubusercontent.com
- 8
- 9v8.0.48 config.example.yaml 第 220–227 行
github.com
- 10sub2api issue #8458
github.com
- 11
- 12sub2api PR #8460
github.com
- 13PR #8460 全量补丁
patch-diff.githubusercontent.com
- 14CLIProxyAPI issue #7133
github.com
- 15v8.0.48 models.json 第 4086–4122 行
github.com
- 16v8.0.48 thinking/convert.go 第 162–183 行
github.com
- 17v8.0.48 thinking/validate.go 第 86–101 行
github.com
- 18CLIProxyAPI PR #7132
github.com
- 19PR #7132 全量补丁
patch-diff.githubusercontent.com
- 20CLIProxyAPI Releases
github.com
- 21sub2api Releases
github.com
- 22codex-proxy Releases
github.com
- 23codex2api Releases
github.com
- 24CLIProxyAPI dev 提交时间轴
github.com
- 25sub2api main 提交时间轴
github.com
- 26status.openai.com summary
status.openai.com
- 27status.anthropic.com incidents
status.anthropic.com
- 28Google Cloud Status incidents
status.cloud.google.com
- 29codex-reset.com
codex-reset.com
- 30codex-reset.com feed
codex-reset.com
- 31
- 32r/GeminiAI Argon 不可用
reddit.com
- 33r/GeminiAI flash 吃额度
reddit.com
- 34r/GeminiAI 撞日限额
reddit.com
- 35r/GeminiAI 撞周限额
reddit.com
- 36r/GeminiAI 不扣额度
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.