On this page · 11 sections
- What actually changed on 20 August 2026
- The compression trade nobody announced
- The cost you cannot calculate from the documentation
- The model card has not caught up
- Rate limits are the ceiling, not the price
- Where a transparent-background request is allowed to run
- India-specific considerations
- What is still unknown
- FAQ
- How eCorpIT can help
- References
Summary. OpenAI enabled transparent backgrounds for gpt-image-2 and the gpt-image-2-2026-04-21 snapshot on 20 August 2026, in preview, on /v1/images/generations, /v1/images/edits and the Responses API image generation tool. Set background to transparent and use png or webp; jpeg is not supported. The billing problem arrives with it. OpenAI prices gpt-image-2 image output at $30.00 per 1M tokens, image input at $8.00 and cached image input at $2.00, against $32.00 output for gpt-image-1.5 and $40.00 for gpt-image-1. The only output-token table OpenAI publishes, 272 tokens for a low-quality 1024x1024 image up to 6,240 for a high-quality 1024x1536 one, is labelled for "models prior to gpt-image-2". For gpt-image-2 itself the documentation sends you to an interactive calculator, and the pricing page sends you back to the same guide. The gpt-image-2 model card, meanwhile, contains zero occurrences of the words "transparent" or "background", four days after the feature shipped. Rate limits cap a Tier 1 account at 5 images per minute and a Tier 5 account at 250.
What actually changed on 20 August 2026
The OpenAI API changelog entry is dated 20 August 2026 and tagged against two models, gpt-image-2 and gpt-image-2-2026-04-21, and three routes: v1/images/generations, v1/images/edits and v1/responses. The image generation guide states it in one sentence: "Transparent backgrounds are available in preview for gpt-image-2. Set background: "transparent" to request one. Use png (the default) or webp; jpeg isn't supported with transparent backgrounds."
Three words in that sentence carry the engineering weight. "Preview" means no availability commitment. "Default" means png is what you get if you say nothing. And the exclusion of jpeg removes the one output format whose compression behaviour most teams already have tuned.
The same guide lists background alongside size, quality, format and compression as an output option, and notes that size, quality and background all accept auto, where the model picks. An auto background on a preview feature is a request whose output format you cannot predict in advance, which matters if a downstream asset pipeline expects an alpha channel.
The compression trade nobody announced
The guide states that output_compression, a 0 to 100 percent control, applies to jpeg and webp only. Transparency requires png or webp. Intersect those two constraints by hand and one format survives.
| Output format | Transparent background | output_compression supported |
|---|---|---|
png (default for transparency) |
Yes | No |
webp |
Yes | Yes |
jpeg |
No | Yes |
auto size or quality with png |
Yes, format fixed | No |
| Streamed partial images | Follows final format | Follows final format |
If you want a transparent asset and any control over file size, webp is the only path. Teams that standardised on png for transparency, which is most of them, get no compression parameter at all. That is not stated anywhere as a caveat; it falls out of two rules written eleven hundred lines apart in the same document.
Streaming makes it worse in a small, quantified way. The guide states that each partial image emitted through the partial_images parameter costs an additional 100 image output tokens. At $30.00 per 1M image output tokens, three partials add 300 tokens to every request. That is a rounding error on one image and a real line item at volume, which is the shape of cost we usually find in AI gateway model routing and FinOps work.
The cost you cannot calculate from the documentation
Here is the circular reference. The pricing page carries the per-token rates and then says, in the image generation block, "For image generation cost estimates, use the calculator in the image generation guide." The guide's cost section opens with the heading "gpt-image-2 output tokens" and one line beneath it: "For gpt-image-2, use the calculator to estimate output tokens from the requested quality and size." The calculator is an embedded widget. There is no static table.
The static table that does exist sits under the next heading, "Models prior to gpt-image-2":
| Quality | Square 1024x1024 | Portrait 1024x1536 | Landscape 1536x1024 |
|---|---|---|---|
| Low | 272 tokens | 408 tokens | 400 tokens |
| Medium | 1,056 tokens | 1,584 tokens | 1,568 tokens |
| High | 4,160 tokens | 6,240 tokens | 6,208 tokens |
Applies to gpt-image-2 |
No | No | No |
| Streaming partial image | +100 tokens | +100 tokens | +100 tokens |
Anyone who reads quickly will apply those numbers to gpt-image-2 and be wrong by an unknown margin, because the guide also warns that "a larger non-square resolution can sometimes produce fewer output tokens than a smaller or square resolution at the same quality setting". The old intuition that pixels scale linearly into tokens does not survive gpt-image-2.
The published rates are unambiguous. The token counts are not.
| Model | Image input per 1M | Cached image input per 1M | Image output per 1M |
|---|---|---|---|
gpt-image-2 |
$8.00 | $2.00 | $30.00 |
gpt-image-1.5 |
$8.00 | $2.00 | $32.00 |
gpt-image-1 |
$10.00 | $2.50 | $40.00 |
gpt-image-1-mini |
$2.50 | $0.25 | $8.00 |
chatgpt-image-latest |
$8.00 | $2.00 | $32.00 |
One more asymmetry sits in the same table. gpt-image-2 text output is listed as "-", while gpt-image-1.5 and chatgpt-image-latest carry $10.00 per 1M text output tokens. gpt-image-2 bills text input at $5.00 and cached text input at $1.25.
There is a second cost multiplier specific to editing. The guide states that input_fidelity cannot be changed on gpt-image-2 because the model "processes every image input at high fidelity automatically", so edit requests carrying reference images consume more input tokens than the equivalent request on an older model. On a transparency workflow, where the usual pattern is generate, inspect, edit, that lands on the most repeated call in the loop. We have written before about how image token billing turns into a peak-window problem when a vendor changes the counting rule rather than the price.
The model card has not caught up
The gpt-image-2 model card is the page an engineer opens first. Four days after the announcement it contains zero occurrences of "transparent" and zero of "background". Its "Supported features" section lists exactly one item, inpainting. Its endpoint table marks v1/responses as "Not supported", while the 20 August changelog entry names v1/responses among the routes that gained transparent backgrounds. Both statements are defensible once you know that the Responses API reaches GPT Image through an image generation tool rather than by naming the model, but the model card does not say so, and a reader checking capability on that page alone will conclude the opposite of what shipped.
Zero-occurrence checks like this are cheap and they keep catching real gaps. We ran the same check when Ultrafast mode was announced without a published price.
Rate limits are the ceiling, not the price
The model card does publish the numbers that will stop your rollout first. Image generation is capped by images per minute as well as tokens per minute.
| Usage tier | Tokens per minute | Images per minute |
|---|---|---|
| Tier 1 | 100,000 | 5 |
| Tier 2 | 250,000 | 20 |
| Tier 3 | 800,000 | 50 |
| Tier 4 | 3,000,000 | 150 |
| Tier 5 | 8,000,000 | 250 |
Five images per minute on Tier 1 is the number to plan against during a transparency evaluation. A designer iterating on cut-out product shots will hit it inside the first hour. gpt-image-2 also supports the Batch endpoint, which is the documented way around a per-minute image cap for work that does not need to be interactive.
Size constraints bind independently of tier: maximum edge length 3,840 px, both edges multiples of 16 px, long-to-short edge ratio no greater than 3:1, and total pixels between 655,360 and 8,294,400. A 4K landscape at 3840x2160 is 8,294,400 pixels exactly, which puts the largest documented size on the ceiling rather than under it.
Where a transparent-background request is allowed to run
Transparency does not change residency, and residency is where image work gets constrained. OpenAI's data controls guide lists ten regional domain prefixes. For /v1/images/generations and /v1/images/edits, regional processing is available in the United States and Europe only. gpt-image-2 appears in the supported model list for both routes.
| Region prefix | Regional storage for images | Regional processing for images |
|---|---|---|
us.api.openai.com |
Yes | Yes |
eu.api.openai.com |
Yes | Yes |
ae.api.openai.com |
Yes | No |
in.api.openai.com |
Yes | No |
gb.api.openai.com |
Yes | No |
The United Arab Emirates supports regional processing for chat completions, responses and embeddings, but its processing list does not include either images route. Seven further regions, Australia, Canada, Japan, India, Singapore, South Korea and the United Kingdom, show no regional processing at all. The guide also notes that image support in those starred regions requires approval for enhanced Zero Data Retention or enhanced Modified Abuse Monitoring, which we covered when mapping OpenAI's zero data retention limits by endpoint.
Cost follows. The pricing page states that regional processing endpoints carry a 10 percent uplift for models released on or after 5 March 2026. The default gpt-image-2 snapshot is dated 2026-04-21, which is after that cut-off, so a US or EU residency-routed image call is billed at 110 percent of the rates in the table above. Applied to image output, $30.00 becomes $33.00 per 1M tokens.
India-specific considerations
in.api.openai.com gives regional storage for /v1/images/generations, /v1/images/edits, /v1/files and /v1/vector_stores, and no regional processing for anything. Inference for an Indian project's image request happens outside India. Teams building consent-bound flows under the Digital Personal Data Protection Act 2023 should treat the prefix as a storage control, not a processing one, and document it that way, which is the same conclusion we reached on per-request regional processing.
For product photography, marketplace catalogues and marketing asset pipelines, the practical Indian pattern stays unchanged: generate in a supported processing region under a Modified Retention amendment, or keep the pipeline on self-hosted weights. Budget the 10 percent uplift either way if you route through a residency endpoint.
What is still unknown
OpenAI has not published a gpt-image-2 output-token table, has not said how long the preview runs, has not documented the failure mode when background: "transparent" meets output_format: "jpeg" in the same request, and has not updated the model card. Until the token table appears, the honest position for a finance model is a measured cost per image from your own usage dashboard rather than a figure derived from the documentation. Measure ten images at each size and quality you plan to ship, then multiply.
FAQ
How eCorpIT can help
We build and cost image generation pipelines against the numbers a vendor actually publishes, not the ones a launch post implies. That means measuring output tokens per size and quality on your own account when no table exists, choosing between png and webp on file-size evidence, and placing calls in a region that matches your retention commitments. Our engineering teams are ISO 27001:2022 certified and CMMI Level 5 appraised, and we design applications aligned with Digital Personal Data Protection Act 2023 requirements. Ask us to model your image generation costs before the preview becomes generally available and the rate card moves.
References
Last updated: 24 August 2026.