Nodes/Mecha Merge Node Pack/Clamped Add Opposite
ComfyUI Node

Clamped Add Opposite

Add a difference but refuse to leave the [A, B] band — the 'safe transplant' merge

By ljleb·Created 2 years ago·Updated 30 days ago· 101
Clamped Add Opposite
  • a (delta|param|weight)
  • b (delta|param|weight)
  • c (delta|param|weight)
  • alpha (1.0)
  • recipe
merge_checkpointingfalse

Clamped Add Opposite is the version of add difference that refuses to overshoot. Where plain Add Difference computes A + alpha*(B − C) and lets the result wander wherever the math takes it, this node clamps every tensor so it stays between A and B, element by element. The name "opposite" comes from the older convention: B is the fine-tune, C is the anchor/base both A and B derive from, and the delta B − C is "opposite" in the sense that you're transplanting the change from one model onto another.

The README's own example workflow calls this "clipped add difference," and it's the poster child for the pack - a merge that keeps you inside the box both parents occupy, which is exactly the guardrail people want when they're afraid a merge will produce something degenerate.

How it works

result = clamp(A + alpha*(B − C), min(A, B), max(A, B)), per key, per element. The clamp is the whole point: if the delta pushes a value past the range either parent had, it's pulled back to the nearer parent's value instead of left to drift. With alpha = 1.0 (the default) you get the full clipped add. Lower alpha softens the whole thing.

Inputs from the schema:

  • a (delta|param|weight) - the starting point, usually your base model in weight space.
  • b (delta|param|weight) - the model you're stealing the change from.
  • c (delta|param|weight) - the anchor both A and B are relative to; often the shared base.
  • alpha (1.0) - strength, itself a MECHA_RECIPE, so you can feed it a Float for a flat value or Blocks Mecha Hyper for per-block weighting.
  • merge_checkpointing - leave off unless you're rerunning a heavy graph and want the branch cached on CPU in fp16.

Output is one recipe (MECHA_RECIPE) → Mecha MergerMODEL/CLIP/VAE.

When to reach for it

The classic setup: you have a base model, a fine-tune built on it, and a third model you want the fine-tune's behavior transplanted onto. C is the shared base, B is the fine-tune, A is the target. Clamping keeps the result expressible as "between A and B everywhere," which sounds restrictive and is - that restriction is what prevents the usual add-difference failure mode of drifting into noise outside either model's range.

If you don't want the clamp, use plain Add Difference Mecha Recipe. If you want the clamp but with a custom bound set rather than "between A and B," that's what Clamp Mecha Recipe plus a Recipe List is for.

Install & gotchas

ComfyUI Manager → search mechaMecha Merge Node Pack, or:

cd ComfyUI/custom_nodes
git clone https://github.com/ljleb/comfy-mecha.git
pip install -r comfy-mecha/requirements.txt

Restart; only dependency is sd-mecha==1.1.7.

Where people burn themselves: forgetting that A and B both need to be weight-space recipes (the clamp requires A and B in the same space - the pack raises a type error if they aren't), and assuming the clamp means alpha can't overshoot. It can - the clamp bounds the result against A and B, so alpha = 2 still clamps, but you're forcing it against the wall everywhere and the output looks like a hard-cropped version of the blend. Keep alpha in the 0.5–1.0 range unless you know why you don't.

Categorymecha

Inputs (5)

NameTypeDefaultDescription
a (delta|param|weight)MECHA_RECIPE
b (delta|param|weight)MECHA_RECIPE
c (delta|param|weight)MECHA_RECIPE
alpha (1.0)optMECHA_RECIPE1
merge_checkpointingoptBOOLEANfalseSpeeds up an entire branch of a merge graph that does not change often in exchange of memory. - true: store the first output of this recipe node on cpu memory in fp16. On subsequent workflow executions, as long as the inputs do not change, the cached keys are returned after being cast to the original device and dtype. - false: do not store the output. The recipe and its inputs will re-execute on subsequent workflow executions. Note that the memory used to checkpoint the output is distinct from the cache feature. In general, you probably want to either use this *or* a cache unit, but not both at the same time because the memory adds up. The difference between merge checkpointing and cache is that merge checkpointing completely re-merges from scratch if any input changes. Merge checkpointing is also generally much faster than cache in the fast path.

Outputs (1)

NameTypeDescription
recipeMECHA_RECIPE