Nodes/Nukun_ComfyUI_Nodes/Conditioning Analyzer (Nukun)
ComfyUI Node

Conditioning Analyzer (Nukun)

The X-ray machine for your conditioning tensor

By OnekoSL·Created 3 months ago·Updated 11 days ago· 1
Conditioning Analyzer (Nukun)
  • conditioning
  • conditioning
  • report

Conditionings are black boxes. You feed a prompt in, a tensor comes out, and unless you're comfortable poking at tensor shapes yourself, you have no idea what's actually in there - how many tokens, what the norms look like, whether there's a pooled output, whether the numbers are quietly turning to NaN. NukunConditioningAnalyzer exists to open the box: it passes your conditioning through unchanged and hands you a text report of everything interesting about it.

That "passes through unchanged" part is the key design decision. This is a diagnostic node, not a transformer. You drop it in a wire, read the report, and take it back out - nothing about your image changes.

What the report tells you

Wire any CONDITIONING in, and the single report (STRING) output gives you:

  • entry count and tensor shapes
  • dtype and device
  • metadata keys present on the conditioning
  • whether a pooled output exists
  • token count and channel count
  • per-token norm statistics
  • NaN/Inf checks - the one everyone actually cares about

That last one is the reason this node earns its keep. If your image comes out black, garbled, or "collapsed", NaN or Inf in the conditioning is a classic culprit, and this node tells you in one run whether the problem is upstream of the sampler or not.

The workflow it's built for

The README's own advice is the pattern: use it before and after experimental nodes. Capitan Advanced Enhancer gets name-dropped, but the idea generalizes - any node that claims to reshape conditioning:

  1. ConditioningAnalyzer → read report A (baseline).
  2. Through the experimental node.
  3. ConditioningAnalyzer again → read report B.

If report B shows the same shapes, dtype, and sane norms, the node did nothing harmful numerically. If B shows a new cuda:0 device when A was CPU, or token count changed, or NaN appeared - you've found your regression in seconds instead of debugging blind.

The two outputs

  • conditioning - your input, untouched. Wire this through and continue the graph exactly as before.
  • report - the STRING with all the stats. Right-click it and view it as text, or wire it to a text display/logger node.

It's effectively a "view" node for conditioning, in the same spirit as ComfyUI's console/log helpers.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/OnekoSL/Nukun_ComfyUI_Nodes.git

Restart ComfyUI or install via ComfyUI Manager ("Nukun").

Bottom line

You won't use this every day - you'll use it every time something weird is happening and you're out of ideas. It's the multimeter you keep in the drawer: boring, unglamorous, and the thing you reach for when the graph is misbehaving and you want data instead of vibes. Pair it with the pack's ConditioningAdjust and neutral_report_only preset and you've got a "did my conditioning actually change?" harness for any experiment.

CategoryNukun/Conditioning

Inputs (1)

NameTypeDefaultDescription
conditioningCONDITIONING

Outputs (2)

NameTypeDescription
conditioningCONDITIONING
reportSTRING