ApplyFluxFillPatch

If you've ever tried to use a LoRA with FLUX.1 Fill dev, you already know the problem: Fill is a full 12B checkpoint, it needs its own ~23GB download, and - this is the kicker - it just doesn't play well with LoRAs at all. "Flux Fill hates Flux Dev character Loras" has been a community refrain since November 2024, and it's why you'd reach for this node.

ApplyFluxFillPatch makes base Flux dev behave like Fill, so you keep your character LoRAs, your stylized checkpoints, your whole existing dev stack - and still get masked inpainting. It's the required companion node for the CivitAI "Flux.Fill - Inpaint LoRA" (model 981615, by SeniorPioner), and it's about as small and single-purpose as a custom node gets.

What it actually does

This is a "patcher," not a LoRA loader. The pack ships a 35MB fill_state.safetensors file right in the repo, containing the Fill model's conditioning-projection weights - img_in, txt_in, the timestep and vector embed layers. When you run the node, it clones your Flux model's patcher and swaps those specific weights into base dev at inference time, backing up the originals and restoring them when sampling ends.

That swap is exactly what base dev is missing. The real giveaway: Fill's img_in.weight is [3072, 384] while base dev's is [3072, 64] - a different input shape, because Fill takes a masked image as conditioning. That shape mismatch is literally why you can't just drop dev LoRAs onto the Fill checkpoint (trainers blow up with size mismatch for img_in.weight), and it's why this node exists as a weight-swap rather than a merge.

The inputs that matter

• model - your Flux dev MODEL. This is the only thing you really feed it.
• img_in (default on) - the masked-image branch. This is the one that actually teaches dev to inpaint. Leave it on.
• txt_in (default on) - the text-conditioning adjustment.
• vector_in.in_layer / out_layer and time_in.in_layer / out_layer (all default on) - the rest of the Fill conditioning patch. Leave them on. The only reason to touch these is if you're debugging or want to isolate what each layer contributes.

It outputs a single MODEL, which you wire straight into your normal masked-inpaint chain: InpaintModelConditioning (or SetLatentNoiseMask) → sampler → decode → composite. The official workflow is embedded as a PNG on the CivitAI model page, so that's your reference if you want to see the exact graph.

Installing it

ComfyUI Manager: search ComfyUI-flux_fill_patcher and install. Or by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/bananasss00/ComfyUI-flux_fill_patcher

Restart ComfyUI. That's it - no requirements.txt, no extra model downloads, because the weights are already in the repo. You still need the full Flux dev checkpoint (plus CLIP and VAE) for the workflow itself.

Where people get burned

Expect a quality hit. The CivitAI page says it plainly: extracted-LoRA results are "lower quality compared to using a full checkpoint." This is the pragmatic option, not the best-quality one. If you don't need LoRAs at all, just use real FLUX.1 Fill dev (or its OneReward fine-tune) and skip this node entirely.

Composite after inpainting. Same rule as every Flux inpainting workflow: every VAE encode/decode degrades the image, so paste the inpainted region back over the original with ImageCompositeMasked (or use the Inpaint Crop and Stitch pair) instead of letting the whole image round-trip.

Don't fight the mask conditioning. Feed the masked image through the proper conditioning nodes - the whole point of this patch is that dev now understands mask conditioning, so actually give it one. A plain empty latent defeats the purpose.

One thing this node can't fix: it only makes dev fill. If your actual goal is whole-frame instruction editing, that's what Qwen-Image-Edit or Flux 2 Klein are for - masked inpainting is the corner where the old faithful still beats them, and this node is the cheapest way to keep using it with your dev LoRAs.