Moving off Image 1.0: quality default flips from low to high

If you migrate from /v1/image-1.0/generate to POST /v1/images and pin ChatGPT Image 2.5, add quality: "low" yourself. Image 1.0 defaults to low; on the new route the docs say that omitting quality for ChatGPT Image 2.5 means high. At 1024-class sizes that is 1 cent versus 7 cents per image, so an unchanged request body can cost seven times as much.

Why the default matters

The docs describe Image 1.0 as a compatibility alias for Image Router Auto that is retiring soon. Its public URLs stay as aliases and return job.model: "sume/auto". For new integrations the docs say to use POST /v1/images with model: "sume/auto" or a catalog id.

The two routes have different defaults, and they look the same in a diff because the field is simply absent from your request. A request body that has worked for months can change price only because the route changed.

What the arithmetic looks like

Take ChatGPT Image 2.5 as the example, since Auto routing uses Flare for it. A nightly job of 1,000 images at the low default costs 1,000 x 1 cent = $10. The same body sent to /v1/images on gpt-image-2.5 without quality costs 1,000 x 7 cents = $70. Sending quality: "low" brings it back to $10; sending medium costs $20.

If you intended the higher quality, then 7 cents is a fair price for a final. The point is to choose, not to inherit a default by accident.

Migration checklist

Work through these in order and compare cost before and after.

• Set quality explicitly in every request body.
• Replace image_urls with input_references objects: {"type": "image_url", "image_url": {"url": "..."}}.
• Replace num_images with n.
• Replace mask_image_url with mask_url.
• Pin a catalog id if you need the same model next week; Auto does not disclose the family.
• Log usage.cost for a week and compare it with the old bill.

What stays

Image 1.0 still accepts transparency for stills with transparency: true; the new route handles transparent backgrounds with background: "transparent" on ChatGPT Image 2.5. The legacy Image Router routes keep working but get no new parameters, so the longer you wait the more you lose.

A test before the switch

Run your ten most typical Image 1.0 requests through the new route with quality: "low" and with no quality, and compare usage.cost on both. The first should match the old spend. The second shows the cost of inheriting the default. Keeping both results next to each other in a pull request makes the reason for the explicit field obvious to the next reader.

Dates and routes

The docs call Image 1.0 a compatibility alias that will retire soon, and the legacy POST /v1/image-router/generate and GET /v1/image-router/models routes still work but are deprecated and will not get new parameters. There is no date in the docs, so plan the migration now instead of waiting for a notice. Move the one request template, test it, and then move the rest.