Clamp
Squash any merge into the box you define — bounds as a recipe list, stiffness as a dial
- a (delta|param|weight)
- bounds (delta|param|weight)
- stiffness (0.0)
- recipe
Clamp Mecha Recipe is the general version of the guardrail that Clamped Add Opposite hard-codes. Where that node always clamps between its two inputs, this one clamps any recipe into a bound set you provide - as a MECHA_RECIPE_LIST - with a stiffness dial that controls how hard the clamp bites. If you've ever merged something and thought "that's a nice blend except for the outliers," this is the node that kills the outliers.
How it works
Element-wise, clamp(a, min(bounds), max(bounds)): every value of a that dips below the lowest bound is pulled up to it, every value above the highest bound is pulled down. With multiple bounds, the effective range is [min of all bounds, max of all bounds] - so the bounds list is really describing a box.
The interesting knob is stiffness (default 0.0):
0.0- plain clamp against the outer min/max of your bounds.- As stiffness rises toward 1.0, the clamp tightens toward the innermost bounds that surround the average of the bound set, instead of the outer extremes. High stiffness means the result hugs the "common area" of all your bounds rather than their widest span. This is the "clipped" behavior made continuous - you can push from permissive to restrictive without a hard switch.
Inputs from the schema:
a (delta|param|weight)- what you're clamping.bounds (delta|param|weight)- aMECHA_RECIPE_LIST(default empty); build it withMecha Recipe Listfrom however many bound recipes you want.stiffness (0.0)- the dial above.merge_checkpointing- cache-the-branch toggle; leave off unless re-running a heavy graph.
Output: one recipe (MECHA_RECIPE).
Where it fits
The natural use is taming the output of an aggressive merge: take a blended recipe, feed it into a, feed your parent models (or any reference set) into bounds, and the result is guaranteed to stay within the region your references occupy. You can also chain it after Add Difference when you want to decide the clamp region instead of inheriting "between A and B" from Clamped Add Opposite.
Install & gotchas
ComfyUI Manager → search mecha → Mecha 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.
The recurring foot-gun: the bounds socket is a MECHA_RECIPE_LIST, not a single recipe - a lot of people wire one model in and wonder why the node complains. Route it through Mecha Recipe List (set count to the number of bounds) and you're set. And an empty bounds list is legal but means "clamp against nothing," so the node passes a through unchanged - if your clamp is doing nothing, check that the list actually has entries.
Inputs (4)
| Name | Type | Default | Description |
|---|---|---|---|
| a (delta|param|weight) | MECHA_RECIPE | — | |
| bounds (delta|param|weight)opt | MECHA_RECIPE_LIST | — | |
| stiffness (0.0)opt | MECHA_RECIPE | 0 | — |
| merge_checkpointingopt | BOOLEAN | false | Speeds 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)
| Name | Type | Description |
|---|---|---|
| recipe | MECHA_RECIPE | — |