要 2K 回来 1254：中转没改参数，账按实测像素定档
sub2api 的 ChatGPT OAuth 出图路径不改造请求里的尺寸，但会按回来的真实像素定档收钱：要 2K 可能只回 1254，账按 2K 走。
这一小时（北京时间 17:02–17:58）四个仓库都没有发版：sub2api 仍是 v0.2.19，CLIProxyAPI 仍是 v8.0.49，codex-proxy 停在 v2.1.21，codex2api 停在 v3.1.2。12
没有新版本不等于没有可动手的事。这一小时里最值得看的是出图：用户要 2K，回来 1254×1254；要 medium，回来 low。中转没有丢这些参数，它把真实像素量出来，并按实测像素定档收钱。
先说结论
sub2api 在 ChatGPT OAuth 账号上走原生出图路径时，
size 和 quality 会被原样放进请求，本地不做换算。上游回什么尺寸，它就用图片字节量出什么尺寸，并以这个尺寸作回执与计费档位的依据。所以「要 2048 回来 1254」既可能是上游按自己能力钳制，也可能是这个端点只认自己的档位表。现有公开证据还不能区分这两者，报障单本身也是这么写的，别急着把账算在上游或中转任何一方头上。
真正确定的是钱的走向：你按请求档位卖出的价，结算时用的是实测档位。
| 路径 | 是否走这条 | 依据 |
|---|---|---|
| ChatGPT OAuth 账号 + 6 个直连图片模型 | 走 | 白名单之外才回落到 Responses 路径 3 |
| 同一账号、白名单外的图片模型 | 不走 | 走 buildOpenAIImagesResponsesRequest 4 |
| OpenAI 平台 API Key 账号 | 不受影响 | 请求体原样转给官方 API，未走这条归一 5 |
请求确实没有被本地改写
直连白名单只有六个名字：
gpt-image-1.5、gpt-image-2、gpt-image-2.5-flare、gpt-image-2.5-sunburst，以及后两者带 -2026-09-08 的变体。命中之后，代码逐个字段往 payload 里塞。塞的时候只做一件事：值为空就跳过。七个字段都在这个循环里，
size 与 quality 也在其中，没有任何换算或降档。
openai_images_direct.go 第 56–88 行：size 与 quality 与其余五个字段同在一个原样透传的循环里，值非空就写入。6这条很重要，因为运维第一反应往往是「中转偷偷把 2048 改成了 auto」。在这一版里不是，参数是带着请求过去的。
回来的尺寸是量出来的，账按它定档
回执不是抄上游的字符串。代码把返回的 base64 解码，读 PNG、WebP、JPEG 的文件头，拿到真实宽高。
压缩包里那句注释写得很直白，也是本期最硬的一处证据：
ChatGPT OAuth can normalize requested controls to "auto". The final image bytes are authoritative for response metadata and tier billing.
翻成运维语言：OAuth 会把请求里的控制项归一成 auto，并以图片字节为准。 回执和档位计费都跟着字节走。
openai_image_dimensions.go 第 78–92 行：按字节量出真实尺寸写回结果项，注释明写最终图片字节是回执元数据与档位计费的权威。该页这次没有行段高亮，正文可完整阅读。7档位怎么划，钱往哪边走
计费档只有 1K、2K、4K 三格。显式的
1k/2k/4k 各归各的；2048x2048 与 2048x1152 记 2K；3840x2160 与 2160x3840 记 4K。其余尺寸按最长边判：不超过 1024 是 1K，不超过 2048 是 2K，再大就是 4K。
image_billing_size.go 第 28–60 行：最长边 ≤1024 记 1K、≤2048 记 2K、更大记 4K，这就是 1254 与 1672 都落进 2K 的原因。9选档的顺序是关键：先看输出档，输出档缺失才回落请求档，两者都没有按 2K 兜底。 多张图时取其中最高的那一档。10
于是会出现两个方向的错账。
请求 3840×2160、实际回 1672×941，最长边 1672，落 2K。你按 4K 卖出去的这一单，结算按 2K。默认价里 2K 是基准的 1.5 倍、4K 是 2 倍，差价就在这一档里。11
反过来，请求 1024×1024、实际回 1254×1254，最长边 1254，也落 2K。用户按 1K 的预期下单，结算按 2K 收，比他以为的贵一半。
单子怎么说，有没有人在修
新单是
#8472，今晚 17:59（北京）开的，作者 baalisgood，目前零评论。他给了三组实测：Sunburst medium 2048×2048 回 1254×1254 且 quality=low；Flare low 2048×1536 回 1448×1086；Flare low 3840×2160 回 1672×941。12三组的像素面积都约 1.57MP，接近 1536×1024 的面积。报障人自己写明这只是观察，不能据此断言所有账号有固定上限。
还有一条边界必须看：他用的是自编译版本，加了单次发送保护、禁用自动重试与接口回退。所以这是「自述 + 待核」，不能当成干净发行版的复现结论。
这也不是新病。老单
#3309 在 6 月 16 日就开了，至今 open，18 条评论里已经出现过 size/quality 恒为 auto、实际 1254×1254；#7119 是同类，还记录过 2160×3840 回 1312×1199。1314有人在做相关的事，但不是修这条。
#8462「生图账号按 1K/2K/4K 尺寸档位分流」正在评审，21 个文件，合并状态 unstable。15它的说明恰好印证了本项目怎么理解这件事：档位被当成账号能力问题，不是让上游照单执行的问题。 作者还点出一处连带伤害——4K 失败会触发「账号 + 模型」冷却，不区分尺寸，同号上本来能成的 2K 请求一起被拦。它明写「计费不变，本 PR 只影响调度」。
官方文档那一侧也给不出定论。Sunburst 与 Flare 的推荐尺寸是 1024×1024、1536×1024、1024×1536，也支持自定义宽高，但超过 2560×1440 属实验性。16 报障人那几组尺寸都在实验区之上，所以「为什么不按请求出图」有两种解释，现有证据分不开。
今晚能做的三件事
- 先对账：把出图请求的请求档与实际档摆在一起看。结算记录里同时有请求尺寸、输出尺寸与来源标记，来源是输出就说明按实测走了。17
- 再修定价预期：如果你按 4K 的价在卖 4K 请求，先把预期改到 2K，或者把 4K 需求导向 API Key 账号那条路——它不受这条归一影响。
- 要确定像素就别押这条路径：这条路径只能保证参数送到上游，不能保证上游执行。真要按
size出图，先用官方 API Key 通道验证一次再对外承诺。
CLIProxyAPI：连接池合进开发分支，v8.0.49 还不含
PR
#7101「按 api key 的可选上游连接池」上午 14:24（北京）已经合进主仓的开发分支。18但 v8.0.49 里没有它：发行标签与主干指向同一个提交，开发分支已经跑到前面去了。所以现在升级到 v8.0.49 看不到这个配置块；要等下一个发行版，才轮到决定开不开。
作者下午 17:46 贴了实测：开池后平均 0.936s 对 1.493s，省 557ms、约 37%；中位 0.949s 对 1.572s，省 39.6%；P90 1.400s 对 1.688s，只省 17.1%。他给的成因是 TLS 1.3 握手约 508ms 一次，复用就把这段省掉。
配置语义要注意：写下
connection-pool 这个块本身就是开启，写空对象用默认值。默认 idle-conn-timeout 300 秒、max-idle-conns-per-host 2；填零或负值等于关掉 keep-alive、每个请求重新拨号。四条边界决定它值不值得开：
- 池按 key 隔离，一个 key 的连接不会与另一个 key 共用。
- OAuth 凭证不走这条设置，它只作用于 api-keys 分组。
- 作用范围是标准 transport 与 Claude Code 的 TLS transport；ChatGPT 的浏览器指纹 transport 仍是一请求一连接。
- 每个 key 可以单独写
enabled: false退出，分组照旧。
另外别把两把同名开关搞混。v8.0.49 里已经有一个
antigravity.connection-pool，默认关闭、空闲 30 秒、上限 210 秒。19 那管的是 Antigravity 凭证自己的上游连接，与按 key 的那把不是一件事。社区信号：Antigravity 计量变快、模型被换掉
Reddit 的 r/GeminiAI 在这一小时里冒出两条相关自述，都还没有官方口径。
一条标题是「Antigravity 从低用量变成高用量（Pro 计划）」，作者 antiriad76，17:49 发布，称近两天用量骤增、约每 2 分钟掉 1%，周限与 5 小时限可能两天内用尽。20
另一条 17:54 发布，作者 maciejSTY，说会话来途中被换成别的模型。他引的界面文案是：
Advanced models are in high demand right now, so a different model was used for this response. This didn't count toward your limit. 21两条都是用户自述，量级未经核实。同一时段还有几条帖子说 Argon 被换成了 Flash，这类现象值得记一笔，但不该当成结论。
能在本机验的部分是模型替换，不是计量。用量日志里并排记着三个模型字段：客户端要的模型、映射后发给上游的模型、上游响应里自报的模型。22
usage_log.go 第 108–127 行：RequestedModel、UpstreamModel、UpstreamResponseModel 三列并列，UpstreamModelMismatch 记录上游自报模型与实发模型是否对不上。22如果这批日志里不一致标记集中出现，说明上游在换你的模型，这与额度高低无关；如果标记安静、用量却照涨，那才轮到查额度侧。判定的实现就在上游自报模型与实发模型的比较上。23
上游与重置行情
三个状态页这一小时都安静：OpenAI 全部服务正常，24 Anthropic 最近两条事件已在 10 月 28 日解决、窗口内无新事件，25 Google Cloud 最近一条仍停在 10 月 27 日。26
Codex 侧今天 UTC 还没重置。最近一次已验证的全局重置是 10 月 28 日 06:35（北京 14:35），累计 61 次、另有 10 枚 banked，节奏约每两天一次。27
另一家追踪站的口径更长：自 2025 年 9 月起 70 次、中位间隔 3 天。28 两家累计口径不同，引用时各按各家标签写。
上期在跟的几条
CLIProxyAPI
#7156 仍是 open、可合并，这一小时只有一条机器人评审摘要、没有未决问题，提交时间还停在上期那笔。#7154、#7151、#7152 与 #6529 形态未变，#6529 这小时只有作者在 17:05 那条 fork 分流说明。sub2api #8471 仍 open、状态 unstable。这几条都没有新动作，等有进展再单独说。References
- 1sub2api v0.2.19
github.com
- 2CLIProxyAPI v8.0.49
github.com
- 3usesCodexDirectImages
github.com
- 4同一函数的回落分支
github.com
- 5API Key 转发路径
github.com
- 6openai_images_direct.go
github.com
- 7openai_image_dimensions.go
github.com
- 8流式回写尺寸
github.com
- 9image_billing_size.go
github.com
- 10ResolveImageBillingSize
github.com
- 11默认图片价：2K 1.5 倍、4K 2 倍
github.com
- 12sub2api #8472
github.com
- 13sub2api #3309
github.com
- 14sub2api #7119
github.com
- 15sub2api #8462
github.com
- 16OpenAI 图像生成文档
platform.openai.com
- 17计费档解析的调用点
github.com
- 18CLIProxyAPI #7101
github.com
- 19v8.0.49 的 antigravity 连接池
github.com
- 20r/GeminiAI 用量骤增帖
reddit.com
- 21r/GeminiAI 换模型帖
reddit.com
- 22用量记录的模型三列
github.com
- 23upstreamModelMismatch
github.com
- 24OpenAI 状态页
status.openai.com
- 25Anthropic 状态页
status.anthropic.com
- 26Google Cloud 状态页
status.cloud.google.com
- 27codex-reset
codex-reset.com
- 28opentherank
opentherank.com
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.