Workflow Transfer

ComfyUI has a well-known limitation: once a workflow starts running, you can't change its topology mid-execution. You can't have a graph that says "if the LLM decided this is a chat-only reply, skip the image generation branch entirely." Workflow Transfer is LLM Party's workaround, and it's more literal than you'd expect - it doesn't reroute nodes inside your graph, it launches an entirely separate ComfyUI process to run a different workflow, then pipes the result back.

Here's the mechanism, straight from the pack author explaining it on Reddit: you build your sub-workflow (say, an image-generation pipeline), bookend it with the pack's Start Workflow and End Workflow nodes, and save it in API format into the workflow_api folder inside the LLM Party project. Back in your main graph, you drop a Workflow Transfer node, pick that saved workflow from the dropdown, and wire in whatever inputs it expects. The first time it runs, the node spawns a second ComfyUI instance via subprocess.Popen on port 8189, feeds it the sub-workflow through the API, and reads the result back via the End Workflow node listening on port 8190 - then hands that result back into your original graph running on 8188.

That's a genuinely useful trick if you want an agent to decide, based on the conversation, whether to run "just reply" versus "reply and also generate an image" versus "reply and generate a video" - each as its own self-contained workflow, selected at runtime by the LLM's output rather than hardcoded into one giant graph.

The catch: it's a second full ComfyUI process, not a lightweight call

This is the thing to internalize before you reach for it. It is not a subgraph call - it's a completely separate ComfyUI instance, which means it loads its own checkpoints from scratch and uses its own VRAM on top of whatever your main instance is already holding. Don't use it as a convenience wrapper for "run this small subgraph"; that's what group nodes are for. Use it specifically when you need runtime branching driven by an LLM's decision, because that's the one thing core ComfyUI genuinely can't do on its own.

The other real gotcha, again straight from the author: the first run opens a second console window for that spawned instance, and you have to leave it open. Close it and the sub-instance dies mid-flight, and your main workflow just hangs waiting for a response from port 8190 that's never coming.

Inputs and outputs

Only is_enable (boolean) is required. Everything else is optional pass-through data for whatever your sub-workflow's Start Workflow node expects - not every field applies to every sub-workflow, they're just the common set the pack anticipates:

• workflow_path - the dropdown of saved sub-workflows. It's populated from whatever .json files you've dropped into the workflow_api folder; the sample entries you'll see out of the box (fastapi.json, draw.json, vtuber_api.json, and others) are the pack author's own example/test workflows, and your own saved ones will show up here the same way.
• system_prompt / user_prompt / positive_prompt / negative_prompt - text fields to forward into the sub-workflow.
• file_content / file_path / img_path1 / img_path2 / model_name - additional pass-through fields for sub-workflows that need a file, an image path, or a specific model name.

Outputs are images (IMAGE) and text (STRING) - the two things a sub-workflow commonly hands back.

Installing it

Same install as the rest of the pack: search comfyui_LLM_party in ComfyUI Manager, or clone 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 and restart.

Common issues

Beyond the "keep the console window open" trap above: the target workflow has to already exist as an API-format JSON with Start/End Workflow nodes bookending it, sitting in the workflow_api folder, or it simply won't appear in the dropdown. And if something else on your machine is already bound to port 8189 or 8190, the spawn will fail or hang - free the ports, or look at Workflow Transfer V2, which adds a configurable server_address field for exactly this situation instead of hardcoding the port.