🎲 LLM Wildcard Report

The LLM Wildcard Resolver churns through your slots silently - it resolves a __hair__, tops up a pool, retries a duplicate, and you'd never know which was which. LLM Wildcard Report is the visibility layer: wire the Resolver's report output into it and you get a structured, collapsible rundown of the run plus parsed counters you can route on.

It's an output node, which in ComfyUI terms means it's allowed to render stuff into its own body without breaking the graph. That's where the real value is - the node's UI shows a header with total / generated / reused / errors, one row per slot (status badge, name, final value), and each row expands to reveal the exact prompt sent to the LLM, the raw reply, any retry, and any error. There's also a raw-report textarea for copy-paste. If you've ever watched an LLM node quietly fail and wondered why, this is the node that answers.

Inputs and outputs

One input: report - wire from the Resolver's report output. That's it.

Four of the five outputs are the useful part, because they're real numbers you can branch on:

• summary - the full report text (STRING).
• generated - slots that produced new values and were appended (INT).
• reused - slots that reused an existing value, including cap-hits (INT).
• errors - slots where the LLM call failed (INT).
• total - total wildcard slots resolved (INT).

The canonical trick is routing on errors: only save the workflow image when errors == 0, so a flaky LLM call doesn't silently ship a broken prompt. A little switch node between errors and your image-saver does it.

Behind the scenes the Resolver writes a structured JSON payload alongside the text report, and the Report node's frontend pulls it to render those expandable rows - the text parsing is a fallback when the payload isn't there. Either way, the counters are the same.

Installing

Same pack, same story: ComfyUI Manager → search LLM Wildcard Manager, or git clone https://github.com/pclshm/comfyui-llm-wildcard-manager into ComfyUI/custom_nodes, restart. No dependencies, no model files - it's pure text parsing.

Honestly, you can live without this node if your prompts resolve cleanly every time. The moment you start debugging why a slot reused when you wanted a fresh value, or you want images saved only when every slot succeeded, it earns its place in the workflow. It's also a nice first thing to wire up on a new template, just to see what the resolver is actually doing with your pool files before you trust it.