Clip Reshaper: Pad/Slice Dim

This is the "make the numbers fit" button, and it deserves to come with a warning label. Clip Reshaper: Pad/Slice Dim takes your conditioning and forcibly changes its last dimension to whatever you ask for - by slicing it down or zero-padding it up. It will make a matrix multiplication stop crashing. It will not make your image good. The author is refreshingly upfront about this: the README says flat out that blindly cutting or padding embeddings "can degrade or distort the semantic information."

How it works

Here's the mechanism, and it's simple enough to hold in your head. Each conditioning tensor's last dimension is its embedding size D - 768 for SD 1.5's CLIP, 1280 for SDXL's OpenCLIP-G, something else for every new LLM-style encoder. If D is bigger than your target_dim, the node slices the tensor to t[..., :target] - keeping the first chunk of the vector and throwing the rest away. If D is smaller, it concatenates zeros to reach the target. If they already match, it passes the tensor through unchanged. Metadata on each conditioning item is carried along untouched.

Inputs

The inputs: conditioning, plus target_dim (INT, default 1280, range 1–65536). That default hints at the intended use case - 1280 is the SDXL dimension, so the pack's author had "bend something into SDXL shape" in mind. The single output is a CONDITIONING you can wire straight back into the sampler.

When it's useful - and when it's a trap

So when is this legitimately useful? When you're doing experimental vector math, feeding a debug node that demands a fixed size, or building scaffolding for a cross-encoder pipeline where you know you're going to replace the brute-force reshape with something learned later. That last case is the pack's own stated niche: these utilities are aimed at cross-model CLIP adapter work, where sometimes you just need shapes to agree so you can see what else breaks. For "the shape must match and only the shape matters," this works.

When is it a trap? Real generation. Zero-padding 768 up to 1280 doesn't invent meaning - the new dimensions are empty, and the model treats them as actual signal. Slicing 1280 down to 768 discards up to 40% of the vector the text encoder spent real parameters producing. The results are usually noisey, washed-out, or just wrong, and no amount of retrying will fix it, because the corruption is structural. If you're doing this for a production workflow, stop and ask whether you're actually using the right checkpoint or CLIP instead - 90% of conditioning dimension mismatches are "wrong model for the encoder," not "I need to reshape."

That last point is the honest take on this whole pack: it's for tinkerers and people building experimental adapters, not a daily driver.

Install

Install it once for all five nodes via ComfyUI Manager (search "Clip Reshaper") or:

cd ComfyUI/custom_nodes
git clone https://github.com/thezveroboy/ComfyUI-ClipReshaper

Then restart. No dependencies beyond torch, no model downloads. If you feed it something that isn't a proper conditioning list, it'll throw a clear TypeError saying it expected [tensor, meta] pairs - that's the error message doing its job, not a bug. Use Pad/Slice to unstick an experiment, not to paper over a wrong model choice.