Seed Input Type¶
The seed input type renders a number field with a companion "Random" button. It controls the random noise pattern used during image or video generation. The special value -1 means "generate a random seed," which the backend resolves to an actual integer before sending the workflow to ComfyUI. The resolved seed is saved in the job record so results can be reproduced later.
YAML Example¶
From the t2i-dynamic manifest:
inputs:
- id: seed
name: "Seed"
type: seed
default: -1
tooltip: "-1 = random. Set a number to reproduce results. With batch_count > 1, each batch gets seed + increment."
From the wan22-i2v-fp8 manifest (static workflow):
- id: seed
name: "Seed"
type: seed
node_id: "21"
field: "noise_seed"
default: -1
tooltip: "Controls generation randomness. Use -1 for a random seed each time."
From the wan22-svi-dynamic manifest (per-scene seed inside scene_list):
per_scene:
- id: seed
name: "Seed"
type: seed
default: -1
tooltip: "Seed for this specific scene. Use -1 for random."
Fields¶
| Field | Type | Required | Default | Description |
|---|---|---|---|---|
id |
string | yes | -- | Unique identifier used as the parameter key. Typically just "seed". |
name |
string | yes | -- | Human-readable label displayed above the seed field. |
type |
string | yes | -- | Must be seed. |
default |
integer | no | -1 |
Pre-filled value. Almost always -1 (random). Setting a specific number here would make the workflow deterministic by default, which is rarely desired. |
tooltip |
string | no | -- | Help text. Should explain the -1 convention and reproducibility. |
node_id |
string | no | -- | (Static workflows only) The ComfyUI node ID where the resolved seed is injected. |
field |
string | no | -- | (Static workflows only) The input field name on the target node (e.g. "seed", "noise_seed"). |
Frontend Behavior¶
When the runner page encounters a type: seed input, the buildSeedInput() function creates a composite element:
- A wrapper
<div>with classseed-rowthat uses flexbox layout. - An
<input type="number">element for entering the seed value. Itsminis0,maxisNumber.MAX_SAFE_INTEGER, and its initial value comes from the manifest'sdefault(typically -1). - A "Random" button (
btn btn--smclass) that, when clicked, sets the input's value to a random integer generated byMath.floor(Math.random() * 2147483647).
The number input carries data-input-id for form gathering. At submission time, the frontend reads the value as a number via Number(el.value).
After a successful job execution, the backend returns the resolved seeds in the response. The frontend displays these below the seed input as a "Used: 1234567890" hint, so the user can see (and later reuse) the actual seed that was used. This hint appears for:
- Top-level seed fields: a
<div class="seed-used">element is appended below the input. - Per-scene seeds: the hint appears below each scene's seed input within the scene card.
If the user submits with -1, the hint shows the randomly generated seed. If they submitted a specific number, the hint confirms that number was used.
Backend Behavior¶
Seed resolution¶
The backend treats -1 as a sentinel value meaning "generate a random seed." Every assembler function in workflows.py follows this pattern:
The random range is 0 to 2^53 (9,007,199,254,740,992), which is the maximum safe integer for JavaScript/JSON compatibility.
Seed storage in job records¶
The resolved seed (whether user-specified or randomly generated) is saved in the job record JSON under a seeds dictionary:
{
"workflow_id": "t2i-dynamic",
"params": { "seed": -1, ... },
"seeds": { "seed": 4827391056, "batch_1": 4827391056, "batch_2": 4827391057 }
}
This separation is intentional: params.seed records what the user submitted (-1), while seeds records the actual values used. This makes it possible to distinguish "the user wanted random" from "the user wanted this specific number."
Seed behavior with multi-generate¶
The multi-generate feature (the [- N +] stepper next to the Generate button) sends N sequential execute calls. Each call goes through the full seed resolution independently:
- If the user set seed to
-1: each job gets a completely fresh random seed. - If the user set a specific seed: every job uses the same seed, producing identical results (useful for testing other parameter changes).
Seed behavior with batch_count¶
When a dynamic workflow has batch_count > 1 (the repeat_variable mechanism), the backend handles seed incrementing:
for i in range(batch_count):
seed = int(params.get("seed", -1))
if seed == -1:
seed = random.randint(0, 2**53)
elif batch_count > 1 and i > 0:
seed = seed + i # Increment seed for batch
resolved_seeds[f"batch_{i+1}"] = seed
This means:
- With seed -1: each batch iteration gets an independent random seed.
- With a fixed seed: batch 1 uses the seed as-is, batch 2 uses seed+1, batch 3 uses seed+2, etc. This produces variations while keeping results reproducible.
Per-scene seeds¶
In the wan22-svi-dynamic workflow, each scene has its own seed:
for i in range(num_scenes):
scene_seed = int(scene.get("seed", params.get("seed", -1)))
if scene_seed == -1:
scene_seed = random.randint(0, 2**53)
resolved_seeds[f"scene_{i+1}"] = scene_seed
Each scene's resolved seed is stored separately as scene_1, scene_2, etc. in the job record.
Static workflows¶
For static workflows with node_id and field, the resolved seed is written directly into the workflow JSON at the specified node location, replacing whatever value was there.
Notes¶
- The
-1convention is universal across the codebase. Do not use0ornullas the random sentinel -- only-1triggers random generation. - Seeds are deterministic: the same seed + same prompt + same model + same settings = same output. This is how diffusion models work. However, changing any parameter (even slightly) typically produces a completely different result.
- The "Random" button in the frontend sets a value using
Math.random(), but this is cosmetic. If the user wants a true random seed on execution, they should leave the value at-1rather than clicking Random. The Random button is useful when the user wants to try a specific random number and potentially use it again. - The seed type can appear both at the top level of a workflow's inputs and nested inside
scene_listentries (asper_scenefields). The backend handles both contexts. - Seed values are displayed in the "Used" hint and in the job record. Users can copy a seed from a successful generation's job record and paste it into the seed field to reproduce that exact result.