After generate_image on sume/auto, why can't the agent name the model?
Sume never discloses which family ran for sume/auto: job.model stays sume/auto and the model list omits it. To name a model, pin an id from image-models_list.

The agent cannot name the model because Sume does not say. For sume/auto, Sume selects the family for you and never discloses which one ran. The job's model field stays sume/auto, and GET /v1/images/models does not list it. If a report must name the model, pin a catalog id instead of leaving payload.model blank on generate_image.
What the docs say, row by row
Sume's Image generation page has a Sume specifics table. The behavior that matters for an agent report is below.
| Question | Documented answer |
|---|---|
| Which family ran? | Never disclosed |
What does job.model show? | sume/auto (it echoes what you requested) |
| Is it in the model list? | No, GET /v1/images/models does not list it |
| What is billed? | cost, the USD amount billed to your wallet |
| Provider identity | Not disclosed for any model |
When blank is right, and when to pin
The MCP docs say to omit payload.model and route to sume/auto unless the user named a family. That is the right default for a quick draft where any good result will do. Pin a model when you need one of these:
- A repeatable look across a series: Auto may choose differently next time.
- A named model in a client report or a style guide.
- A feature only some models have, such as many reference images; for example,
gpt-image-2.5takes up to 16 references. - A price you can calculate in advance, from the catalog entry.
How to pin from an agent
Ask the agent to call image-models_list and read the capabilities of the entries, then image-models_get for the one it plans to use. The ids come from the live catalog, not from memory, because the catalog changes. Then it submits generate_image with that id in payload.model.
A good instruction reads: list the image models, choose one that supports references, show me its id and estimated price with dry_run=true, and wait for my yes before submitting. With Write granted, the paid call also needs an idempotency_key.
What the agent can say safely
After an Auto run, the safe statement is: generated with Sume Auto, job id and request id, billed amount. It should not guess the family from the look of the result. For the cost, quote the cost or the debited amount from usage_get, not the held estimate. If the user later wants the same style, the instruction is to rerun with a pinned model and compare.
Same rule for video
The same behavior exists for video. The Video generation page says sume/auto is an addition that only Sume has, and that the poll response reports sume/auto without disclosing which family ran. An agent that generates both images and clips on Auto should therefore label its outputs with the job id and the billed cost, which are always known, and not with a model name.
This is also why a style guide that says "made with model X" cannot rely on Auto. If your brand needs the claim, pin the id in the instruction and have the agent copy it into the report from the catalog entry, not from the picture.
Sources
Related posts
More in Agents
- Agent leaves model blank on generate_video: 720p 8 s costs $1.00
Omit payload.model and generate_video routes to sume/auto: 3 to 10 s, 720p and 8 s by default. At 720p the price runs from $0.38 for 3 s to $1.25 for 10 s.
- Haiku 5.5 effort for an agent that polls Sume jobs
Claude Haiku 5.5 defaults to medium effort. What that means for a loop that calls Sume jobs_wait, and when to move to low or high.
- Use a low-effort Haiku 5.5 subagent for Sume dry_run previews
Anthropic recommends low effort for subagents, and warns it can skip checks. Where a Haiku 5.5 subagent fits in front of a paid Sume call.
- Same Sume agent run: Haiku 5.5 is $0.04, Mistral Large 4 is $0.50
One workload, two vendor price pages: 40 turns of 8,000 input and 400 output tokens driving Sume tools. Haiku 5.5: $0.04. Mistral Large 4: about $0.50.
Written by Sume