ChatGPT Image 2 or 2.5 at high quality: 27 cents vs 7 on Sume

At high quality and 1024 size, ChatGPT Image 2 is listed on Sume at $0.211, which bills as 27 cents, and ChatGPT Image 2.5 is listed at $0.0527, which bills as 7 cents. That is about 3.9 times the price for the older model. The Sume docs say you can still select ChatGPT Image 2, so the older id is still there. They also describe xhigh and max quality for 2.5, so those tiers are a reason to move, beyond price.

The two rows

Both are pass-through rows in the Sume image catalog. The catalog marks the Image 2 list as a high/1024 display rate, and the admission step uses an OpenAI image-token estimate that depends on quality and size. For Image 2.5, the catalog list is the high/1024 output only, rounded to $0.0001, and admission includes estimated input tokens.

Savings at volume

• 1,000 high-quality images: 27 cents x 1,000 = $270.00 on Image 2, 7 cents x 1,000 = $70.00 on 2.5. The gap is $200.00.
• 100 images: $27.00 against $7.00.
• Move down to low on 2.5 for drafts, at about 1 cent each, which is $10.00 per 1,000.

What the move changes in the request

On 2.5 the default quality is high when you omit it, and auto reserves the max price. If your Image 2 code never sent quality, check what it assumes before you switch ids. The 2.5 model also supports background: auto|transparent|opaque, up to 16 reference images, and custom pixel sizes with both edges a multiple of 16 and a 3840 maximum edge.

Recommendation

Move to 2.5 unless you have a reason to hold the older id, such as a prompt you tuned on Image 2 that you want to keep byte-for-byte stable. Run ten prompts on each at high and compare them before you switch a production queue. Select the model through the Image API with the explicit id gpt-image-2 or gpt-image-2.5, and compare in the same call settings.

Check it before you run it

Every figure above is a catalog list price times 1.25, rounded up to the cent, as of 2026-10-08. Catalogs change, so before a large batch, read the current model entry in the docs and recompute the one line that matters for your case. Write the arithmetic next to the job in your own notes: list rate, seconds or characters, multiplier, rounding. If the result differs from the wallet charge by more than a cent, the catalog entry has changed, and the docs page is the place to find out why.

Run one small job first. Submit a single request with the pinned model id and the settings in the tables, poll the returned polling_url until it finishes, and compare the charge with your estimate. Then scale up. Using a pinned id for the test matters, because sume/auto never names the family, so you cannot tie its charge to the row you priced.