Workflow Transfer V2

If you haven't read the Workflow Transfer article first, start there - V2 is the same idea, and the difference is one field. The original node spawns a second ComfyUI process on your machine and talks to it over hardcoded local ports (8189 out, 8190 back). V2 adds a server_address input (default 127.0.0.1:8190) so that target is now something you configure on the node instead of something baked into the pack's code.

That one field closes a real gap. On the pack author's own Reddit thread explaining the original node, someone asked exactly this: could it embed a workflow running on a different instance - say, a second GPU running its own ComfyUI so you could offload VAE decode without doubling up on one card? The author's answer at the time was that you'd have to go edit workflow.py directly, line 173, to change the hardcoded port. V2 is that fix turned into an actual node input - point server_address at any reachable ComfyUI instance's API port, local or remote, instead of always spawning a fresh subprocess on your own machine.

That makes V2 the more flexible tool for two real situations: running the sub-workflow on a second GPU you're already keeping warm with its own ComfyUI process, or targeting a workflow server that's already running somewhere else on your network, rather than paying the cost of spinning up a brand-new local instance every time.

Inputs and outputs - identical to V1, plus one field

is_enable (boolean) is the only required input. The full set of optional pass-through fields matches Workflow Transfer exactly - file_content, file_path, img_path1, img_path2, system_prompt, user_prompt, positive_prompt, negative_prompt, model_name, and the workflow_path dropdown (populated from your saved .json files in the workflow_api folder, same sample entries as V1 out of the box) - with server_address added on top.

Outputs are the same pair as V1: images (IMAGE) and text (STRING).

What doesn't change

Everything else about how this works is identical to V1, and worth repeating because it's the part people miss: this still isn't a lightweight subgraph call. Whatever's listening at server_address - whether it's a subprocess V2 spawns for you locally or an instance you already have running elsewhere - is a full, separate ComfyUI process with its own model loading and its own VRAM footprint. Use it when you need an LLM's output to decide, at runtime, which entire workflow branch to run (chat-only vs. chat-plus-image vs. chat-plus-video, for instance) - not as a convenience wrapper around a subgraph, which group nodes already handle for free.

If you're spawning locally rather than pointing at an already-running remote instance, the same rule from V1 still applies: don't close the console window that opens for the sub-process. Closing it kills the target and your main graph hangs waiting on a response that isn't coming.

Installing it

It's the same package as every LLM Party node - there's nothing separate to install for V2. ComfyUI Manager: search comfyui_LLM_party, install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/heshengtao/comfyui_LLM_party

then pip install -r requirements.txt in your ComfyUI environment, restart.

Common issues

If server_address points at a remote or second-GPU instance, make sure that target ComfyUI is actually up and its API is reachable from where your main workflow is running - firewall rules and "is the other process actually still alive" are the two things worth checking first when a request to a non-local server_address just times out. If you're using the default local spawn behavior instead, the troubleshooting is identical to V1: the target workflow needs to exist as an API-format JSON with Start/End Workflow nodes in the workflow_api folder, and a port already in use will block the spawn - though with V2 you at least have the option to point server_address somewhere else instead of fighting over the same port.