CLIPMergeSimple

CLIPMergeSimple is ModelMergeSimple's text-encoder twin: it blends two CLIP models into one with a single ratio. You've probably never needed it - most people never touch text-encoder merging - and then you hit one of the situations where it's the only tool that works, and suddenly it's indispensable.

The mechanics mirror ModelMergeSimple exactly: clone clip1, patch clip2's weights on top, so each weight becomes ratio · clip1 + (1 − ratio) · clip2. There's one meaningful difference: the node skips the position_ids and logit_scale keys. Position embeddings are structural - averaging them corrupts the token positions a text encoder relies on - and logit_scale is the CLIP contrastive scaling constant, not a "blendable" weight. So the merge is the "real" learned weights only, which is also what makes the interesting trick possible.

The trick is the Z-Image / Qwen3 encoder swap, and it's a genuine community discovery (a real thread about it ran in early 2026): Z-Image expects a Qwen3-4B text encoder and throws a mismatch error if you plug in the 8B directly, but running the 4B and 8B encoders through CLIPMergeSimple sidesteps the check. The merged encoder keeps the 4B structure the model demands while pulling in some of the 8B's behavior - and since the diffusion model only enforces the encoder's size, the merge passes. People report noticeably better prompt adherence. Is it a clean upgrade or a happy accident? The thread itself couldn't agree. But it works, and it's the kind of thing only a merge node can do.

How it works

result = ratio · clip1 + (1 − ratio) · clip2, applied per weight tensor, position embeddings and logit_scale excluded. Ratio defaults to 1.0 = pure clip1. Nothing is saved - you get a patched CLIP you can wire straight into a CLIPTextEncode.

The inputs that matter

• clip1, clip2 (CLIP) - the two text encoders. Feed them from Load CLIP nodes.
• ratio (FLOAT, default 1.0, 0–1, step 0.01) - the blend. 1.0 is all clip1.

One CLIP out.

Where people get burned

Shape mismatch is the hard wall: the two encoders must have compatible weight shapes, and the moment they don't you get errors (the Z-Image trick only works because the 4B and 8B share enough structure). Don't expect to blend a CLIP-L with a T5 - different tokenizers, different dimensions, no merge.

The subtler gotcha: merging text encoders that were trained on different tokenizers or vocabularies is mixing two different languages of tokens, and the result can degrade prompt adherence even when shapes line up. If a merged CLIP produces nonsense, that's the cause, not a bug in the node.

How you get it

Core ComfyUI, model/merging category, ships with the program. In the same family: CLIPMergeSubtract for difference math on encoders, CLIPMergeAdd for pure addition - but for the blend, this is the one.