Seed (Swwan)

Everyone meets the seed problem the same way. You queue a batch, one image comes back gorgeous, and the seed that made it is already gone - because control_after_generate fires after the run, so the number sitting in the box is the one the machine will use next. This is the KB's "most reliable beginner injury in ComfyUI," and it's why rgthree's Seed node exists. This is the pack's port of it, and it keeps the trick that makes that node worth installing.

That trick: a seed node that remembers what it just ran, and gives you a button to put it back.

How it works

Two halves, and you need both to understand it.

The frontend half is where the magic lives. The pack ships web/js/swwan_seed.js, which patches api.queuePrompt before your prompt is sent. It looks for SwwanSeed nodes whose seed is a special value, resolves that value against the node's stored swwan_last_seed, writes the resolved number into the prompt and into the saved workflow metadata, then stamps the node with the number that actually ran. Three magic values: -1 randomise, -2 increment, -3 decrement. So "random every time" and "the next one, please" stop being a dropdown you set once and forget.

It also deletes the stock control_after_generate widget on load - deliberately, because that widget would rewrite your special value after the queue - and replaces it with buttons: Random each time, Increment each time, Decrement each time, New fixed random, and Use last seed. That last one is the recovery move: the good seed is sitting in the node's properties, one click away, instead of lost.

The Python half is a thin fallback. seed, hidden prompt/extra_pnginfo/unique_id, one SEED (INT) output. If a special value somehow reaches the backend - headless runs, API prompts, no frontend - it prints a warning, generates a random seed, and tries to write it back into the workflow metadata so the log isn't a mystery.

Inputs and outputs

One required input, seed (INT, default 0, range ±1125899906842624), and one output, SEED (INT). Wire SEED into the seed of a KSampler (after converting that widget to an input) or into anything else that wants an integer - a sampler, a filename prefix, a second sampler. One seed, many consumers, defined once: that's the pure-plumbing use case for a value node.

Install

Comes with the pack:

cd /path/to/ComfyUI/custom_nodes
git clone https://github.com/aining2022/ComfyUI_Swwan.git
cd ComfyUI_Swwan
python -m pip install -r requirements.txt

Then restart and hard-refresh the browser - this one matters more here than for most nodes, because the whole feature is a JS extension. If the buttons don't appear and there's no /extensions/ComfyUI_Swwan/ script loaded in the network tab, you're looking at a cached frontend, not a broken install.

Where people get burned

No frontend, no magic. Run this through an API or a headless queue and -1 is not "random each time" - it's a warning in the log and a random number. If you script ComfyUI, pass real seed values.

Don't add back control_after_generate. It's removed on purpose. Someone re-adding it via a custom script, or a Nodes 2.0-style frontend that reintroduces stock widgets, will fight this node's resolution step.

It doesn't fix the other seed trap. With the stock KSampler, the global "widget control mode → Before" setting is still the fix, and it's worth setting once per install regardless.

It's an INT, so caching behaves. The KB's note on rgthree applies here too: if you want a computed value to be cache-friendly, feed it a Seed node rather than a random built-in - a seed that resolves to a fixed number keeps the same cache signature across runs.

Legacy IDs. The pack catalog maps the old Seed (rgthree) ID onto SwwanSeed and keeps this as the current entry point - but if your workflow still references rgthree's own Seed (rgthree), it's a different node and stays missing until you migrate or install rgthree. The shipped scripts/migrate_workflow.py (dry-run first) handles that.