CLIPMergeAdd
Adding text encoders together, the bluntest of the CLIP merges
- clip1
- clip2
- CLIP
CLIPMergeAdd is the text-encoder version of ModelMergeAdd: it adds two CLIP models' weights together - clip1 + clip2 - with no ratio and no attenuation. It's the least-used node in the CLIP merge trio, and for good reason: addition is the least safe operation you can do to a pair of trained encoders, and there's no knob to soften it.
To be straight about it, this node sits in a strange spot. CLIPMergeSimple (the blend) has a real, documented community trick - the encoder-swap that dodges Z-Image's shape-mismatch errors. CLIPMergeSubtract (the difference) has a real purpose in removing baked-in encoder tendencies and isolating fine-tune contributions. Addition has... compounding. You'd use CLIPMergeAdd when you genuinely want two encoders' contributions to stack - the text-encoder analogue of the multi-LoRA stacking workflow - and that's a narrow, expert-only case. Most people will never have a workflow that calls for it, and that's the correct state of affairs.
How it works
Same machinery as the rest of the family: clone clip1, apply clip2's weights as a patch at full strength - both strengths 1.0 - so every weight becomes clip1 + clip2. The position_ids and logit_scale keys are skipped, same as every CLIP merge, because averaging or adding positional tables and the contrastive scaling constant would corrupt the encoder's structure rather than blend it. That's the only safety guard this node has, and it's doing a lot of work.
No ratio input exists because there's no partial state. It's all-or-nothing addition.
The inputs that matter
clip1,clip2(CLIP) - the two encoders.
One CLIP out. That's the entire input/output surface.
Where people get burned
The failure mode is predictable and it's the same one ModelMergeAdd has: two full-strength encoders added together is not a better encoder. Weight magnitudes balloon, embeddings drift out of the range the diffusion model expects, and the result is often a CLIP that "works" (no error) while producing worse prompts than either parent - the silent, worst kind of failure, because there's no loud error to tell you it went wrong.
The other trap is the shape-mismatch wall: encoders with different dimensions or tokenizer families can't be added, and ComfyUI will not rescue you. Same architecture, same tokenizer, same shapes - otherwise the merge fails before it starts.
The honest guidance: if you think you need CLIPMergeAdd, first ask whether a blend (CLIPMergeSimple) would do it. Addition is for the rare case where you're deliberately stacking small, known deltas - and even then, verify with real prompts, because nothing in this node will warn you when you've built a worse encoder.
How you get it
Core ComfyUI, model/merging category, ships with the program. No installation.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| clip1 | CLIP | — | |
| clip2 | CLIP | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| CLIP | CLIP | — |