Legion: Master (12 channels)

LegionMaster is the node that actually makes something happen in LegionPower. You've configured a worker with Legion: Configuration, you've built a worker workflow that starts with Legion: Importer and ends with Legion: Exporter - this node is the middleman that serializes your inputs, shoves the worker workflow into a separate ComfyUI process, and collects the results.

This 12-channel version is the biggest Master variant; there are also 3- and 6-channel editions. They're identical in behavior, they just expose fewer input/output ports so your graph stays tidy when you only need a handful of values.

When to reach for it

LegionPower's whole pitch is isolation. If you have a VRAM-hungry post-processing step (ReActor face restore is the canonical example) that never seems to give memory back, you can run it in a worker process. Same story for long-running jobs you don't want blocking the main UI, or workflows you want pinned to a specific GPU. The catch - and it's a big one right now - is that only images and primitives cross the wire. You can't offload a full sampling pass yet, because latents, models, and conditioning don't serialize. So think "disposable post-processor," not "distributed generation."

How it works

1. The node takes your legion_config (or a warmed-up legion_campaign), serializes every connected input_N into a run-specific temp folder, and writes an input manifest.
2. It finds the worker workflow file, locates its LegionImporter node, and patches data_exchange_root to point at that temp folder.
3. It makes sure a worker ComfyUI is alive on the configured port - starting one if needed (main.py --port XXXX, same install, same Python) - then submits the patched workflow over HTTP and waits for it to finish.
4. When done, it reads the output manifest the worker's LegionExporter wrote, deserializes, and returns results as output_1 … output_12.

Sync vs async: with execution.asynch: false (default) the node blocks and returns real outputs. With true, it returns immediately - output_1..12 come back as error-message strings on purpose, and you collect results later with Legion: Join. You can also feed a previous legion_campaign in instead of a config to reuse a running worker.

The inputs and outputs that matter

• legion_config - the config object from Legion: Configuration. You need either this or legion_campaign, not both (the node raises if both or neither are connected).
• input_1 … input_12 - data to send to the worker. Wire in only what you need; empty ports are skipped.
• legion_campaign (output) - a handle you can pass to a Join node or reuse as the input of another Master.
• output_1 … output_12 - the results, in order, in sync mode.

Installing

ComfyUI Manager: search "LegionPower". Or:

cd ComfyUI/custom_nodes
git clone https://github.com/Transhumai/ComfyUI-LegionPower.git
cd ComfyUI-LegionPower
pip install -r requirements.txt

Restart. The only dependency is requests; no model downloads, nothing heavy.

Troubleshooting

• Worker on port XXXX failed to start in time - port already in use, or auto-detection picked the wrong ComfyUI path/Python. The Master prints the exact launch command to the console; run it by hand to see the real error.
• Output manifest not found - the worker workflow ran but has no connected LegionExporter, or it errored partway through.
• Data types don't match - unsupported inputs are skipped with a warning and come back None.
• VRAM not freed afterwards - by design. Workers stay alive for reuse. Change the port in the config or restart ComfyUI to force a fresh worker.

One honest note: this pack is a 0.1.1 MVP with essentially no community footprint yet, so treat it as promising machinery with sharp edges. Test with dry_run: true in the config before you point it at real workloads.