Ideogram 4 custom_model_uri vs Sume catalog ids and sume/auto

Ideogram's custom-model endpoint generates with a model "that you or your organization can access, selected by custom_model_uri". Sume's documented Image API has no equivalent field: you pick a model id from the catalog, or send sume/auto. The docs describe no private or fine-tuned model hook, so do not expect custom_model_uri to be honored.

Ideogram facts are from its custom-model endpoint page; Sume facts from the Image API docs, both read 2026-10-01.

How does Ideogram select a custom model?

The endpoint is POST /v2/image/generate/ideogram-4-custom-model. custom_model_uri is required, in the form model/<id>/version/<id>, and you or your organization must have access to the model. The page also says the model determines which rendering speeds are supported.

How do I choose a model on Sume?

Discover models and pricing with GET /v1/images/models, then send one catalog id as model to POST /v1/images. sume/auto is a Sume-only value: Sume picks the family and never discloses which one ran, it is not listed in the catalog, and job.model stays sume/auto.

What happens if I send a field Sume does not list?

A request that sets a parameter the selected model does not list is rejected with 400 unsupported_parameter rather than silently dropped. So an unknown custom_model_uri is a signal to change the request, not something to ignore. Sume also does not disclose upstream provider identity.

What can I do for brand consistency instead?

Use input_references to pass reference images for image-to-image, and keep the prompt and catalog id fixed across a campaign. For the Ideogram 4.0 family on Sume, see Ideogram 4.0 API.