GPT Image 2.5 seed: can you get the same image twice?

You cannot pin a seed for GPT Image 2.5 on Sume. The seed field exists in the request schema, but Sume's docs say it is not served in v1 and that no model advertises it, so a request that sets it comes back as 400 unsupported_parameter. To get something that looks like the image you already have, reuse that image: pass its Sume URL back in input_references and describe what must stay.

This page covers what the 400 looks like, why resending the same prompt does not repeat a picture, and three ways to keep a look steady across a batch. Facts come from the Image API docs and the OpenAPI reference, read 2026-10-03.

What happens if I send seed anyway?

The docs list seed as "Seed for deterministic generation (not served in v1)" and put it with output_compression and explicit pixel size under catalog-gated parameters: in the schema, advertised by no model, rejected at runtime. The rejection is a 400, not a silent drop, so your script fails fast instead of producing an image you wrongly believe is reproducible.

Check the catalog before you rely on any parameter. GET /v1/images/models publishes capability descriptors per model, and the docs say a request that sets a parameter the model does not list is rejected. If seed ever appears in the descriptors for a GPT Image 2.5 row, that is the signal to try it.

curl -sS https://api.sume.com/v1/images/models \
  -H "Authorization: Bearer $SUME_API_KEY" \
  | python3 -c "import json,sys; d=json.load(sys.stdin)['data']; m=[x for x in d if x['id']=='openai/gpt-image-2.5'][0]; print('seed' in m['supported_parameters'])"

Why does the same prompt give a different picture?

A text prompt describes a set of acceptable images, not one image. Without a way to fix the random starting point, each call is a fresh draw from that set. Sume does not publish anything that promises byte-identical output for identical input, so plan as if every call differs.

That is also a billing fact: every completed generation is billed in full, and a failed one is not billed. Rerolling to "get the good one again" costs a new generation each time.

How do I keep a look consistent without a seed?

Use the three controls that are served. They trade exactness for something you can actually get.

• Anchor on an output. Take the URL from data[].url of the image you liked and send it as an input_references entry on the next call, with a prompt like "same character, same outfit, same lighting; new pose: sitting at a desk". GPT Image 2.5 takes up to 16 references.
• Freeze the parts you like with a mask. mask_url works on GPT Image 2.5 edits, so change one region and leave the rest to the model's edit behavior, then verify the untouched area yourself.
• Reuse the exact wording. Keep a fixed "style block" (lens, light, palette, background) at the top of every prompt and vary only the subject line. It will not repeat a picture, but it narrows the set.

A comparison of the options

The table summarises what each approach gives you on Sume today.

How should a batch handle this?

If you need ten variations that belong together, generate the hero first, review it, and feed its URL to the other nine. That makes the hero a visual contract and keeps your spend tied to images you intend to use. Keep the preserve list identical in every request, because edit drift grows when it changes between steps.

Do the review step with the cheapest honest check: open the hero at full size, look at hands, text and edges, and only then fan out. A defect in the hero is copied into every continuation, so fixing it once with a masked edit is cheaper than fixing nine outputs. If the hero is almost right, run one masked edit on the flawed region instead of rerolling the whole frame.

Store the Sume URL from the response, not any provider URL; the docs say Sume mirrors outputs into its own media URLs and results carry data[].url. If you need the file long-term, download it as soon as it completes and keep your own copy.

What would change this advice?

Watch the catalog, not the schema. The schema already contains seed, but the docs say no model advertises it, so the capability descriptors are the source of truth. If a GPT Image 2.5 row starts listing seed, test it on a small request and compare two outputs yourself before you build on it, because a seed that works on one provider path does not promise identical output across model versions.

Until then, treat each generation as a new draw, store the URL of every image you approve, and make consistency a property of your references and your prompt, not of a number.