Configurable Model Router
Pick a model by condition, driven by a JSON map
- model_1
- model_2
- model_3
- model_4
- model_5
- MODEL
Most Flux workflows end up with several models loaded at once - a base model, a fill model for inpainting, a depth or canny model for ControlNet work - and the graph grows a tangle of "which one do I actually use today" logic. Configurable Model Router collapses that into one node: you feed it up to five models, give it a condition string, and it hands back the model your JSON config says matches. It's the flexible, user-editable cousin of the pack's FluxContinuumModelRouter, introduced in the 1.7.0 update.
How it works
The node holds two things on its face: a condition string and a routing_config JSON blob. The JSON maps condition strings to input indices - the default config ships as:
{
"default": 1,
"inpainting": 2,
"depth": 3,
"canny": 4
}
At execution it looks up condition (lowercased) in the config, falls back to "default" if nothing matches, and routes to model_<index>. So condition "depth" → model_3.
The clever part is lazy loading: each MODEL input is marked lazy, and the node's check_lazy_status only requests the one model it actually needs based on the condition. Connect five checkpoint loaders to it and only the selected model ever gets loaded into VRAM - the pack's "only activates nodes and models required for current task" philosophy, implemented properly. Note that laziness means your model loaders must actually support lazy inputs for the skip to happen; if a loader isn't lazy-aware, it loads anyway.
Inputs and outputs
- condition -
STRING(single line). What you're doing right now, e.g."inpainting","depth","canny", or anything your config defines. - routing_config -
STRING(multiline), the JSON map. - model_1 … model_5 - optional
MODELinputs, lazy.
Output is one MODEL - the routed model.
Installing it
Ships in robertvoy/ComfyUI-Flux-Continuum:
cd ComfyUI/custom_nodes
git clone https://github.com/robertvoy/ComfyUI-Flux-Continuum
or ComfyUI Manager ("Flux Continuum"), restart. No extra dependencies.
Where people get burned
The config is plain JSON - a stray trailing comma or a missing quote makes it silently do nothing (the code swallows parse errors and just requests nothing). If the node returns nothing or errors "input model_X is required... not connected", check your JSON first, then check that you've connected a model to the index the config references. And remember conditions are matched lowercased and trimmed - "InPainting" still matches "inpainting", but "inpaint" does not match "inpainting". That exact-match behavior is the #1 cause of "it ignored my condition" complaints.
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| condition | STRING | default | — |
| routing_config | STRING | { "default": 1, "inpainting": 2, "depth": 3, "canny": 4 } | — |
| model_1opt | MODEL | — | |
| model_2opt | MODEL | — | |
| model_3opt | MODEL | — | |
| model_4opt | MODEL | — | |
| model_5opt | MODEL | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| MODEL | MODEL | — |