LLM Dialogue Cycle

You've probably seen the trick where you paste model A's answer into model B and ask it to rip it apart. LLM Dialogue Cycle automates that loop inside a single ComfyUI node - two local GGUF models talk to each other, no copy-paste, no API keys, no external runtime. The reason you'd reach for it over wiring up two chat nodes with a cyclic graph is that ComfyUI is genuinely bad at cycles. This node runs the whole A→B→A→B exchange in one call, so your workflow stays a straight line.

It's the same engine as LLM Session Chat (llama-cpp-python running GGUF weights out of models/LLM/), but aimed at a different job: critique-and-revise loops, red-teaming a prompt, or simulating a conversation to check whether your role settings actually behave before you set them loose on a real user. It ships with the pack's own opinion baked in - initial_user_text goes to Model A only, and from there each model's output feeds the other's next turn.

How it works

The cycles input is the turn counter: 1 means A then B - a single round trip. Bump it and the ball keeps bouncing, up to 50. Each role gets its own persistent history, so session_id is really a base: A's history lives at {id}_A, B's at {id}_B, and the full transcript is appended to {id}.txt on disk. The node returns the whole transcript as a string out of transcript_text, which is the output you'd wire into a text preview or a save node.

Because the models run inside one execution, the pack keeps both model managers loaded when runtime_cache is KV_cache or LlamaTrieCache (the defaults), so the dialogue doesn't reload weights between turns. That's also why the newer Unload LLM Model node exists - after a big two-model run you can free the VRAM without restarting ComfyUI.

The inputs that matter

You mostly set four things and ignore the rest:

• modelA / modelB - dropdowns populated from GGUF files in ComfyUI/models/LLM/. If they read (No GGUF models found in models/LLM/), that's your problem right there.
• system_prompt_A / system_prompt_B - role definitions. A shared system_prompt applies to both unless the per-role one is filled in, which overrides it.
• cycles - how many round trips before it stops.
• n_gpu_layers - 0 is pure CPU (slow for anything past a few billion params), -1 offloads everything.

The mmprojA / mmprojB projector slots exist for future image-capable dialogue; dialogue is currently text-only, so set both to (Not required) and move on. Everything else - temperature, top_p, max_tokens, n_ctx, the summarization and cache knobs - is standard sampling and history management, and the defaults are sane.

Installing it

The usual two paths. Via ComfyUI Manager, search for ComfyUI-LLM-Session. Or clone it manually:

cd ComfyUI/custom_nodes
git clone https://github.com/kantan-kanto/ComfyUI-LLM-Session.git
pip install pillow numpy
pip install llama-cpp-python

Then restart ComfyUI. Drop your GGUF files into ComfyUI/models/LLM/. Plain PyPI llama-cpp-python works for most text-only models; the newer multimodal families (Qwen3-VL, Gemma 4) need a recent JamePeng build matching your OS, Python version, and GPU backend - the README's COMPATIBILITY.md walks through it.

Where people get burned

Two local models means two sets of weights. A 12B GGUF on an 8GB card is already a squeeze; running A and B back-to-back is where you'll first feel the VRAM ceiling. Keep the quant ladder honest - Q4_K_M or so per model, and lean on n_gpu_layers for partial offload. And remember the histories persist: rerun with the same session_id and the models keep talking where they left off. That's a feature for testing prompts, but a trap if you expected a clean slate - flip reset_session when you want one.