image generation seed zero: Keep zero through client serialization

An image generation seed zero is a useful boundary fixture because zero is falsy in JavaScript but valid under the current image provider integer schemas. Losing it usually happens in application request construction before the gateway sees the body. Fix the serialization decision before interpreting any difference in generated images.

Find the destructive condition

A builder that includes seed only when Boolean(seed) is true drops zero. An expression such as seed || undefined has the same problem. The gateway image route does not use either pattern: it assigns body.seed and removes only properties whose value is undefined.

A local builder should distinguish missing from present. If zero was entered deliberately, serialize seed as the JSON number 0. If no seed was selected, omit the property. If a form supplies the text string “0”, convert and validate it deliberately before submission; the provider schema expects a number rather than coercing every numeric string.

Null is another distinct case. Sending seed as null does not request a default. The route preserves null for this direct field, and the optional integer schema rejects it. Optional means omission is allowed, not that every empty representation is accepted.

Use a small offline fixture

Create a fixture set containing omitted seed, numeric zero, a positive integer, a fractional number, null, and a numeric string. Capture the exact JSON produced by your builder. The first three should match their intended presence; the latter cases should be rejected by your application or clearly expected to fail provider validation.

Include a round trip through whatever stores your draft settings. A UI can preserve zero initially and lose it when restoring a saved draft through a truthy fallback. Check that the displayed control, local record, and serialized request all agree.

If your SDK supports multiple models, keep seed validation separate from model identity. The current adapters accept an optional integer, but that shared field is not evidence of equal upstream behavior.

Interpret a seed responsibly

A saved seed is provenance for an experiment. It is not a promise that repeated requests produce identical bytes, nor a way to transfer one model’s output to another model. Upstream versions, implementation behavior, and other parameters can change. Archive the actual output when exact historical evidence matters.

When comparing prompt revisions, hold the seed and other selected parameters constant if that fits your experiment. Still record each returned artifact and human decision independently. Do not describe a visual difference as a serialization bug until the submitted requests establish that the intended seed was lost.

Acceptance checklist

Approve the builder when seed zero remains a number through form parsing, persistence, restoration, and serialization. Confirm that optional omission remains different from null and that the request contains an explicit model.

Use numeric JSON types, prompt versioning, and seed reproducibility testing to connect this small contract test to a wider evaluation record.

Continue with models and parameters

• Flux API key: two paths, and what changes after you have one
• Flux API parameters: every accepted value and what it costs
• Flux aspect ratio options: what it accepts and what it rejects
• Browse all models and parameters guides