10/19 夜间速报：同一张内联图写了两份，DeepSeek 的 48 MiB 闸在 24 MiB 入站就落下
这一小时四仓无新版本：sub2api 把 DeepSeek 的 Base64 内联图同时写进 image_url 与 url，24 MiB 入站就撞上上游 48 MiB；CLIProxyAPI 两笔修复落进 dev 却还没发版，上期那条孤儿 tool call 有了只删不补的补丁。
这一期覆盖北京时间 17:33 到 18:33，约一小时。四个仓库都没有新版本，新增的是三件事：一张把内联图写两份的 sub2api 新单、两笔落进 CLIProxyAPI dev 的修复、上期那条孤儿工具调用的补丁。
给一句结论：今晚不跑 DeepSeek 的 Responses 内联图，也不在 v8.0.33 上把 Codex Desktop 挂到 Kimi 或 Meta 的 OAuth 路线，这三件事都碰不到你的实例。
一张内联图被写两份，48 MiB 的闸在 24 MiB 入站就落下
sub2api 的 #8222 在 17:40 开出，作者 mafuchao99，目前 open、0 评论、没有补丁。1
环境很普通：DeepSeek 官方 API、模型
deepseek-flash、Responses 协议、一张 Base64 内联图。问题出在适配层。v0.2.17 的
aliasDeepSeekResponsesImagePart 会给同一个图片 part 同时写 image_url 与 url，两个字段存的是同一份完整 data URL。2
if 只差字段名，赋值完全相同：一次请求里，同一张图占了两份字节。原文触发面比平台标记宽。
targetsDeepSeekAPIHost 只要上游主机是 api.deepseek.com 就命中，openai 平台里把 base_url 指到 DeepSeek 的映射账号同样走进这条改写。3改写发生在转发前（
openai_gateway_forward.go 第 1407 行）和透传路径（openai_gateway_passthrough.go 第 613 行），input 的 content 与 tool output 里的图都会走到。报障人给了三组数字：
- 一张 20,976,520 字节的 PNG，入站 JSON 27,968,948 字节，实际 Forward 出口 55,937,689 字节，约 53.35 MiB。
- 入站 23 MiB 与 24 MiB 两档都过，出站 48,234,289 与 50,331,441，后者离 48 MiB 只剩 207 字节。
- 入站 25,167,055 字节时出站 50,332,672，回 413
Request payload is too large。
同一把官方 Key、同一张图、只改字段：只带
image_url 是 200，两个都带是 413，只留 url 是 400，报 input_image must have image_url or file_id。DeepSeek 官方文档写的是 48 MiB 请求体上限，Base64 计入；单图另有 32 MiB 上限，外链图 URL 不超过 8192 字符。4
于是有一条今晚就能用的口算：走 Responses 的内联图，把整个入站请求压在 24 MiB 以内。过了这条线，出站就贴近甚至越过 48 MiB。
今晚能做的三件事，各有代价：
- 压图。最直接，代价是细节；原始图要压到约 18 MiB 以下才稳妥，因为 Base64 占 4/3、再乘两份。
- 换外链 URL。它在请求里只占几 KB，重复写一份也不胀；代价是上游要在 60 秒内拉完，单图不超 32 MiB。
- 拆请求，一张图一个请求。代价是上下文被切碎。
只留
url 那条路会从 413 变成 400，别把它当更省字节的写法。调大前置 Nginx 的 client_max_body_size 也没用，卡住的是上游。CLIProxyAPI：两笔修复落进 dev，v8.0.33 上今晚还踩得到
17:40 与 18:06，dev 上落了两笔提交，各自关掉一张单。
先说 18:06:33 的
8df4e42a，关 #6769：Kimi 与 Meta 的 OAuth 路线被 Codex 目录虚报成 responses lite 加 code mode。5报障环境是 v8.0.33 加 Codex Desktop 0.163.0-alpha.10.2。
目录对
kimi-k3 与 muse-wonder-1.0 同时给出 tool_mode: code_mode_only、use_responses_lite: true、supports_reasoning_effort_updates: true。后果是两端各回一个 400。Meta 那边是
input[0] did not match any supported type，客户端发了 additional_tools 输入项；Kimi 那边是 Unsupported custom tool: 'exec'。把声明挪回顶层
tools、或改成普通 function，同一个模型立刻 200。根因在目录归一化。v8.0.33 的
nullCodexClientRequiredOptions 只清 apply_patch_tool_type、upgrade、availability_nux，这三个字段原样留着。
另一笔是 17:40:36 的
45ccd9c3，关 #6768——就是下午那期头条里那句「开了 force-model-prefix，xAI 图片模型一律 400」。改法是把客户端请求的模型名传进图片 handler，用登记过的 xAI 模型解析路由，并允许自定义 xAI 凭证前缀。7
两条都只在 dev。v8.0.33 的 tag 停在 10-18，main 也停在 10-18 21:05，升级拿不到。8
上期那条孤儿 tool call，补丁只做删除
上期结尾登记过 #6771：
codex-api-key 指到 DeepSeek 的 /v1/responses，历史里 orphan function_call 没有配对的 output，上游回 400 No tool output found for tool call。18:04 有人给 #6772 提了补丁，base dev，5 个文件 +167/−1，一笔提交，作者 drakeo338。9
判定很朴素：先扫一遍
input，收集所有 function_call_output 与 custom_tool_call_output 的 call_id；再扫第二遍，function_call 与 custom_tool_call 里 call_id 非空、又不在集合中的，直接丢掉。
call_id 为空的原样留下，只删「有 id 却没回音」的那类。原文调用点也收得很窄：只在来源格式是 OpenAI Responses 时生效，插在
codex_executor_request.go 的 cacheHelper 里、SanitizeCodexInputItemIDs 之前。代价同样写在代码里。它删调用，不补一个伪造的 output；模型的上下文里就少了一次「我曾发起过这个工具」，严格的模型可能因此重复发起同一个调用。
PR 目前 open，自动评审留了一条未解决的发现，维护者还没有表态。
短条：异步生图的下载策略跟着同步端点对齐
sub2api 的 #8223 在 17:51 开出，作者是维护者本人，2 个文件 +386/−11。10
改的是异步生图完成后转存结果的下载器：目标主机是本机、回环、私网、链路本地或 CGNAT 地址就不下载，重定向每一跳同样校验。
响应声明的
Content-Type 与字节嗅探都不是图片时，任务直接判失败；此前会按 png 存一个无效文件并标完成。明天的行为变化就这两条：上游图片 URL 指向内网、或回 200 但内容不是图的异步任务，会从「成功」变成「失败」。
b64_json 与 data: URL 两条路不受影响。四仓状态与上游
版本没动：sub2api v0.2.17、CLIProxyAPI v8.0.33、codex-proxy 稳定版 v2.1.18（预发布 v2.1.19-beta.f824033）、codex2api v3.1.1。
主干也没动：sub2api 的 main 停在 10-16 12:42，codex2api 停在 10-17 05:35，codex-proxy 的 main 停在 10-16 01:16、dev 停在 10-18 18:46。CLIProxyAPI 的 main 停在 10-18 21:05，dev 头是 18:06 那笔。
上游全绿：OpenAI 状态页 All Systems Operational、活动事件 0；Anthropic 全绿、今天无事件；Google Cloud 7 条事件，最近仍停在 10-08 至 10-09 的 Cloud Storage 上传。11
Codex 额度侧：今天 UTC 仍未重置，最近一次已验证的全局重置是北京时间 10-18 04:41，约 38 小时前；累计 55 次全局、10 次 banked。12 opentherank 记 63 次、中位间隔约 3 天。13
未收与未闭合
sub2api #8113 在 17:45 有一条作者催评审，只有一句 follow-up，没有新信息。14
r/OpenAI 18:16 那条问 Google Drive 写入限制是不是收紧了，是用户自述自己的 Codex 自动化被挡，没有版本也没有日志。15
r/GeminiAI 两条（gemini pro 3.1 变差、一张新模型截图）属模型体感，按排除规则不收。OpenAI 开发者社区 18:05 那条讲 Computer Use 把 macOS 登录钥匙串锁住，是客户端问题，与中转运维无关。
三条待跟：#8222 会不会按「保留
image_url、删掉重复 url」修；#6769 与 #6768 的修复进哪一版；#6772 那条自动评审的发现会不会让作者改掉「删调用」的做法。References
- 1sub2api issue #8222
github.com
- 2
- 3targetsDeepSeekAPIHost 第 421–443 行
github.com
- 4DeepSeek Vision 文档
api-docs.deepseek.com
- 5CLIProxyAPI issue #6769
github.com
- 6dev 分支 models.go 第 561–578 行
github.com
- 7commit 45ccd9c3
github.com
- 8CLIProxyAPI 发行版列表
github.com
- 9PR #6772
github.com
- 10PR #8223
github.com
- 11OpenAI 状态页
status.openai.com
- 12codex-reset.com
codex-reset.com
- 13opentherank
opentherank.com
- 14PR #8113 评论
github.com
- 15r/OpenAI 帖子
reddit.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.