NInfer - Seed

Language models sample, which means the same prompt gives you a different answer every time. The seed is what ties that randomness to a number: pad the same seed into the same request and you should get the same completion back.

If that sounds familiar, it's because it's the same contract as a diffusion sampler's seed, and it comes with the same fine print. Here, the seed is genuinely useful for a different reason than in image generation: a prompt enhancer that produces a banger of a prompt is worth keeping, and a seed is how you get back to it without saving the output. It's also how you make "run this workflow twice and compare the settings" an actual experiment rather than two random draws.

Inputs and output

• Seed - integer, 0 to 4294967295 (that's 2³²−1, the usual 32-bit ceiling). Default 0.
• Options - merged in and out, like the rest of the family.

It ships with control_after_generate enabled, which is the same widget behaviour core nodes use: a small control next to the number that decides whether the seed changes between runs - keep it fixed, increment it, decrement it, or randomise it. Fixed is what you want while you're tuning the other settings; randomise is what you want when you're generating variant prompts and don't care which you get.

Mechanically, seed is one of the parameters the openai SDK accepts natively, so it travels as an ordinary request argument and needs no extra_body workaround. It also needs the model to be a sampling model doing sampling. With Temperature at 0 and a greedy decode, the seed has nothing to influence.

Getting reproducibility that actually holds

Three conditions, and the third one is the one people forget.

1. The same seed number on this node.
2. The same everything else. Same prompt, same system prompt or skill, same images in the same slots, same temperature, same Top P and Top K, same Max Tokens and Reasoning Effort, same Extra Body JSON. Change the system prompt by one character and you've changed the distribution the seed is sampling from.
3. Force Regen on, on the Chat node. This is the trap. With Force Regen off, ComfyUI will often hand you the cached previous answer instead of generating anything - so "same seed, same output" appears to work perfectly and proves nothing. It also means that when you change the seed and still get the old answer, the node never ran. If you're testing whether the seed does anything at all, turn Force Regen on and watch the token-usage preview in the Chat node's body: new counts mean a new generation, identical counts mean a cached result.

One honest caveat. "Same seed, same output" is the contract, not a guarantee. Server-side batching, different kernels, a change of model artifact, or a different quantisation of the same weights can all shift a token or two, and with a thinking model a small shift in the reasoning channel can cascade into a different final answer. Treat the seed as usually reproducible and always worth recording, not as a hash of your inputs.

Where it belongs in the chain

Anywhere in the options chain, since every option node merges by key and order doesn't matter. The one convention worth adopting: put it last, after the sampling nodes, so the widget ordering in your graph mirrors the way you think about the run - behaviour first, sampling later, dice at the end. When you come back to a workflow in three weeks to figure out why it produced that one perfect prompt, you'll be glad the seed is sitting right at the edge of the chain with a value you can read.