sume/auto or a pinned image model: what the response shows

Pin an image model when you need to know what made the picture, and use sume/auto when you only need a good picture. The two differ in what Sume tells you afterwards. With a pinned id, the response model echoes the id you requested. With sume/auto, job.model stays sume/auto, GET /v1/images/models does not list it, and Sume never discloses which family ran.

Side by side

These behaviors are documented on the Sume Image API page, read 2026-10-08.

Where the choice changes the bill

The clearest example is ChatGPT Image 2.5. If you pin it and set quality: "low", you pay about 1 cent per 1024-class image. If you leave quality at auto, Sume reserves the max price at admission. If you omit it, the model runs at high, around 6 to 7 cents. The Image API page also describes a quality field with auto, low, medium, high, xhigh and max, so set it explicitly on any request where the price matters.

A practical split

• Exploration, mood boards, one-off assets: sume/auto, since you do not need to know the family.
• Brand work that must look the same next month: pin the id, because with Auto you cannot see which family produced the image and so cannot repeat it on purpose.
• Comparisons between models: always pin, since Auto cannot tell you which side of the test you are looking at.
• Cost control at volume: pin the id and the quality, then compute the price from the catalog before the batch.

Legacy aliases

Image 1.0 (POST /v1/image-1.0/generate) is a compatibility alias for Image Router Auto, and Sume will retire it. For new integrations, use POST /v1/images with either sume/auto or a pinned catalog id, as described on the Image API page and in the Models overview.

One more difference shows up in logs. A pinned request leaves a job whose model field you can group by, so a weekly cost report can split spend per model. Auto jobs all fold into one sume/auto bucket, which is fine for a single team budget but gives you nothing to compare. If you want to learn which model suits a prompt type, run a pinned test set first, record the prices, and only then decide whether Auto is good enough for the routine traffic. Retired models follow a similar rule: a retired id such as nano-banana-2 still works and runs as its successor, and the job stores the new id, so check the stored model after a migration.