KV_Edit_PreData

If KV_Edit_Load is the engine, KV_Edit_PreData is where you tell the car where to go. It takes your image, your mask, your VAE and CLIP, plus two prompts - and packs all of it into one condition bundle that KV_Edit_Sampler will later unpack. It's the node you'll actually spend your time in, because the two prompts are the editing interface.

Here's the mental model that makes KV-Edit click, and it's genuinely different from img2img: the source_prompt describes what's in the image right now, and the target_prompt describes the edit you want. The sampler uses the source prompt to guide an inversion pass of your image (so the model can re-find the exact latents and attention features of the original), then regenerates only the masked region toward the target prompt while reusing the background's cached keys and values. The better your source prompt matches the actual image, the cleaner the edit - write it like you're captioning the photo for someone who can't see it. This is the same reason people still reach for mask-based editing over whole-frame edit models, per the KB's inpainting essay: the unmasked background comes back bit-for-bit, not "close enough."

What it needs

All six inputs are required:

• clip - your Flux CLIP (DualCLIPLoader with clip_l.safetensors + t5xxl_fp8_e4m3fn.safetensors, type "flux").
• vae - ae.safetensors via VAELoader.
• image - the photo you're editing.
• mask - a MASK tensor the same size as the image. Anything above 0 becomes the edit region; white = change this, black = leave alone.
• source_prompt / target_prompt - the pair above, both multiline.

One output: condition (CONDITION_KV), which carries the encoded source and target latents, the processed mask, both prompts, the image dimensions, and the loaded VAE. It all rides one wire into the sampler.

What it does to your inputs

The source code shows three quiet transformations you should know about before they bite you:

It crops your image. Height and width are silently truncated down to the nearest multiple of 16 before encoding (shape[0] - shape[0] % 16). A 513×513 image becomes 512×512. The example workflow dodges this by scaling to a clean 512×512 first with an ImageScale node - do the same, because discovering the crop after a slow Flux pass is annoying.

It encodes the image, not you. The image is pushed through the Flux autoencoder into latent space (bfloat16), and the mask is cropped to match and thresholded to 0/1. The white region is what gets regenerated; everything else is preserved from the source.

It encodes both prompts through your ComfyUI CLIP, including the tokenizer bumped to a 512-token context - that's the full T5-XXL sequence, so long natural-language captions work.

Gotchas

Like its sibling loader, this node clears ComfyUI's loaded models and cache once it's done encoding - it's grabbing a lot of VRAM for the encode, then handing the results off. That's expected behavior, not a leak.

The other recurring trap is prompt quality. KV-Edit "works well with curated prompts," as one user of the sibling Klein-2 KV-Edit workflow put it - sloppy source prompts produce edits that drift because the inversion guidance has nothing accurate to latch onto. Default the source to an accurate caption of the image, target to the smallest change that expresses the edit, and let the mask do the spatial scoping. Two good sentences beat a paragraph of tags here.