Recipe List

Mecha Recipe List exists for one structural reason: several merge nodes in this pack accept any number of recipes, and ComfyUI can't do "any number of wires." So the pack bundles recipes into a MECHA_RECIPE_LIST - one wire carrying many - and this node is the bundler. Set a count, plug in that many recipe_N inputs, and out comes a single recipes list you feed into the varargs socket of a Clamp (bounds), a Dropout (deltas), a Geometric Median (models), or any of the TIES-family multi-model merges.

It's a plumbing node - the ComfyUI equivalent of a tuple - and its only job is to be there when a merge needs a list. You'll use it constantly for multi-model merges and almost never think about it.

Inputs

• count - an INT (default 2, up to 64) controlling how many recipe_N sockets are visible. Bump it to match how many recipes you're bundling; a little JS in the pack (varargs.js) shows and hides the sockets so the node stays tidy.
• recipe_0 … recipe_63 - the recipes to bundle, all optional MECHA_RECIPE inputs. The node packs the first count of them in order.

Output: recipes, a MECHA_RECIPE_LIST.

Notes from the siblings

There's a second list node in the pack, Mecha Subtract Recipe List, which does the same bundling but subtracts a base_recipe from every entry on the way through - handy when you're assembling multiple deltas all derived from one base. And the sockets on varargs merge nodes (like Dropout's deltas) are the consumers; Recipe List is the producer. If you see a MECHA_RECIPE_LIST socket on a merge node, this is what feeds it.

Install & gotchas

ComfyUI Manager → search mecha → Mecha Merge Node Pack, or:

cd ComfyUI/custom_nodes
git clone https://github.com/ljleb/comfy-mecha.git
pip install -r comfy-mecha/requirements.txt

Restart; only dependency is sd-mecha==1.1.7.

The gotchas are the boring but real ones. count and how many you actually plug in should match - a count of 3 with only 2 wired leaves a gap, and the pack reads the first count sockets. The list is ordered, so for methods where order matters (it usually doesn't in the sum-style merges, but check), the position of your wires is the position in the list. And remember this produces a list, not a recipe: wiring it into a single-recipe socket errors, and feeding a single recipe where a list is expected needs this node - you can't fake it. The 64-socket ceiling is a hard cap; if a merge method needs more models than that, you're in a rare place indeed.