Logger

Every time a workflow "doesn't work," the problem is hiding somewhere you can't see - and this node is a set of eyeballs. Logger sits on any wire, prints whatever is flowing through it to your ComfyUI console, and hands the exact same value right back out so nothing downstream notices it was even there. It's the utility knife of debugging an LLM-in-the-graph pipeline: you wire your prompt enhancer's output into it, see the raw string your model actually generated, and find out in one run whether your conditioning is getting clean text or markdown scaffolding and "Here is your enhanced prompt:" preamble.

Full honesty up front: this pack is very new. The repo has exactly one commit ("base config"), the README is literally just a title, and Logger is the only node it currently registers. The name promises llama.cpp LLM nodes - they aren't in the tree yet. You're installing this for a debug utility, not the LLM features, and it's a brand-new unknown pack from a fresh repo, so the usual caution applies: it's arbitrary Python that runs when ComfyUI loads, and I'd read it before trusting it with anything sensitive. What's here works, though.

How it works

The mechanism is simple and it shows. Logger accepts any_value - a wildcard * input, so you can drop it on any socket regardless of type - and because IS_CHANGED() returns float("nan"), it counts as "changed" every single run. That's deliberate: it re-executes even if nothing upstream changed, so you never miss the log line you're hunting for. It formats dicts and lists as pretty-printed JSON, prints the whole thing in color to stderr, and returns both the original value and the formatted text.

The inputs and outputs that matter

• any_value - the thing you want to inspect. Leave it unconnected and it logs [no input]; wire anything in and you get its type and value.
• checkpoint_name - the label on your log message ("after_llm", "before_encoder"). The name is a lie; it's not a model checkpoint, just a tag so you can tell your log lines apart when you've got three of these in one graph.
• console - default true; set false and it stops printing but still returns the string.
• text_color - one of nine ANSI colors. Purely cosmetic, but when you have multiple loggers running, color-coding them is surprisingly good.

Outputs: passthrough (the original value, untouched - this is what keeps the wire flowing) and log_string (the full formatted log as text, which you can preview or write to a file). Because it's an output node, stick it at the end of a branch you want to inspect - it won't break whatever's downstream.

Installing it

ComfyUI Manager (search "ComfyUI-LlamaCPPPython"), or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/stalkervr/ComfyUI-LlamaCPPPython

Restart ComfyUI. No requirements.txt, no model downloads - Logger has zero heavy dependencies. If the pack later grows llama.cpp loaders, expect GGUF files and a real install step, but this node needs nothing.

Where people get burned

The number one "it's broken" is actually "it works, wrong window": output goes to stderr, so if ComfyUI runs as a background service, check its log file - you won't see colors in the WebUI. checkpoint_name defaults to "default", so two loggers with default labels are indistinguishable; name them. And the always-re-executes behavior is a feature, not a bug - that node running every queue pass is what makes it a debugger instead of a paperweight.