Modal Universal Executor

If you've loaded a downloaded workflow that runs on the cloud via Modal Sync, you've probably found a node called "Modal Universal Executor" sitting in the graph and wondered what it does. The honest answer: not much, for you. It's the pack's debug entrypoint - the reference version of the proxy node the extension generates automatically when you mark parts of a workflow to run on Modal. You are not supposed to wire it up by hand, and if it's in a workflow you downloaded, it's a leftover from someone's remote run.

Here's the background. Modal Sync works by rewriting your queued workflow: any node you mark Run on Modal gets partitioned into a "remote component," and that component is replaced at queue time with one or more generated proxy nodes named ModalUniversalExecutor_<hash>. Those generated variants are signature-preserving - they keep the original node's inputs and outputs so the rest of your graph doesn't know anything changed. The plain ModalUniversalExecutor class in this pack is the base version, marked dev-only and experimental in the source, used for debugging the routing itself.

That's also why you keep tripping over it. The pack's README is blunt: workflow files saved after a remote run may include these internal proxy nodes, and they "should not be treated as clean source workflows." They're useful as regression fixtures for the author, not as something to share or rebuild on. If a workflow you grabbed shows ModalUniversalExecutor nodes, treat them as scaffolding - either delete the remote-marked region and rebuild it, or just don't expect the graph to make sense until you know the whole thing was authored with Modal Sync in mind.

Mechanically, it's the thinnest node in the pack: one input, one output, both of type *.

• original_node_data - the serialized payload for the node that should run remotely. If it arrives as a JSON string, the executor parses it; otherwise it treats it as a dict.
• output - whatever the remote execution returned, passed straight through as a normal ComfyUI output.

At execution time it hands that payload to the configured remote-executor client, which is a local mirror in local mode or the Modal-backed worker in remote mode. That's the whole show.

Installation is the same as the pack, because this node is the pack. In ComfyUI Manager search for "Modal Sync" (ttulttul/ComfyUI-Modal), or clone it into custom_nodes/ and restart:

cd ComfyUI/custom_nodes
git clone https://github.com/ttulttul/ComfyUI-Modal

You don't install it separately, and there's no reason to. The author - the same ttulttul behind the ComfyUI-Iterative-Mixer pack - has been building workflow tooling for a while, but this particular node is internal plumbing. If you're debugging the pack itself and want a fixed reference proxy to step through, sure, this is your entrypoint. For actual use, the real proxies are the generated ModalUniversalExecutor_<hash> variants, and you never touch those either.

So the practical takeaway: when this node shows up in your searches or your saved JSON, don't reach for it. If it's breaking a workflow you downloaded, the fix is usually not to fix the node - it's to re-derive the workflow without the cloud leftovers. Watch for the more useful errors around the rewrite instead: boundary-validation failures on non-transportable values like MODEL or VAE, and the occasional Dependency cycle detected message, both of which leave diagnostics in comfy.log.