sume/auto hides which image model ran: pin an id for brand assets

model sume/auto never discloses the family, and job.model stays sume/auto. Why a brand asset set needs a pinned image model id, and how to pin one on Sume.

4 min readSume
All posts

No: with model: "sume/auto" you cannot find out which image family Sume ran. The Image API docs say Sume selects the family for you and never discloses which one ran, job.model stays sume/auto, and GET /v1/images/models does not list it. If a set of brand images must look the same next month, pin a real model id.

Auto is a good default for a one-off picture. It is the wrong default for a series, because you cannot reproduce or debug what you cannot name.

What Auto gives you and what it hides

The table sets Auto beside a pinned id, using only what the docs state. Nothing here says which model Auto picks, since Sume does not say.

sume/auto versus a pinned model id on the Sume Image API (Image API docs, read 2026-10-10)
Questionsume/autoPinned id such as bytedance-seed/seedream-4.5
Which family ran?Not disclosedThe one you named
model in the responseEchoes sume/autoEchoes the id you sent
Listed by /v1/images/modelsNoYes, with capabilities and price
Capability check before the callNot possibleRead supported_parameters

Why it matters for a series

A series needs the same look, ratio and reference handling every time. With Auto, a change in routing on Sume's side can change all of these without a visible signal in your logs. With a pinned id, a change shows up as a documented catalog change, a different price on the endpoint, or an error such as 400 unsupported_parameter when a field is withdrawn.

Pinned ids also let you check a request before you send it. The supported_parameters descriptors for the model tell you the ratios, n range and reference count, so your code can reject a bad combination locally.

How to pin, and the traps

Send the org/slug id from the catalog, for example openai/gpt-image-2.5 or google/nano-banana-2.1. Sume also accepts the bare Image Router ids, such as gpt-image-2, as aliases for their org/slug equivalents, but the full id is clearer in logs.

Two traps are worth knowing. First, retired ids can be aliased: nano-banana-2 still works but runs as Nano Banana 2.1, and the job stores the 2.1 id, so your pin may point at a different model than its name suggests. Second, the old Image 1.0 URLs are compatibility aliases for this Auto pipe and Image 1.0 is retiring, so a pipeline built on them is on Auto whether you meant it or not.

  • Store the model id with every generated asset.
  • Compare the model echoed in each response with the id you sent.
  • Re-read GET /v1/images/models at start-up and fail loudly if your pinned id is missing.
  • Re-run a small sample when you change a pin, before you change the whole set.

How to test a pin before you commit

Choose two or three candidate ids and run the same five prompts on each, with the same references and ratio. At the catalog base prices, five prompts on a 0.05 USD model cost 0.25 USD, and on a 0.0375 USD model 0.1875 USD, so the whole comparison costs well under a dollar. Keep the outputs next to the id that made them, and pick on what you see, not on a guess about what Auto might have used.

Then write the chosen id into one configuration value, not into twenty call sites. The day you want to change the look of the series, you change one line and re-run a sample.

When Auto is fine

Auto suits prototypes, one-off pictures, and cases where you care about getting an image rather than which image. Use it there. If you later decide to pin, do it by running the same five prompts on two or three candidate ids and choosing from the results, which costs only a few cents at the catalog's base prices.

Sources

Related posts

More in Developers

All Developers posts

Written by Sume