[llama.cpp] System One Decide (Prompt Sequential)

The mirror image of the batch decision problem. You have one image - a freshly generated frame, a reference photo, a character sheet - and a list of things you want to know about it. Time of day. Is it a close-up. Is there water. Is the subject facing camera. Four, five, ten asks, all against the same picture.

[llama.cpp] System One Decide (Prompt Sequential) runs those asks as independent decisions against the same complete image bundle, one after another, on one loaded model.

What it does

The inputs are the family standard: session, system, context, question, session_unload, and optional images. What changes is the shape of context and question - here they're lists, paired by index.

The execution count is the longer of the two lists, and any list of length one is broadcast across all of them. So you can wire four questions with a single shared context, or four contexts with one question, or pair four and four one-to-one. What you cannot do is expect a Cartesian product - the pack is explicit that this is index pairing, not combinations. Four questions and four contexts gives you four requests, not sixteen.

Unlike the Media Sequential variant, the media doesn't change between requests: the same normalized image bundle is attached to every one. That's the whole point - you're not rebuilding media per question. Just don't assume it's cached: the pack warns that normalization is shared but the encoder may still run again per decision.

Outputs are lists, one entry per request: answer, metrics, media_diagnostics, plus a single scalar session you can keep chaining or unload. Unload happens once, after the sequence finishes - which is what you want, because starting a fresh session per question would throw away the entire reason to use this node over four separate Decision nodes.

The two questions you're really asking

First: are these answered independently? Yes. Each request is its own System One call with its own state and its own question payload, and the pack's design intent is that they don't see each other's answers. If you want the second question to be informed by the first, that's a graph-level job - ask the first, branch, build the second question from the result.

Second: can the questions be different types? Yes, and this is the sharp edge. Nothing stops a CreateList from mixing a choice question and a noul question, which means the same output socket holds answers whose value means completely different things: a probability for the choice, P(true) for the noul, an expected 0-based level index for a score. [llama.cpp] Extract Answer passes all three through correctly, but your graph has to know which index is which. It's fine - just label your indices somewhere you'll read them later.

Reading the results

Same plumbing as the media variant. Pull an entry out of the list and hand it to [llama.cpp] Extract Answer:

System One Decide (Prompt Sequential) ─ answer ─ GetItemFromList (index 2) ─ answer ─ Extract Answer

metrics per entry is the honest companion to all this - decision seconds, token usage, and the session bookkeeping (execution_index, model_reused, unload_required). Read it as a receipt for one request, not as proof the image was ever looked at.

Installing it

cd ComfyUI/custom_nodes
git clone https://github.com/craftingmod/ComfyUI-llama-multimodal.git

Restart, or install ComfyUI-llama-multimodal from ComfyUI Manager (search llama multimodal). You need ComfyUI 0.19.3+, the model GGUF and its mmproj in ComfyUI/models/LLM, a llama binary if you're using a Runtime Session - Settings → llama-multimodal → Download llama.cpp fetches it - and the optional llama dependency makoto-decision for the decision family, which is in the pack's requirements.txt.

Where people get burned

Length mismatch. Every supplied context and question is validated before the first inference call, and a list that is neither length 1 nor length N is a hard error. That's good - it fails before you've waited on four model calls - but it's the single most common mistake with this node. Count your list contents.

You wanted combinations and got pairs. Ten questions against five images is ten requests attached to the same bundle, not fifty. Wiring five images here doesn't make them a matrix; it makes them a bundle the questions all share, and if that's not the intent, you want Media Sequential instead.

The endpoint again. /v1/systemone is not universal. Unsupported server builds fail with a 404/501 and no fallback, and Native Sessions are rejected outright - Runtime or Connect only.

Images that never got looked at. The diagnostics mark remote media verification as unverified_remote, so a full set of confident probabilities is not evidence your model has vision support or that your mmproj loaded. Check the picture gets mentioned at all before you build a branching pipeline on top of it.

Re-runs cost real seconds. The node is non-idempotent, so changing anything and pressing queue re-asks every question. With a dozen asks on a small GPU that's a real wait - build the wording up on two questions, then scale.