Dynamic Model Switch (Creepybits)

The Dynamic Model Switch is the flagship of the pack's "dynamic" switch family, if only because it has four slots instead of three. It passes through the first MODEL input that has something connected - model1 beats model2 beats model3 beats model4 - and hands it out the other end. No selector widget, no configuration, no active choice. It's a fallback chain for checkpoints, and it's quietly the most practical node in the bunch for shared workflows.

Why a model fallback is useful

Models are big, slow to load, and usually the thing that decides whether a workflow runs at all. A priority chain for checkpoints lets you build "use this if you have it, otherwise use that" without branching your whole graph:

• Shared workflows. The workflow author runs Flux; a friend running the same graph only has SDXL. Wire Flux into model1, SDXL into model2, and each person gets whichever checkpoint their setup can actually load.
• VRAM-aware degradation. Wire your premium model first, a quantized/GGUF version second, and a tiny model last. The chain silently picks the best one available to this machine.
• Multi-mode experiments. Have four checkpoints you rotate through for style tests - the priority chain means you disable/enable by disconnecting, not by editing an index.

Outputs are MODEL and the pack's standard show_help string (proverb-of-the-day gag, not help).

The trade-off vs. an active switch

You need to be clear-eyed about the naming. "Dynamic" here does not mean "switches at runtime based on a value" - it means "passes the first connected input." If you want to actively toggle between two or more connected checkpoints with a click, you want an indexed model switch (a "Multi" style switcher with an integer input) - the pack's Multi Model Switch handles that pattern. The Dynamic switch is for priority, not choice. Positional priority also means model1 always wins, so wire your actual favorite into slot 1, or you'll keep getting results that feel "wrong" for no visible reason.

The None trap

All four slots empty → None out, which a KSampler will not accept. The model input is downstream-essential, so always keep at least one slot fed - treat model4 as your guaranteed "this always works" default. Also note the state is stateless: nothing is remembered between runs, which is fine, because a fallback chain shouldn't need memory.

Installing it

It's part of the Creepybits pack, installed all at once:

cd ComfyUI/custom_nodes
git clone https://github.com/Creepybits/ComfyUI-Creepy_nodes.git

Restart ComfyUI, or find "Creepy" in ComfyUI Manager. No model downloads; the pack's requirements install on first launch. If you share workflows with people on different hardware, this is the node that keeps your shared graph running on all of them.