I’m using gpt-image-2 and gpt-image-2.5 to generate illustrated stories, and I’m seeing no cached image-input usage despite repeatedly reusing the same character reference image.
Our setup:
We call /v1/images/edits, uploading the reference image through multipart image[].
Each request uses the same reference image bytes but a different scene prompt.
Some requests run concurrently, but others happen sequentially: we generate a cover and first-page preview, then generate the remaining pages later using the same reference image.
Both models list cached input pricing, but my usage dashboard shows zero cached image inputs. For example, filtering to gpt-image-2 and our development API key shows approximately 75.2K uncached input tokens and zero cache-read tokens.
I understand concurrent requests might arrive before a cache is populated. However, that doesn’t fully explain the absence of cache hits when we reuse the reference image in later requests.
Does image-input caching actually work on /v1/images/edits for these models? Does changing the text prompt prevent the reference image from being cached, even when its bytes are identical? Are there specific timing, input-order, or request-format requirements?
Has anyone confirmed successful caching through their usage dashboard or billing? A minimal working example would be very helpful.
Below this topic, you’ll find a Related topics section. You may want to check those discussions to see what others have reported and whether any solutions or workarounds have been found.
Side note: I did try using Discourse AI search to find more relevant topics, the search result needs work.
I could not find any official response from the OpenAI team or any user that stated that could get the discounted rate for cached input images. Considering that we got a usage graph for this on the OpenAI Billing section, I expect that this is not the desired behavior.
Hi! /v1/images/edits doesn’t currently apply cached-input pricing when you reuse a reference image. Cached-image billing applies to the image-generation tool in Responses. I also tested sequential edits on GPT Image 2 with the same image; the Images API response didn’t report cache reads. Let me know if you have any questions!
API users of image models are developers with applications that can target and expect to exploit a context window cache. They would not offer a “chat that can make images” on Responses that would only be a worse and more expensive ChatGPT with arbitrary re-billing of input images.
This is the pricing page. It gives a clear message: construct a sequence of model calls with large enough repeated input, you will receive a discount. Nothing about the endpoint.
The discount is never delivered and the over-charge is 400%.
The technology is there but is not working in the place with the most cleanly repeated partial input?
Then you have to document if edit images or mask are placed first or last around prompt text in the context sequence.
On the ordering question: the images come before the text prompt, and a mask applies to the first image.
For ordinary /v1/images/edits calls, reusing the image doesn’t get cached-input pricing, regardless of changing the scene text or waiting between runs.
The pricing table should make this clearer! I've asked internally for confirmation of the wording and a working Responses example that shows cached-image pricing. Responses adds language-model costs too, so I'm not sure if it'll end up being the cheaper option.
I confirmed with the image team that cached-input pricing is limited to the Responses image-generation tool. It doesn't currently apply to /v1/images/edits.
For anyone testing through Responses: image-tool cache hits count toward billing discounts, but /v1/responses doesn't return those cached-input counts. You can't verify an image-cache hit from the response JSON alone.
Let me know if there are any outstanding questions here!
Is there any plan to make cached-input also be applied for /v1/images/edits? It definitely feels more like a bug than an intended behavior, also considering it is not written anywhere in the documentation.
The edits API fails to deliver a discount on even identical requests. Not even changing a single output parameter (which might have internal context placement informing the AI that is undocumented).
Moreso: the API can accept n>1 image outputs in one API request with the same prompt, receiving many variations from the same input. This seems like it should be an instant delivery of the remainder of the images at a cached or even free input pricing - as with Chat Completions.
This is certainly an area where OpenAI technology could have them internally enjoying the computation reduction and not sharing the win.
It seems the “responses” cache hits would be because the entirety of a growing chat is ran back into a parallel image model, an image model that is hitting you with a bill for observing the entire conversation. There, it is not even documented what breakpoint increments of token granularity or inside message content parts for “write” or “match” happen on this obfuscated second chat input that is going on to a multimodal image-output model that observes chats.
Is anything going to change from feedback?
Expectation: Documentation saying the cache pricing is untrue and, where actually plausible, still made unverifiable and unaccountable.
