RemRun Start From Here ->

Here's the thing people miss about RemRun Input Graph(s): by default it ships everything upstream of it to the remote machine. Your local GPU does nothing, and you end up paying the network cost to move a graph you could have run in place. That's a waste - especially if the cheap part (loading an image, building a prompt) is trivial and the expensive part (VAE decode of a video latent) is the only thing your machine can't handle.

RemRun Start From Here is the boundary marker that fixes it. Drop it into the middle of a graph and it splits the run: everything upstream of the Start node runs locally, and only the nodes between the Start node and a RemRun Input node get shipped to the remote. Cheap stuff stays home, heavy stuff travels. It's the difference between offloading your whole workflow and offloading just the one step that needs the big GPU.

How it works

When a RemRun Input node expands your graph for the remote, it walks upstream and stops at every Start node it finds. The remote prompt gets only the nodes after those boundaries. Each Start node is then replaced on the remote side with a Deserializer node, which receives the local values from the Start node's inputs - serialized and shipped over as part of the remote prompt.

So the data flow is: local nodes compute → values get serialized at the Start boundary → the remote subgraph receives them through its Deserializer stand-ins → computes → sends results back through the Input node's serializer. The Start node is where local hands the baton to remote.

The inputs that matter

• outputs_when_local - what happens if something downstream of the Start tries to use its outputs locally. Default is error, which is correct but unforgiving: the whole run dies with "output used locally, but outputs_when_local is set to 'error'". If you want the graph to survive, set passthrough (pass the values through) or block_execution_silent / return_none for the other flavors.
• inputs_when_local - default disconnected, meaning the Start's inputs are cut off locally so nothing upstream of it tries to compute in the remote run. Set to lazy for the other behavior.
• lazily_transfer - from_input_node (inherit the Input node's setting), or force on/off. skip_lazy_transfer_under_mb (default 0.25) keeps small values out of the lazy path so they always go directly.
• remote_run_dependent_outputs - ignore or run; when run, other nodes hanging off the middle of the remote subgraph also get executed remotely.

Ten wildcard inputs, ten wildcard outputs.

Where people get burned

The outputs_when_local error is the #1 confusion. You build a graph with a Start node, wire its outputs into a local preview node, run it, and get a hard error - because those outputs are supposed to live on the remote side now. Either rewire so the Start's outputs only feed the remote path, or set outputs_when_local to passthrough if you genuinely need them locally too. And the usual pack rules still apply: both machines need the pack installed, video jobs need total_timeout raised well past the 90-second default, and there's a live browser session needed on the local side for the binary response to have somewhere to land.

Install on both instances is the standard two-liner:

cd ComfyUI/custom_nodes
git clone https://github.com/LatentRat/comfy_remote_run

or ComfyUI Manager → "comfy_remote_run". Just websockets and requests as dependencies - no models, no extra files. This node plus RemRun Input is the combo that makes the "offload text encoder and VAE" setup from the README actually work the way you want it to.