Start Workflow

Plain ComfyUI has no concept of calling one workflow from inside another - no subgraphs, no "run this saved pipeline as a function." comfyui_LLM_party builds that capability itself, and Start Workflow is the entry point of it: the node that sits at the top of a saved sub-workflow and receives whatever an outer graph hands it.

The mechanism is worth understanding before you use it, because it's more involved than it looks. Per the pack's own author explaining it directly: the pack's workflow-transfer node spawns a genuinely separate ComfyUI process via a subprocess call, listening on a second port (8189 by default), and feeds it your saved sub-workflow through ComfyUI's own API. Start Workflow is where that inbound call lands - it's the point in the inner graph where the outer caller's parameters arrive, and its matching counterpart (End Workflow) is where results get sent back out through yet another port for the outer graph to pick up. This is genuinely closer to a microservice call than a subgraph - it isn't free composition, and it means a second full ComfyUI instance is running, with its own models loaded, for the duration of that inner workflow's execution.

How it works

Every field on Start Workflow is optional, and every one has a matching output of the same name. That's the whole design: this node doesn't transform anything - it's a pass-through boundary. Whatever the outer workflow supplies for a given field shows up as that same field on the output side, ready to feed into the rest of your sub-workflow.

The inputs and outputs that matter

The full set mirrors itself input-to-output:

• image_input1 / image_input2 (IMAGE), or img_path1 / img_path2 (STRING) - pass images in directly or by file path.
• system_prompt / user_prompt - for a sub-workflow that's an LLM conversation step.
• positive_prompt / negative_prompt - for a sub-workflow that feeds a sampler.
• model_name - which model the inner workflow should use.
• user_history - prior conversation state, if the sub-workflow continues a conversation rather than starting fresh.
• file_content / file_path - generic text or file passthrough for anything that doesn't fit the more specific fields above.

You'll essentially never wire all of these on a real sub-workflow - only connect what your particular inner graph actually needs. An image-processing sub-workflow cares about the image fields and ignores the prompt ones; an LLM-conversation sub-workflow is the reverse.

Where it fits

The pattern, per the pack's own author: save an inner workflow (with Start Workflow at its entry and End Workflow at its exit) in API format inside the pack's workflow_api folder, then use the workflow-transfer node in your outer graph to call it - passing whatever this node's inputs need. It's genuinely useful for the case it targets: letting an LLM's decision determine which of several pre-built sub-workflows actually runs, something a single static ComfyUI graph can't do on its own since it has no native branching.

How to install it

Search comfyui_LLM_party in ComfyUI Manager and install, then restart. Manual route:

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

Run pip install -r requirements.txt from inside the pack's folder using ComfyUI's own Python, then restart. This node itself needs nothing extra, but the workflow-embedding feature it's part of needs a free port (8189 by default) for the spawned inner ComfyUI process, and whatever models that inner workflow uses loaded a second time.

Common issues & troubleshooting

VRAM usage roughly doubles when you use this. That's expected, not a leak - a second ComfyUI process means a second set of loaded models. This is the tradeoff the author has confirmed directly when asked: the mechanism is a real second instance, not a lightweight subgraph, so budget VRAM accordingly before nesting workflows this way on a GPU that's already tight.

The inner workflow never runs, or the call hangs. Check that port 8189 (or whatever port your setup uses) is actually free and not blocked - since this spawns a real second process listening on that port, anything else already bound to it will prevent the inner workflow from starting.

Fields you didn't wire come through empty. That's correct behavior, not a bug - every field on this node is optional and simply passes through whatever it received, including nothing. Only wire what your sub-workflow actually consumes.