零发版：CPA 五笔修复停在 dev、sub2api 默认导出模型改 gpt-5.6-sol、API-key 连通性测试误报欠费
这四个仓库一夜都没发新版，但该动手的地方有三处：sub2api 主干把导出的默认模型换成 gpt-5.6-sol、CLIProxyAPI 五笔修复全停在 dev，以及一条会把好 key 报成欠费的连通性测试。
到北京时间今天 10:20 为止，这一夜四个仓库都没有发新版本。CLIProxyAPI 停在 11 月 5 日 02:03 的 v8.0.551，sub2api 停在 10 月 28 日 18:16 的 v0.2.192，codex-proxy 与 codex2api 分别停在 11 月 3 日 19:35 的 v2.1.233和 11 月 4 日 10:22 的 v3.1.34。
没有新版本，不等于没有要动手的地方。sub2api 主干在 09:15 与 09:34 进了两笔：一笔给网关加资源上限，一笔把 CC Switch 导出的默认模型改掉56。两笔都还没进发行版，v0.2.19 上一切照旧——所以先看清，再决定今天要不要临时改。
CLIProxyAPI 这边，08:59 到 09:53 之间 dev 连落五笔，把 #7254、#7255 两条报障修了进去，v8.0.55 却一条都不含7。另有两条新报障值得当天处置：API-key 连通性测试会给测试请求套上 Claude Code 身份，在促销额度账号上误报欠费8；OAuth 账号走图片生成时 complexity 被静默丢掉9。
一、sub2api：默认导出模型换成 gpt-5.6-sol，还没发版
09:34 合进主干的那笔只有一行。
frontend/src/utils/ccswitchImport.ts 第 3 行，OPENAI_CC_SWITCH_CODEX_MODEL 从 'gpt-5.5' 改成 'gpt-5.6-sol'10，提交说明写的是「GPT-5.5 已不提供服务，默认导出模型改为 GPT5.6-SOL」6。手上的 v0.2.19 同一行仍是
'gpt-5.5'11，所以现在导出行为没变。变的是「下次发版之后新导出的那份配置」。
frontend/src/utils/ccswitchImport.ts 第 1–4 行，提交 8e92c892（FeeiCN，11 月 5 日 09:34）的完整改动就是第 3 行这一处6这一行为什么值得看一眼：官方页写得很清楚，用 ChatGPT 登录的 Codex 自 10 月 14 日起不再服务 gpt-5.5，API key 认证的会话不受影响，并要求把 gpt-5.5 换成本账号可用的模型12。导出给用户的配置如果还写着 gpt-5.5，那份配置在他的号上跑不起来。
sub2api 自己的默认模型清单没动。v0.2.19 的
DefaultModels 首项已是 gpt-5.6-sol，但清单里仍然留着 gpt-5.5 一行，gpt-6.1-sol 与 gpt-6-luna 也都在列表里13。所以「清单里能选」不等于「上游还收」。今天能做的一步：把 gpt-5.5 从各分组的模型白名单里摘掉，或者至少确认没有任何地方把它写成默认。等下一次发版再核导出默认值。
二、sub2api：六个资源上限键，和一种新的 503
| 键 | 默认值 | 作用 |
|---|---|---|
request_body_memory_budget_bytes | 1073741824（1 GiB） | 请求体缓冲总预算，0 表示关闭 |
request_body_read_timeout_seconds | 120 | 读请求体超时，取值 0–3600 |
downstream_write_timeout_seconds | 120 | 写下游超时，取值 0–3600 |
sse_queue_max_bytes | 8388608（8 MiB） | SSE 队列字节预算 |
sse_event_max_bytes | 0 | 单事件字节上限，0 表示继承 max_line_size |
sse_event_max_lines | 4096 | 单事件非空行数上限 |
这六个键在启动校验里逐条检查，填错直接起不来：负预算报
must be non-negative，超时不在 0–3600 之间也报错16。新出现的行为是这条 503：请求体缓冲预算耗尽时，网关回 503、带
Retry-After: 1、正文是「Request body buffering capacity is exhausted; retry later」17。
backend/internal/server/middleware/request_body_memory.go 第 14–35 行；第 28 行只认预算类错误，第 31 行写 Retry-After: 1，第 32 行是那句 503 正文17运维含义很直接：以前面板上的 503 多半是上游过载；从这一版起，同一个 503 也可能是本机内存预算打满。区分办法就是正文那句话——带上它，就是自己这边的容量问题，不是上游，也不是 key 的问题，等一两秒再试即可。
另有一个数字会咬人。示例配置里
max_line_size 从 41943040 改成 524288000，与代码里既有的 500 MB 默认值对齐18。一直照抄旧示例的部署，实际跑的是 40 MB 的单行上限；经常转发长工具输出的中转，这可能就是偶尔截断的来源。三、CLIProxyAPI：五笔全在 dev，v8.0.55 一条不含
08:59 到 09:53 之间 dev 连落五笔，逐笔如下，全部在主干、全部未发版：
- 08:59 gpt-image-2.6 三个模型进内置模型表，09:39 由 PR #7262 合并19。dev 的
model_definitions.go第 15–17 行是 gpt-image-2.6-flare、-sunburst 与 gpt-image-2.620；v8.0.55 同一文件里这三个名字一个都没有21。 - 09:42 #7254：Chat Completions 侧把客户端的 tool_search 声明桥成普通函数22。
- 09:43 #7255：Claude 翻译层按类型处理 thinking 内容块23。
- 09:51 一笔 13 文件的修复：Antigravity 流式终止块保留客户端可见用量、稀疏 refusal 的身份字段、Home 流错误日志24。
- 09:53 合并 PR #7242：把流中段的安全拦截归成 400 并落错误日志25。
#7254 的改法对运维有直接影响。Chat Completions 协议本身没有 tool_search，这条路以前会把客户端的 tool_search 声明整块丢掉；现在声明被桥成普通函数发下去，客户端执行完搜索，回程的调用再还原成 tool_search_call 项。
internal/translator/openai/openai/responses/openai_openai-responses_tool_search.go 第 12–35 行，提交 8c9a7851（11 月 5 日 09:42）；v8.0.55 里没有这个文件22#7255 解决的是另一条。流式响应里
delta.content 是「带类型的数组」时，旧代码用 .String() 取，取出来的不是文本；v8.0.55 第 286 行现在还是这么写的26。非流式那一侧同样会丢 thinking 块或排错顺序23。同窗口还有一条没落地的：#7259 的 PR #7261 仍 open，且与主干冲突（
mergeable_state 为 dirty）29，实际合进去的是另起一笔的 #7262。别把 #7261 算进「下个版本会带上」。四、sub2api #8525：连通性测试冒充 Claude Code，促销额度账号误报欠费
现象有三组对照。同一个 Anthropic API-key，标准
/v1/messages 回 200；加 anthropic-beta: claude-code-20250219 后回 400 说余额过低；只在 system 里塞一句 You are Claude Code, Anthropic's official CLI for Claude. 也会 4008。触发条件是组织用的是促销 API 额度。原因在后端测试服务里。拼测试请求时按 Claude Code 的样子来：system 写
claudeCodeSystemPrompt，还带一个生成的 session 串30；发请求前把 claude.DefaultHeaders() 整套套上，API-key 账号再带 APIKeyBetaHeader31。上游据此把它当 Claude Code 会话，走了另一套额度判定。
backend/internal/service/account_test_service.go 第 577–598 行；第 582 行遍历 claude.DefaultHeaders()，第 591 行给 API-key 账号写 APIKeyBetaHeader，第 598 行才轮到账号级头覆盖31这解释了一件最容易误判的事：测试报欠费，不代表 key 废了，也不代表额度真的没了。先做个最土的验证——直打
/v1/messages，只带 x-api-key 与 anthropic-version，回 200 就说明 key 是好的，问题在探针。还有一层要知道：真实转发也带 Claude Code 身份。转发链路会把 OpenCode 那句身份改写成
claudeCodeSystemPrompt32，API-key 账号走 APIKeyBetaHeader33。所以「测试通过」也不等于「真实转发一定通过」，两边不是同一套形状。补丁方面：#8527 仍 open，
mergeable_state 是 unstable。改法是 API-key 账号只发标准探针（不带 system、不带 UA、不带 anthropic-beta），OAuth 账号保留原探针34。报障人自己在 09:51 补了一条独立验证：同一份本地改动部署后，原先失败的账号在后台 Test Connection 里通过，另有四条普通转发（两非流式、两流式）也通过8。这是报障人的自测，不是官方承诺。在合进来之前，Anthropic API-key 账号的连通性测试结果只当参考；要判活，用上面那条直打。
五、sub2api #8526：OAuth 账号的图片请求会丢 complexity
同一个接口，两条路径行为不同。API-key 账号的
POST /v1/images/generations 保留 complexity（low / medium / high），OAuth 账号这条会静默丢掉，v0.2.19 与当前主干都复现9。代码落在图片请求的重建上。工具模板是
{"type":"image_generation","action":"","model":""}，之后按一份固定名单逐个补字段——size、quality、background、output_format、moderation、style，n 另按条件补35。complexity 不在名单里，所以它只能靠「原样转发」活下来，一旦走重建路径就没了。
backend/internal/service/openai_images_responses.go 第 400–424 行；字段靠 412–417 行这份名单逐个写回，白名单外的字段不会出现在请求里35影响不止画质。按报障人引用的 OpenAI 文档，两个 2.6 模型支持三档 complexity，省略时按 high 出图9。也就是说你设 low 想省时间省钱，实际可能按 high 出。这是文档口径，账单上的差异建议自己拿一张图核一次再下结论。
处置：图片生成先走 API-key 账号，OAuth 账号这条等修。
六、上游：那条事故已经结了，重置口径两家对不上
OpenAI 状态页上，北京时间 06:38 开始的「付费 ChatGPT 套餐错误率升高」，08:32 标为 resolved，影响级别 minor36。整体状态已回到 All Systems Operational，没有组件级降级。
Anthropic 最新一条事故仍是 10 月 28 日那条 Google Calendar 连接器报错37；Google Cloud 那边查不到本窗口的新事故，最新一条仍是 10 月 20 日的多产品事件38。也就是说，上面两条报障都不是上游挂了引起的。
重置口径仍然两家各说各的。codex-reset 首页写：今天还没有重置，最近一次已验证的全局重置在 8 天前（10 月 28 日 6:35 UTC），累计 61 次全局重置、10 张 banked、节奏约每 2 天一次39。opentherank 写：自 2025 年 9 月以来 71 次重置、中位间隔 2.9 天、最长等待 68 天，页面标注更新于 11 月 1 日40。
两家的累计数与「最近一次」都对不上，引用时带上各自标签。另外提醒一句：codex-reset 的 feed 里最新那条是 10:16 的闲聊帖，
signal.active 仍是 false、最近一条明确承诺停在 10 月 22 日41，别把日常帖当重置预告。七、窗口内还有三条，先记着
CLIProxyAPI #7263（10:18 报）：Antigravity 的 gemini-4-argon-high 连续两天反复
unexpected EOF，抓到的上游响应里有半截 thought: true 块、没有终止 finishReason。报障人自己说明 CPA 已正确回成 response.failed，所以这不是「假成功」，而是想知道断在哪里、能不能加诊断或安全缓解42。目前没有对应补丁。sub2api #8524（08:08 报）在讨论 overload 与「一台机器上多个号」43。回复里的两个实测值得记住：一机一号也会 overload；有人把新 free 号升成 pro 之后就没再出现过载。拆机器不一定是首选，先看号本身。
#8528（10:15 报）说
/api/v1/usage/dashboard/api-keys-usage 加载很慢，目前只有一句描述44，先记着。今晚要动手的就三件
把 gpt-5.5 从白名单与默认值里清掉；给 Anthropic API-key 加一条不带 beta 头的直打验证；图片生成绕开 OAuth 账号。其余等版本。
References
- 1CLIProxyAPI Releases
github.com
- 2sub2api Releases
github.com
- 3codex-proxy Releases
github.com
- 4codex2api Releases
github.com
- 5sub2api 503617a8
github.com
- 6sub2api 8e92c892
github.com
- 7CLIProxyAPI dev 提交记录
github.com
- 8sub2api #8525
github.com
- 9sub2api #8526
github.com
- 10sub2api PR #8495
github.com
- 11ccswitchImport.ts @ v0.2.19
github.com
- 12Codex models：GPT-5.5 retirement
learn.chatgpt.com
- 13openai/constants.go @ v0.2.19
github.com
- 14sub2api PR #8484
github.com
- 15config.go 默认值 @ main
github.com
- 16config.go Validate @ main
github.com
- 17request_body_memory.go @ main
github.com
- 18config.example.yaml @ main
github.com
- 19CLIProxyAPI PR #7262
github.com
- 20model_definitions.go @ dev
github.com
- 21model_definitions.go @ v8.0.55
github.com
- 22CLIProxyAPI 8c9a7851
github.com
- 23CLIProxyAPI 6044c5d1
github.com
- 24CLIProxyAPI be691624
github.com
- 25CLIProxyAPI PR #7242
github.com
- 26openai_claude_response.go @ v8.0.55
github.com
- 27CLIProxyAPI #7254
github.com
- 28CLIProxyAPI #7255
github.com
- 29CLIProxyAPI PR #7261
github.com
- 30account_test_service.go @ v0.2.19
github.com
- 31account_test_service.go 请求头 @ v0.2.19
github.com
- 32gateway_claude_oauth_body.go @ v0.2.19
github.com
- 33gateway_upstream_request.go @ v0.2.19
github.com
- 34sub2api PR #8527
github.com
- 35openai_images_responses.go @ main
github.com
- 36OpenAI Status：incident 01M6MBCX427A7113A3T4FJ1N6Y
status.openai.com
- 37Claude Status：phg1y2yh07n2
status.claude.com
- 38Google Cloud Status：Xs2XTHzAVC9YnafnPyzj
status.cloud.google.com
- 39codex-reset 首页
codex-reset.com
- 40opentherank：Codex reset
opentherank.com
- 41codex-reset feed
codex-reset.com
- 42CLIProxyAPI #7263
github.com
- 43sub2api #8524
github.com
- 44sub2api #8528
github.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.