Load Style Model (Any)
The loader behind Flux Redux
- any
- STYLE_MODEL
A style model is a small adapter that takes a CLIP vision embedding - the encoded output of a reference image - and turns it into conditioning a diffusion model can act on for style transfer or image variation. StyleModelLoader_Any just loads that adapter file; the actual work happens downstream, in a StyleModelApply-type node fed by both this loader's output and a CLIP Vision encode of your reference image.
Where you'll actually meet this node
The current headline use is Flux Redux, BFL's official image-variation model. Redux isn't a third-party IP-Adapter port - it uses SigLIP encoding through a 2-layer MLP, and by community comparison it's a genuinely strong performer at style transfer: one comparison thread found Redux paired with flux-depth-dev showed the strongest overall performance at carrying style over to a target image, out of everything tested.
One thing worth knowing before you build the workflow: Redux at full default strength tends to overwhelm the prompt rather than blend with it. Community testing settled on roughly 0.04–0.07 as the useful range - much lower than you'd guess - with anything higher turning into "just getting variations of the same image" rather than a controllable style transfer. That knob usually lives on the apply node downstream of this loader, not here, but it's the context you need before assuming this loader is doing something wrong when your output looks more like a copy than a style transfer.
The input and output
One required field: style_model_name, picked from your models/style_models folder. Output is a single STYLE_MODEL, which pairs with a CLIP_VISION output (from CLIPVisionLoader_Any or the stock loader) at the apply node - the style model alone does nothing without an actual encoded image to condition on.
The any input
Same trick as every loader in this pack: an optional any input that accepts anything and does nothing with the value - it only exists to force this node to wait for whatever feeds it before loading. ComfyUI's executor otherwise runs a loader the moment it can, usually immediately for a node with no required inputs from elsewhere in the graph, so without staging, your style model loads alongside everything else at graph start regardless of when it's actually consumed. Style-transfer workflows tend to already be VRAM-heavy - base checkpoint, CLIP vision encoder, and style model all in play at once - so this is a reasonable candidate to defer until right before the apply node needs it.
Installing it
ComfyUI Manager: search ComfyUI-LoaderUtils, install, restart. Manually:
cd ComfyUI/custom_nodes
git clone https://github.com/lrzjason/ComfyUI-LoaderUtils
No extra dependencies. Drop the style model file (Redux's, or an older SD-era style model) into models/style_models; it appears in the dropdown after a restart.
Where people get burned
Empty dropdown means the file isn't in models/style_models, or ComfyUI hasn't restarted since it landed there.
The more common real issue is a mismatch between the style model and the CLIP vision encoder feeding it - they're a matched pair for a given architecture, not interchangeable parts. Redux expects a SigLIP encoder specifically; feeding it the wrong CLIP vision model produces either an outright error or conditioning that runs but doesn't do what you expect. And, as above, if your style transfer looks like a near-identical copy of the reference image, check the strength on your apply node before assuming the loader or model file is at fault - Redux's default is simply too strong for most uses.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| style_model_name | COMBO | 0 options: | |
| anyopt | * | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| STYLE_MODEL | STYLE_MODEL | — |