Ouroboros Critic Settings 🐍

The Ouroboros sampler in this pack is a self-correcting loop: generate, have a vision LLM judge the result, feed the criticism back into the prompt, generate again. This node is the judge. It's a settings bundle - model plus scoring rules - that you configure once and hand to the loop, so the critique you get is consistent and the loop isn't re-deciding how to grade on every iteration.

The mechanism is worth understanding before you wire it, because it's doing a specific job with a specific persona. The bundled system prompt (pre-filled, but editable) tells the critic it's "a strict, consistent image-quality judge inside an automatic refinement loop," shows it one image plus the criteria and the prompt it was generated from, and demands a reply that is only a single JSON object - scores, concrete advice on how to change the generation prompt (not the image directly), and negative-prompt terms for the flaws it sees. That last bit is the whole point: Ouroboros doesn't edit pixels, it edits prompts, so the critic's job is to tell the loop what to try differently next pass.

The inputs that matter:

• config - required, and it must be a Local LLM Settings (GGUF) node with a Vision Settings (GGUF) (mmproj) wired, because the critic needs to actually see the image. No vision model, no critic.
• criteria - one per line, name: description, e.g. anatomy: all required limbs present, no extra limbs, correct proportions. Pre-filled with a sensible set; clear it for a single overall score.
• score_min / score_max - the scoring range (defaults 1–5).
• rubric - free-text guidance/tone on top of the criteria.
• system_prompt - the persona; blank falls back to the built-in default.
• samples - self-consistency: judge each image N times and take the median score. That's N× the critic cost, but it smooths out a vision LLM's mood swings.
• image_downscale - shrink the image the critic sees (2 = half-size, 4 = quarter). Fewer image tokens means faster judging and less VRAM; only worth it when pixel-level precision isn't what you're grading.

Output is one thing: critic_settings (type KINBURG_CRITIC), which wires straight into the Ouroboros node's critic input. This is a bundle node - it does no generation and no judging itself, it just packages the rules.

Installing

Ships in Kinburg-Nodes: ComfyUI Manager → search "Kinburg-Nodes", or clone into custom_nodes and restart. Because it leans on the pack's local-LLM infrastructure, you need llama-cpp-python (installed automatically by install.py, which Manager runs) plus a vision-capable GGUF model with its mmproj file configured in the Vision Settings node.

Gotchas

The most common failure is wiring a config without vision - the node won't error on the surface, but the loop's critic has nothing to look at. And remember samples is a cost multiplier: crank it to 5 on a slow machine and every iteration of an already-slow loop gets five times slower for marginal stability. Start at 1, raise it only if you're seeing the loop oscillate on its scores.