Conditioning Stats (CCN)

Every conditioning node in this pack modifies a tensor you can't see. Conditioning Stats (CCN) is the x-ray: it prints the shape, min, max, mean, and standard deviation of your conditioning to the console, then hands it back completely unchanged. It's a pure inspection node - it sits inline in your graph, changes nothing, and tells you what the numbers actually look like before you start clamping, scaling, and normalizing them.

How it works

For each conditioning entry it prints a block like this to the ComfyUI console:

• Shape - the tensor dimensions [batch, sequence_length, embedding_dim].
• Min / Max - the extreme values, which tell you if you have outliers (the thing Conditioning Clamp exists to fix).
• Mean / Std - the center and spread of the value distribution (what Conditioning Normalizer reshuffles).
• Pooled keys - what metadata the entry carries, most commonly pooled_output.

The label input is just a string used as a heading, so when you have three of these in a graph you can tell which block is which. Slap one after an encoder and one after your favorite conditioning node and you can see exactly what the tinker node did to the numbers.

Inputs and outputs

conditioning in, conditioning out - unchanged, guaranteed. label defaults to "Conditioning" and exists purely for your sanity. There's no debug toggle; it always prints, which is fine because it's cheap and you can bypass it when you're done.

Install

Same as every node in this pack. ComfyUI Manager → search ComfyCollectorNodes → Install → restart, or:

cd ComfyUI/custom_nodes
git clone https://github.com/valkymaera/ComfyCollectorNodes

Restart, no pip step. It's under the (CCN) suffix.

Where it fits

This is a debugging tool, and it knows it. When the pack's own conditioning nodes are the suspects - did the clamp bite? did the normalizer move the mean? - this is the node that answers it in one run. The honest limitation: on modern LLM-encoded models the conditioning tensor is a chat-turn embedding, and the shape/min/max readout is a lot less interpretable than it was in the CLIP era. It's most useful on SD/SDXL-family CLIP conditionings and when you're chaining the pack's own arithmetic nodes. Don't leave it permanently in a production workflow - it's console noise by design - but for a ten-minute debugging session it's exactly what you reach for.