XSeed

Seeds are the least glamorous part of ComfyUI and the most useful one to get right. The whole "change one variable at a time, keep the seed fixed" discipline that everyone preaches falls apart if you can't lock a seed down, and XSeed is basically a nicer seed input that the Xz3r0 pack also hooks into its data-saving system.

What it gives you over the stock KSampler seed field: a proper native randomize control, an optional digit cap, and a second output that feeds the pack's XDataHub saving pipeline so your seed gets logged next to your outputs instead of being lost when you close the tab.

How it works

You get three inputs:

• seed_value - an INT from 0 to 2^64−1 with control-after-generate enabled. That's the dice: in the UI it has the same "randomize after generation" control the native seed inputs have, so you can let it roll and then lock the result to reproduce the image later.
• digits - a cap from 1 to 20. If the seed is longer than this, the node truncates from the front (keeps the leading digits), not the tail. That's the surprising bit: 12345678901234567890 with digits=10 becomes 1234567890, not ...67890. It's a digit-count limiter, not a modulo operation.
• pad_to_limit - if the seed is shorter than the digit limit, pad trailing zeros up to the limit. The author's own tooltip warns you this is rarely triggered: random seeds in the 64-bit range are almost always high-digit numbers, so you'll basically never see it fire.

The node also validates as it goes - negative seeds and digit limits outside 1–20 raise clean errors, which is more than most seed nodes bother to do.

The outputs

Two of them:

• seed_int (INT) - the final normalized non-negative seed. This is what you wire into the KSampler's seed input.
• xdata_seed - a custom xdata_seed payload (a small dict carrying the seed, digit limit, and source). It's only useful inside this pack's ecosystem: feed it to the XDataHub data-saving nodes so the exact seed that produced an image gets stored alongside it. If you don't use XDataHub, ignore it.

Why bother

Honestly, if you just need a random seed, the built-in KSampler input already does it. XSeed earns its place two ways: it's a central place to manage the seed when you've got multiple samplers (one seed source driving several KSamplers instead of two dice that can drift apart), and the digit cap matters if anything downstream - an API, a spreadsheet, an external log - has a length limit on the number. The XDataHub payload is the real differentiator, so if that data-saving workflow isn't your thing, this is a small quality-of-life node rather than a must-have.

Installing

It's part of ComfyUI-Xz3r0-Nodes. Easiest via ComfyUI Manager - search "ComfyUI-Xz3r0-Nodes" and install. Or:

cd ComfyUI/custom_nodes
git clone https://github.com/Xz3r0-M/ComfyUI-Xz3r0-Nodes.git
cd ComfyUI-Xz3r0-Nodes
pip install -r requirements.txt

Restart ComfyUI afterward. No models, no heavy dependencies - just ffmpeg-python in the requirements file, and even that isn't needed for this node.

Gotchas

• Truncation keeps the leading digits, not the last ones. If you set digits=10 you'll get the first 10 digits of whatever rolled.
• pad_to_limit sounds useful and almost never does anything, per the author's own note - that's expected, not a bug.
• If you're reproducing images, always read the seed back from the seed_int output after truncation, not from the raw seed_value, since the cap can change what actually got used.