[llama.cpp] Extract Answer

This is the smallest node in the pack's decision family and the one that makes the rest usable. The Decide nodes hand back an opaque typed payload - a dict with a selected option, a value, a probability list and a raw API result. [llama.cpp] Extract Answer unpacks it into five normal ComfyUI sockets.

If your instinct is to parse that payload yourself with a string node, don't. The pack validates the payload hard before exposing anything: probabilities that don't sum to 1, fields that disagree with each other, mismatched probability counts - all of it is rejected rather than passed along. That's a boring feature right up until the day your server returns something weird and you'd rather have an error than a silently wrong branch.

Its one input, and its five outputs

The input is answer, the OLLAMA_IMAGE_LIST_LLAMA_CPP_ANSWER socket from [llama.cpp] System One Decide or one of the sequential variants. One wire in, five out.

• selected - the chosen option as a string. Empty for score and noul answers, because there's no label to select in either case. This is the output you branch on for choice questions and only choice questions.
• value - a FLOAT whose meaning depends entirely on the question type. Choice: the probability of the selected option. Score: the expected 0-based level index, so a 1.7 means "between the second and third level you supplied". Noul: P(true). Same socket, three different measurements.
• noul - a BOOLEAN, true when P(true) is at least 0.5, and None for choice and score answers. That None is the thing to plan for: wire this into a downstream boolean input from a choice answer and you're feeding it nothing. It's a convenience for the true/false case, not a universal gate.
• probabilities - a FLOAT list, in the order you supplied your answers. For noul it's always [false, true], which is worth remembering because it's the one case where positions don't map to anything you typed.
• result_json - the complete raw per-question answer from the server as a formatted JSON string, including the fields the pack doesn't promote (legend for scores, confidence values, whatever else the build returns).

That last output is the unsung one. When value looks wrong, result_json tells you whether the model was uncertain across the board or the server returned something unusual - and it's a plain string, so any log or preview node can show it.

Wiring it up

The typical graph is short: Decide → Extract Answer → whatever you do with a number. Branching on a yes/no is the cleanest use - the noul boolean into a switch, or value into a threshold if you'd rather decide where the line sits (P(true) ≥ 0.5 is a choice the node made for you; nothing stops you setting the bar at 0.8 and treating anything softer as "unknown").

System One Decide ─ answer ─ Extract Answer ─ value ─ (math / threshold / switch)
                                            └ selected ─ (text branch, choice only)

For the sequential nodes, list outputs need indexing first - a core GetItemFromList per index, then Extract Answer on the result. That's exactly how the pack's own example workflow does it, and it's the standard way into this when you only care about one or two entries.

Two practical notes. The probabilities list is ordered by your input order, not by any ordering the server happened to return - so a low probability at index 0 genuinely means the first option you typed was unlikely. And selected for a choice is the highest-probability option; it is not a separate model decision you can contradict. If selected says "day" and the day probability is 0.51, that's a coin flip rendered as a label, and the graph should know that.

Installing it

Part of the same pack, so nothing extra:

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

…then restart, or install ComfyUI-llama-multimodal through ComfyUI Manager by searching llama multimodal. It needs ComfyUI 0.19.3 or later, and the models themselves live in ComfyUI/models/LLM with their mmproj projector. This node produces nothing on its own - it needs an answer socket from a decision node, and those decisions need the optional llama dependency (makoto-decision, in the pack's requirements.txt) plus a Runtime or Connect Session pointed at a server that implements /v1/systemone.

Where people get burned

Assuming value means one thing. In a workflow that mixes question types, the same FLOAT output is a probability in one branch and a level index in another. That's the number one source of "why is my threshold behaving strangely" in this family.

Treating the probabilities as calibrated confidence. They aren't; the pack says so plainly. They're the model's distribution over your options, and small models are confidently wrong. Use them for ranking and routing, not for anything that needs a real measurement.

Forgetting the list case. On the sequential Decide nodes, Extract Answer connected straight to the output gives you a list socket on a scalar input. Index it first.