用 gpt-image-2 和 2.5 传参考图居然完全没触发缓存计费

我想搞清楚一个问题，在用 gpt-image-2 和 gpt-image-2.5 做插画故事的时候，明明重复上传了同一张角色参考图，为什么在账单后台看到的 cached image inputs 永远是 0？

我的操作链路是调用 /v1/images/edits 接口，通过 multipart image[] 传参考图。为了保证角色一致性，每一张画的请求里包含的参考图字节码（bytes）完全一样，只是场景 Prompt 在变。我尝试了两种模式：一种是并发请求，另一种是顺序请求（先出封面和第一页预览，过段时间再出后面的正文页）。

结果在 API 账单看板里过滤 gpt-image-2 和开发 Key 之后，显示 uncached input tokens 跑了大概 75.2K，但 cache-read tokens 依然是 0。按理说，即便并发请求可能因为缓存还没写入而没命中，但后续那些间隔很久的顺序请求怎么可能一次缓存都没触发？

在论坛里深挖了一下，发现这可能是接口和计费逻辑的坑。

为什么 /v1/images/edits 不走缓存计费

结论很直接：/v1/images/edits 这个接口目前根本不适用缓存计费。

虽然官方价格表里列了缓存输入有折扣，但实测发现，这种 cached-image 计费其实是应用在 Responses 里的图像生成工具上，而不是这个特定的 API 接口。我尝试用 gpt-image-2 做顺序编辑，传完全相同的图，API 响应里依然没有报告任何 cache reads。

这导致了一个很尴尬的情况：官方在价格表里写了有折扣，但在 YAML 规范里没看到对应的 API 形状，最后在账单里也完全没体现。

避坑总结与验证细节

如果你也在对账单，可以核对以下几个点，看看是不是掉进了同样的坑：

• 接口路径： 检查是否在调用 /v1/images/edits，如果是，目前可以默认没有缓存折扣。
• 输入方式： 即使通过 multipart image[] 传输且字节码完全一致，只要是这个接口，大概率不触发。
• 账单数据： 重点看 cache-read tokens。如果这个数值一直是 0，而 uncached input tokens 在涨，说明你每次上传参考图都被当作新输入重新计费了。

目前看来，OpenAI 的这个计费逻辑极其混乱，价格表里有，但 API 层面没落实到具体的 edits 接口上。如果你对成本敏感，建议在计算预算时直接按 uncached 计费，不要把希望寄托在那个还没生效的缓存折扣上。