ComfyUI Client Load (Yogurt Nodes)

Here's a thought: what if your ComfyUI workflow could run another ComfyUI workflow - on a different machine, a second instance on the same box, or a rented GPU box? That's the trick the eight "ComfyUI Client" nodes in this pack pull off. ComfyUI Client Load is the anchor: it points at a server, holds a workflow JSON, and emits a COMFYUI_CLIENT object that the other seven nodes thread through your graph.

What it does

The workflow JSON is the standard thing you get from ComfyUI when you export the API format (that's the "API" tab next to "Share," or via the /object_info endpoint). You paste that into the workflow field, give it a server address, and Load configures an HTTP session pointed at that server's API. The client output then travels through Set nodes (which override values in the workflow) into a Run node (which submits it and waits), and finally into Get Output (which pulls results). In one graph you can orchestrate: preprocess locally, ship the job to the big GPU box, pull the result back, and keep going.

This pattern is real, by the way - the community builds exactly this kind of orchestrator CLI for serverless ComfyUI endpoints, submitting a workflow JSON with parameter overrides and collecting outputs. These nodes are that idea, but inside the graph instead of a terminal.

Inputs

• server - the ComfyUI server address. Defaults to http://127.0.0.1:8188, which is your local instance. Point it anywhere: another machine on your LAN, a cloud box, a tunneled endpoint.
• workflow - the workflow JSON, multiline. This is the whole remote program, so it deserves a text file or a Load Text node upstream rather than hand-editing in the widget.
• poll_interval - how often (in seconds) the client polls the server's history while waiting for a run to finish. Default 0.2s; bump it up for slow jobs on a distant server so you're not hammering the API.
• timeout - how long to wait for a result, in seconds. Default 120. 0 means no timeout, which is how you hang a workflow forever - set it.
• auto_connect - whether to open the HTTP session immediately. Leave it on true; the tooltip notes image uploads need the session live.

Outputs

• client - the COMFYUI_CLIENT handle. Everything downstream in this family consumes it and passes it back out.

Install

Standard Yogurt Nodes install. ComfyUI Manager → search "ComfyUI-YogurtNodes", or:

cd ComfyUI/custom_nodes
git clone https://github.com/yogurt7771/ComfyUI-YogurtNodes.git
cd ComfyUI-YogurtNodes && pip install -r requirements.txt

Then restart ComfyUI. The requests dependency handles the HTTP. No model downloads - the remote server does the heavy lifting.

Where people get burned

Big one, and the knowledge base calls it out: ComfyUI's API is unauthenticated by default. Anyone who can reach the port can submit arbitrary workflows. Keep the server on your LAN or behind auth - do not point this at a public IP without protection, and don't leave a default-credential box exposed. Second: the workflow JSON is a snapshot. If the remote workflow changes - a node added, an id renumbered - your node references in the Set nodes go stale and the run fails in confusing ways. Re-export the workflow and update this node whenever you edit the remote. Third: timeout exists for a reason. A remote job that never completes will sit there polling forever if you leave it at 0; 120 seconds is a sane starting point, and raise it only when the remote genuinely needs longer.