Isekai Visual QA

You've been staring at your own output so long you've stopped seeing the extra finger. Four batches into a long session, your brain is on strike while six-fingered hands sail past. Isekai Visual QA does that eyeballing for you: it hands your render to a local vision model, gets a structured verdict back, and returns a clean approved boolean you can route a workflow on. No cloud API, no key, no per-image fee - it talks to Ollama on your own machine.

It comes from isekai-sh/isekai-comfy-node, a pack tied to the isekai.sh publishing platform; the same repo ships a companion Upload node, and this QA node is meant to sit in front of that path, gating whether an image goes straight to draft or back to the drawing board. It's a small, young pack with no real community footprint yet, so read it as you would any fresh custom node - but the mechanism is solid and worth knowing.

How it works

The node is one of the "LLM as a tool in the graph" family the ComfyUI scene has converged on - a VLM doing a job that isn't diffusion. Under the hood: each input image becomes five PNG views (the full frame plus four quadrant crops) sent in a single request to your local Ollama server. The crops aren't decoration. Small hands and faces in a big render are exactly what VLMs miss, so the quadrants force the model to inspect detail rather than vibe at the composition. Every view is capped at a 1024px longest edge so the request stays inside Qwen's context window.

The default model is Qwen3-VL 8B (qwen3-vl:8b), Alibaba's open-weights vision-language model that's become the local captioning workhorse of this community. The node pins it to deterministic settings: temperature 0, a strict JSON schema for the reply, and a 10-minute Ollama keep-alive. Then comes the part worth stealing: it doesn't trust the model's own score. Qwen's raw estimate is kept as a diagnostic model_score, but the gate score is computed locally - start at 100, subtract 25 per major issue and 5 per minor, force zero if anything blocking shows up. A glitchy model reply costs you, but the verdict stays reproducible.

The inputs and outputs that matter

Five inputs, and only a couple you'll actually touch:

• image - your IMAGE tensor. It passes through untouched, so the node slots in anywhere without changing your output pipeline.
• model and ollama_url - defaults qwen3-vl:8b and http://localhost:11434. Change these only if you've pulled a different model or run Ollama elsewhere.
• approval_threshold - the pass line, default 80. For a batch, the lowest score across all images must clear it.
• rubric - the multiline text box telling the model what to check (hands, anatomy, seams, composition). The default is genuinely well-written and scoped to technical quality only - it explicitly refuses to judge subject matter, taste, or stylization. Swap it per workflow if you want, say, stricter text checks.

Outputs: image (your input, unchanged), approved (BOOLEAN), score (INT), and report_json - a string with the full per-issue breakdown, which is where you look when something fails and you want to know why. On the companion Upload node, approved is exactly what its "Use QA decision" setting wants: it only goes direct-to-draft when the boolean is literally true, and fails closed to manual review otherwise.

Install

Install the pack once, either via ComfyUI Manager (search "isekai") or manually:

cd ComfyUI/custom_nodes
git clone https://github.com/isekai-sh/isekai-comfy-node
cd isekai-comfy-node && pip install -r requirements.txt

Then restart ComfyUI. The pack's only real dependency is Pillow plus requests (torch and numpy come with ComfyUI). What this node actually needs beyond that is Ollama and the model, which lives in your Ollama install, not your ComfyUI folder:

ollama pull qwen3-vl:8b

Where people get burned

The big one is VRAM. Ollama and ComfyUI are both after your GPU. The node tries to help - unload_comfy_models defaults to on and calls ComfyUI's unload_all_models() before inference - but when Ollama shares ComfyUI's GPU, Qwen can keep several gigabytes resident for up to 10 minutes after each call. Run Ollama on a dedicated or remote GPU if you can, and ollama stop qwen3-vl:8b when you want the VRAM back mid-session. If the model is partially offloaded to CPU, each check gets painfully slow.

Manage expectations: this is a quality gate, not a guarantee. If Ollama isn't running, the model isn't pulled, or the reply is malformed, the node fails closed: approved = false, score 0, and an inference_error blocking issue in the JSON. That's the right failure mode for a publish gate - better a false rejection than a mangled hand going out the door. Treat it as a fast, consistent second opinion, wire approved into a retry loop or an upload decision, and you've automated the most boring part of the job.