LucidFlux VAE Patch (F16)

A node with one input, one output and no settings should not need a page. But LucidFlux VAE Patch (F16) is the kind of node that produces the single most confusing symptom in the whole pack - a 1024 latent that decodes to 1024 pixels when you were expecting 2048 - and nothing in the UI tells you why.

So: what's it for.

Flux VAE is /8. UltraFlux VAE is /16.

A normal Flux VAE compresses 8 pixels into 1 latent pixel. ComfyUI hard-codes that assumption when it loads one, and it's correct for ae.safetensors. The VAE LucidFlux's official pipeline uses is UltraFlux's, which is symmetrically 16× - 16 pixels per latent pixel in both directions. The README's file layout even ships it under vae/UltraFlux.safetensors with a note that you can swap in plain ae.safetensors for 1K work.

Load UltraFlux through a normal VAELoader and ComfyUI will treat it as /8. It won't error. It will decode your latent correctly as far as the network is concerned, and then hand you an image half the size it should be, because the upscale ratio it reported to the rest of the graph was wrong.

That's what this node corrects. Internally it does two things: sets the encoder's conv_in stride to 2, and wraps the decoder's final conv_out in a shim that does a nearest-neighbour ×2 interpolate before the convolution. Then it tells the VAE object its downscale and upscale ratio are 16 instead of 8.

The F16 in the display name is that 16×, not a float16 dtype. Nothing about precision here.

Wiring

Input vae, output VAE. It sits between VAELoader and VAEDecode:

VAELoader (UltraFlux.safetensors) → LucidFlux VAE Patch (F16) → VAEDecode → LucidFlux Color Align

That's it. No parameters, because there aren't any to get wrong.

If you're running the 4K branch through LucidFluxPiDDecode instead of a VAE decode, you still want this in the graph for the 2K preview path - PiD eats the latent directly and doesn't touch your VAE at all. And if you genuinely are doing 1K work with ae.safetensors, you can leave the node bypassed. It's patching a mismatch that only exists because of the UltraFlux checkpoint.

Install

Standard pack install, and this node has no model requirements of its own:

cd ComfyUI/custom_nodes
git clone https://github.com/smthemex/ComfyUI_LucidFlux

Restart. You'll find it under the LucidFlux category. The VAE file you actually feed it comes from Owen777/UltraFlux-v1 and belongs in ComfyUI/models/vae/ - renamed or not, the README says it doesn't care, and unlike the pack's other dropdowns this one isn't filtering filenames.

What goes wrong

You forgot it and everything looks fine. This is the real trap. There's no error, no warning, no red node. You get a 1024px image from a 2048px workflow, decide the model is weak, and go read up on step counts. If your LucidFlux output resolution doesn't match the empty latent size you set, check this node before anything else.

You expected it to fix a colour shift. It doesn't. Half-resolution and colour drift are two separate known issues with this pipeline; this handles the first, LucidFluxColorAlign handles the second.

You're mixing it into a non-LucidFlux workflow. Don't, casually. It mutates the VAE object in place - encoder stride, decoder output, reported ratio - and once patched, that VAE stays patched for every other branch in the graph that shares it, whether or not those branches wanted /16. The node guards against double-patching itself, which is nice, but it means "I'll just try it and undo it" doesn't really work without reloading the VAE.

The honest framing: if you're doing anything outside this pack's own example pipeline, this is the node to be suspicious of. Inside the pipeline, it's mandatory and you should stop reading and go wire it up.