GatchaEmbedding
GatchaEmbedding Rolls Dice on Your CLIP — and That's All It Does
- clip1
- clip2
- clip3
- clip4
- clip5
- clip6
- clip7
- clip8
- clip9
- clip10
- CLIP
The name promises a lot and delivers one tiny thing. Despite "Embedding" in the title, this node creates no embeddings. Despite living in the ComfyCloudAPIs category, it calls no API and needs no key. Strip all that away and GatchaEmbedding is a random CLIP selector: wire in up to ten CLIP models, hand it a seed, and it rolls a die and passes one through.
That's it. The entire mechanism is three lines of Python using the standard library's random module. If you've ever wanted the "lucky draw" experience in your workflow - you know, gacha, the misspelled thing the README leans into - this is that, for text encoders. The pack's own README is a parody ("a revolutionary technique for increasing output variety" followed by a roadmap of T-shirts, mugs, a book, a documentary, and an animated series), which is your first hint about how seriously to take it.
Why you'd reach for it
The idea is sound even if the implementation is a toy. In ComfyUI, your CLIP text encoder turns a prompt into the conditioning vectors the sampler consumes. A different CLIP model tokenizes and encodes that same prompt differently, which means slightly different conditioning, which means a slightly different image - even with the same prompt and the same sampler seed. So if you have a handful of CLIPs from the same model family lying around, this node turns your prompt into a slot machine: each run, the seed decides which encoder gets the job.
Where it actually makes sense: you're batch-farming seeds for variety and you want to shake the text-encoder side of the equation too, or you're deliberately comparing how different checkpoints' CLIPs respond to the same words. Where it doesn't: wiring an SDXL CLIP into an SD 1.5 graph. Conditioning dimensions are fixed by the model you're generating with, so mismatched-architecture CLIPs just error out downstream at the sampler. In practice the pool is "CLIPs that match your checkpoint," which for most people is one - which is why this is a fun experiment, not a production tool. The loose community signal on this pack is essentially nil, and the honest reason is that it does one very small thing.
How the roll works
The node collects whatever of clip1 through clip10 is actually connected, then does random.seed(seed) and random.choice(clips). Deterministic given the seed, so the same seed always picks the same CLIP - the reroll is the fun part.
One quirk worth knowing: it seeds Python's global random module, not ComfyUI's sampler RNG. That's fine, but it means the pick is reproducible only if you keep the seed fixed, and if other custom nodes in your graph lean on the same global random state, this node technically nudges their future draws too. Minor, real, and not worth losing sleep over.
The inputs that matter
- seed (required INT, default 1337, min 1, max 16777215) - the dice. Change it, get a different CLIP pick.
- clip1 … clip10 (optional CLIP) - your pool. Leave the unused ones disconnected; they're skipped.
- Output: CLIP - the winner, straight into a
CLIP Text Encodenode, then on to conditioning as usual.
The one output is a plain CLIP, so it slots into any workflow you already have. Nothing else changes downstream.
Installing it
Trivially easy, because this pack has no dependencies worth the name - no requirements.txt, no model downloads, just the stdlib. Either search "Gatcha Embeddings" in ComfyUI Manager, or:
cd ComfyUI/custom_nodes
git clone https://github.com/BetaDoggo/ComfyUI-Gatcha-Embedding
Then restart ComfyUI. That's the whole install. It's one of those rare custom nodes that can't possibly break your environment because it imports nothing but random.
Where it bites
The classic trap: leave every CLIP input disconnected and run it. random.choice on an empty list raises an error, so the node just fails. Also note the seed range starts at 1 - a natural zero seed gets rejected by the UI validator. And remember the output is useless unless it feeds a CLIP Text Encode; this node doesn't condition anything by itself. But honestly, the biggest risk here is overthinking it. It's a coin flip for CLIPs, well-made for what it is, and the README knows it. Roll, look at the output, reroll.
Inputs (11)
| Name | Type | Default | Description |
|---|---|---|---|
| seed | INT | 13371–16777215 | — |
| clip1opt | CLIP | — | |
| clip2opt | CLIP | — | |
| clip3opt | CLIP | — | |
| clip4opt | CLIP | — | |
| clip5opt | CLIP | — | |
| clip6opt | CLIP | — | |
| clip7opt | CLIP | — | |
| clip8opt | CLIP | — | |
| clip9opt | CLIP | — | |
| clip10opt | CLIP | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CLIP | CLIP | — |