Should I use sume/auto for brand image work? Pin a model id instead
sume/auto picks the image family for you and never says which. For brand work where consistency matters, pin a catalog id. What the docs say and how to choose.

For brand work, pin a model id. Sume's Image API docs describe sume/auto as a Sume-only value: Sume selects the family and never discloses which one ran. The response echoes sume/auto as the model, and GET /v1/images/models does not list it. If you cannot see which model made the image, you cannot reproduce its look next week.
Use auto for quick drafts and one-off needs, where the best-fitting model matters more than a repeatable one.
What auto gives you and takes away
| Question | sume/auto | Pinned catalog id |
|---|---|---|
| Who picks the family | Sume | You |
| Is the family disclosed | No; job.model stays sume/auto | Yes, in the request and the job |
Listed in GET /v1/images/models | No | Yes, with its descriptors |
| Capabilities known up front | Not as a row | Read from supported_parameters |
| Same look next month | Not promised | Same row, subject to catalog changes |
Why a brand should not leave it to auto
A brand look is a set of choices: the rendering style, how the model draws type, how it handles a logo reference. Those differ by family. Auto trades that control for convenience, and the docs say outright that the family stays hidden.
The docs promise no particular family for a given prompt, so the look can change without notice. Pinning removes the question.
How to pin well
- Pick one row for text-heavy layouts, such as
ideogram/ideogram-v4.5, and one for photographic product shots, such asopenai/gpt-image-2.5. Test your own brief on each at low quality. - Record the model id with every approved image, next to the job id.
- Re-read
supported_parameterswhen you upgrade, since a row's descriptors are what the API enforces. - Keep auto for exploration. Switch to the id that won once you have an image you like.
A short test
Send the same prompt to sume/auto and to two pinned ids at low quality, and compare the three side by side. The point is not to find a winner for all work, only to learn which style your brief tends to produce. Then write the winning id into your template.
import os, requests
key = os.environ.get("SUME_API_KEY")
if not key:
raise SystemExit("set SUME_API_KEY")
for model in ["sume/auto", "ideogram/ideogram-v4.5", "openai/gpt-image-2.5"]:
r = requests.post(
"https://api.sume.com/v1/images",
headers={"Authorization": f"Bearer {key}"},
json={"model": model, "quality": "low",
"prompt": "Minimal ad: a ceramic mug on a pale table, soft light"},
timeout=90,
)
print(model, r.status_code, r.json()["data"][0]["url"] if r.status_code == 200 else r.text[:100])Sources
Related posts
More in Models
- TikTok's three ad ratios and Kling 3's three: 9:16, 16:9 and 1:1
TikTok's non-Spark ad specs list 9:16, 16:9 and 1:1. Kling 3 on Sume lists exactly those three, at 720p or 1080p and 4 to 15 seconds. Here is what that fits.
- Wan 3.0 Apache-2.0: repo license line vs hosted API on Sume
The Wan 3.0 GitHub page shows an Apache-2.0 license line but does not say weights are released. What that does and does not tell you, plus the wan-3.0 id.
- Wan 3.0 reference videos: 5 clips, 15 s total, 16 fps floor
Wan 3.0 on Sume takes up to 5 reference videos, 15 seconds combined, each at 16 fps or higher. Check clip count, length and frame rate before you submit.
- AI video models with sound: which toggle it, which are always on
Seedance 2.5, Wan 3.0, Kling 3 and MiniMax H3 all return audio on Sume. Kling prices audio separately; H3 and Omni cannot turn it off. What each does.
Written by Sume