SAX Debug Inspector

The whole pitch of SAX_Bridge is that everything - model, clip, VAE, seed, steps, CFG, images, latent - rides along one PIPE_LINE wire, so a five-node workflow replaces a forty-node spaghetti pile. The trade, as with every context-bus design, is that you can't see what's inside the pipe. SAX Debug Inspector is the x-ray: feed it any pipe and it prints the internal state right on the node, so you know what the next node is actually going to receive.

This is the first node you should wire up whenever a SAX workflow misbehaves, because half of all SAX bugs are "the pipe contains something you didn't expect" bugs. It's the read-only sibling of SAX Assert (which checks a value and stops the run) and SAX Debug Controller (which logs everything).

How it works

One input: pipe (PIPE_LINE). Nothing else. It's a terminal node - no outputs - and it renders a summary directly in the node UI, so you see the result without digging through console logs.

What you get, in roughly this shape:

• Whether model, clip, and vae are present (and usually what their inner types, dtypes, and devices are).
• The seed.
• The loader_settings that will drive the sampler - steps, CFG, sampler name, scheduler.
• The images tensor shape, e.g. (1, 512, 512, 3).
• The samples (latent) shape, e.g. (1, 4, 64, 64).
• applied_loras, so you can confirm the LoRA you loaded actually landed on the model in the pipe.

That last one is worth calling out. Pipe-based workflows make it easy to apply a LoRA in one node and then silently run the base weights because the pipe you sampled from was assembled before the LoRA node executed. The KB's plumbing doc names this the classic stale-context failure - the wire is connected, the contents are wrong. Inspector shows you applied_loras at a glance, which turns that mystery into a one-second check.

How to actually use it

Park it right before whatever node is misbehaving. Seeing blank output after the KSampler? Check images after the sampler. Detailer doing nothing? Check that a mask made it into the pipe and that loader_settings holds the steps/CFG you think it does. Inspect, fix, inspect again - it reruns each execution and always shows the latest state, so it works fine as a permanent resident on a debugging branch.

Because it's an output node, ComfyUI always executes it even if nothing downstream consumes it, and it re-evaluates when the pipe changes. It also handles a bare dict or object reasonably well - the field extraction walks dict keys and attributes - so you can use it as a generic "what is this thing" probe on pipes built by other nodes.

The catch

It shows you state; it doesn't tell you whether that state is right. You still have to know that the latent should be (1, 4, 64, 64) and that CFG 8 belongs in loader_settings. If you're not sure what a healthy pipe looks like, run Inspector on a known-good workflow once and take a mental snapshot - after that, deviations jump out at you. And remove it (or bypass it) before sharing the workflow, because the node body full of tensors is noise for anyone who doesn't need it.