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
- 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.
- Waiting 10 minutes for a Sume render over MCP: 11 jobs_wait calls
A remote MCP jobs_wait holds at most 55 seconds, so a 10-minute render takes up to 11 calls at the cap, 12 at the default 50. Re-issue the wait; never resubmit.
- Nightly Sume schedule: model choice and the 30-day cap math
A nightly Scheduled run caps generation at $1.00 by default, so 30 nights is at most $30. How the model's token cost sits beside that cap, with the arithmetic.
Written by Sume