XKleinRefConditioning

Getting a consistent character or style out of a modern backbone usually means bolting a reference-image mechanism onto the side - an IP-Adapter here, a face encoder there. XKleinRefConditioning takes a different, more architectural route: it encodes up to four reference images into the latent space and injects them into both the positive and negative conditioning chains as reference_latents. If your backbone reads reference_latents (the Klein family of models is the one named in the node's title), this is a remarkably clean way to pass reference images to the sampler - no separate adapter network, no extra weights.

How it works

The node takes positive_conditioning and negative_conditioning (both CONDITIONING) plus a vae, and up to four optional image_1 through image_4. For each connected reference image it:

1. Encodes the image with the VAE into a standard latent - vae.encode(image) → {"samples": ...}.
2. Appends that latent to the conditioning's reference_latents list via node_helpers.conditioning_set_values(..., append=True).

The append semantics matter: it's additive to whatever reference latents are already in the chain, and it applies the same reference to the negative chain too, so the model knows what it's not supposed to drift from as well as what to match. If no images are connected, the node is a straight pass-through - positive in, positive out - so you can leave it in the graph permanently and just connect references when you need them. If the conditioning inputs are missing it raises a clear error rather than silently running without context.

Why Klein specifically

The KB's writeup on the Klein architecture is the useful background: Klein (Flux.2's backbone and its derivatives) wraps your prompt in a chat template and stacks multiple hidden layers into the conditioning. It's an LLM-encoder design, not a CLIP design, and it's exactly the kind of model where reference latents travel through the conditioning chain natively. So this node is really "encode reference images and put them where the model already expects them" - which is why it's so much lighter than an adapter-based approach. If you're running a non-Klein backbone that ignores reference_latents, the node still runs but the references silently do nothing, which is the honest caveat.

Inputs and outputs

• positive_conditioning / negative_conditioning - the two chains to augment.
• vae - the VAE matching your model's latent space (this is the load-bearing detail - wrong VAE, wrong latent space, useless references).
• image_1 … image_4 - optional reference images.

Outputs: positive_conditioning and negative_conditioning, with reference latents appended when images were present.

Installing it

Part of ComfyUI-Xz3r0-Nodes. ComfyUI Manager: search ComfyUI-Xz3r0-Nodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Xz3r0-M/ComfyUI-Xz3r0-Nodes.git
cd ComfyUI-Xz3r0-Nodes
pip install -r requirements.txt

Restart ComfyUI. Pure PyTorch + ComfyUI internals - no extra deps for this node.

Gotchas

Two things bite people. First, the VAE must match your checkpoint's latent space - pair a Flux VAE with a non-Flux backbone and your reference latents encode into a space the model doesn't understand, producing garbage or nothing. Second, "Klein" is the promise; confirm your model actually consumes reference_latents before you build a workflow around it, because a silent no-op is the failure mode. And remember encoding happens once per reference per run - it's cheap, but it's real work on the VAE each execution.