Apply IPAdapter Flux Model

This is where the reference image actually starts influencing your generation. IPAdapterFluxLoader just loads files into memory; this node is the one that takes your Flux model, patches it with the adapter, and hands back a model that now "sees" your reference image every time it runs a step. Wire the output straight into your KSampler chain like you would with a LoRA loader - same pattern, different mechanism.

How it works, briefly

Classic IP-Adapter injects your reference image through its own dedicated cross-attention path that runs alongside the model's normal text-conditioning path, so the two coexist instead of one overriding the other. InstantX's Flux build (this pack) follows the same shape but with a SigLIP encoder instead of OpenCLIP, since Flux's architecture doesn't share SD's conditioning setup. The upshot for you: your text prompt keeps doing its job, and the reference image nudges the result toward its style, composition, or general appearance on top of that - it doesn't replace the prompt.

Worth setting expectations honestly: the adapter's own model card says it isn't built for fine-grained style transfer or tight character consistency, and that tracks with what people report - genuinely striking results for some, "the SD 1.5 era version of this was better" from others who now reach for PuLID-Flux (faces) or Redux (BFL's own style/variation adapter) instead. Some community comparisons between Redux and this pack found Redux less prone to "overfitting" the reference at high strength. Worth trying both if style transfer is your actual goal.

The inputs that matter

• ipadapter_flux - the bundle from IPAdapterFluxLoader (or its Advanced sibling - either works, they output the same type).
• image - your reference image. This is what the adapter encodes and injects.
• weight (default 1, range -1 to 5) - how strongly the reference pushes the result. This is the one knob you'll actually tune. Push too high and the reference starts overriding your prompt entirely; too low and it barely registers. Start around 0.5–0.8 and adjust from there - negative weights exist in the range but are an edge case, not the default move.
• start_percent / end_percent (default 0 and 1, i.e. the full schedule) - what portion of the sampling steps the adapter is active for, as a fraction. This is the practical fix for the most common IP-Adapter complaint across every version of it: running the adapter across all steps measurably softens fine detail. Set end_percent to something like 0.6–0.8 to cut it off before the late denoising steps and you'll keep more sharpness while still getting the reference's influence early on.

The output

A single MODEL - your Flux model, now patched with the adapter. Feed it straight into your sampler the same way you'd feed in a LoRA-patched model. No other node in your graph needs to change.

Installing it

Via ComfyUI Manager: search ComfyUI-IPAdapter-Flux, install, restart. By hand:

cd ComfyUI/custom_nodes
git clone https://github.com/Shakker-Labs/ComfyUI-IPAdapter-Flux
cd ComfyUI-IPAdapter-Flux
pip install -r requirements.txt

You'll also need the model files, which aren't bundled: InstantX's FLUX.1-dev-IP-Adapter weights into ComfyUI/models/ipadapter-flux, and the google/siglip-so400m-patch14-384 vision encoder into ComfyUI/models/clip_vision (or let it pull from the HuggingFace cache automatically). Restart after both are in place.

Where people get burned

The single biggest one: expecting this to hold a specific face the way PuLID or ACE++ does. It won't - that's not a bug, it's the adapter doing exactly what its own documentation says it's for, which is broader appearance/style guidance, not identity lock. If a face keeps drifting away from your reference, that's the tool's actual limit, not a setting you missed. Second: if the output looks like it's mostly ignoring your prompt and just recreating the reference image, drop weight and/or pull end_percent down - that combination controls both how strong the pull is and how long it lasts. And the standard custom-node landmine still applies: this pack's requirements.txt shares your Python environment with every other node you've installed, so a transformers version clash is a more likely explanation for an install failure than the node itself being broken.