CLIPMergeSubtract

CLIPMergeSubtract is the text-encoder version of ModelMergeSubtract: it subtracts one CLIP's weights from another's - clip1 − multiplier · clip2 - so you can remove an encoder's learned tendencies instead of just blending them away. If a checkpoint's text encoder was trained (or fine-tuned) into behaviors you don't want - a vocabulary bias, a style of interpreting certain words, an over-attachment to certain concepts - this is the node that lets you take that out arithmetically.

Let's be honest about how niche this is. Text-encoder subtraction is one of the least-used operations in the whole merging family, and for most people most of the time the correct answer is "don't." But it exists for the same reason ModelMergeSubtract exists: difference math on weights is how you remove contributions, and with a text encoder the contribution you're removing is often a fine-tune's baked-in interpretive bias. The LoRA-extraction idea carries over directly - if you have a base encoder and a fine-tune of it, base − fine_tune isolates what the fine-tune added (or, with a negative multiplier, what it took away).

How it works

Clone clip1, apply clip2's weights as a patch with the strengths flipped: clip1 scaled by multiplier, clip2 by −multiplier, giving result = multiplier · (clip1 − clip2). Like every CLIP merge in this family, the position_ids and logit_scale keys are skipped - structural and scaling constants aren't mergeable weights, and subtracting them would break the encoder entirely.

The multiplier range runs −10 to +10 precisely because direction matters: positive subtracts clip2's influence from clip1, negative flips the whole operation so you're effectively subtracting clip1 from clip2.

The inputs that matter

• clip1, clip2 (CLIP) - the two encoders.
• multiplier (FLOAT, default 1.0, −10 to +10, step 0.01) - subtraction strength and direction.

One CLIP out, into a CLIPTextEncode or a CLIPSave node.

Where people get burned

Same shape-mismatch wall as every merge - encoders must be architecturally compatible, same tokenizer family, same dimensions. And the over-subtraction trap is worse here than with diffusion models because a text encoder is smaller and easier to blow out: a multiplier that's a touch too high doesn't remove a bias, it turns the encoder into noise that produces garbage embeddings. Start at 1.0, step by 0.1, and test with real prompts after each change.

Also worth stating plainly: if you're subtracting because a checkpoint's refusal behavior is baked into the text encoder, subtraction thins it but rarely removes it - those behaviors live across the whole pipeline, not just in a subtractable slice of weights.

How you get it

Core ComfyUI, model/merging category, ships with the program. No installation.