ꘅ Local Decision
A model that picks from your list instead of writing a paragraph
- choice
- decision_json
- metrics
The idea, and why it's better than prompting an LLM
Most "LLM in ComfyUI" nodes do the same job: you give a language model a prompt, it writes you prose, and something downstream has to parse the prose. That last step is where it always hurts - role delimiters, preambles, "Here is your enhanced prompt:", a stray backtick, and your conditioning is now poisoned.
ꘅ Local Decision refuses that whole failure mode. You give it a state (a description of the situation), a question, and a fixed list of allowed labels. It ranks the labels and returns one. No generated paragraph. No parsing. The output is a label you defined plus a distribution over the options you defined - a bounded choice inside a design you authored.
That's a much narrower contract than a chat model, and narrow is the point. [ "blue", "orange" ] cannot invent a third palette, cannot emit a command, and cannot drift off into an undressing sequence because it felt like it. For interactive art, generative pacing, or anything where a knob should move in response to a scene description, this beats "prompt a 0.6B model and regex the answer."
Expect a small footprint of community evidence: "genereticore" has essentially no footprint in the r/comfyui and r/StableDiffusion corpus yet. This is a v0.1.0 early-alpha pack from a solo author (languel, publisher id liuboto), not a battle-tested community default. Read it as an experiment with a very clean contract.
Two backends, two different behaviours
model is an enum with exactly two options:
- d1-omni-600m - a specialist. One Core ML forward pass over the allowed answers, zero generated tokens. Text only. Two to eight choices, and at most 256 combined input tokens - longer requests fail explicitly rather than getting quietly truncated to a smaller bucket. Needs macOS 15+ Apple silicon and a separately built helper (
python3 scripts/build_d1_helper.py). Their d1 adapter applies the model's published calibration temperatures, and the result is taggedd1_temperature_scaled. - qwen3-0.6b - uses a language model's answer-slot scores. Up to 26 choices. Shares the same 352 MB download as
ꘅ Local Text. Taggedanswer_slot_softmax_uncalibrated, which is honest: these are not probabilities.
Both produce a label and both feed the same downstream graph, but their scores don't mean the same thing, and the author says to evaluate their quality separately. Believe them.
There's also a wiring subtlety you can see in the source. For Qwen, the question is glued onto the state as prompt + "\n" + question before submission. For d1, the state goes in alone and the question travels as its own field. Same two text boxes, two different consumption paths - so don't assume a decision that flips when you switch backends is a bug.
The fields you'll actually touch
prompt is the state: "A quiet moonlit lake with soft ripples." choices_json is your allowed list - ["blue", "orange"] by default. Keep it identical for your first comparison so the only variable is the scenario. question is optional and defaults to "Which option best fits the situation?"; it's where you define what each option means if the labels aren't self-explanatory.
max_tokens (1–2048, default 256) is Qwen's generation budget. d1 ignores it entirely, because d1 generates nothing. Leave it alone.
Three outputs:
- choice - the winning label, a STRING. Straight into
ꘅ Choice to Value. - decision_json - the full serialized result including the scores. Into
ꘅ Text / JSON Viewerif you want to see it, orꘅ Decision Scores Validatorif you're feeding scores from somewhere else. - metrics - request id, backend, model, timestamp, timings. Cheap to wire to a second viewer; useful when you're deciding whether the thing is fast enough for live work.
Install and downloads
cd ComfyUI/custom_nodes
git clone https://github.com/languel/genereticore
python3 scripts/build_helper.py # Core AI, macOS 27+ / Xcode 27
python3 scripts/build_d1_helper.py # d1, macOS 15+ / Swift 6
Restart Comfy. Search GeneretiCore in Manager if you'd rather not clone. Models never arrive on their own - click ↓ on the node to pull the pinned revision with checksum verification. qwen3-0.6b is ~352 MB; d1-omni-600m is ~769 MB.
The hard wall: Core AI needs macOS 27+ on Apple silicon plus Xcode 27. This is a contributor milestone, not a shipped student release, and the author says so in the README. On Linux or Windows the pack imports and the decision plumbing works, but the model does not.
Where people get burned
The button confusion is the big one, big enough that the getting-started doc has a table for it. ϟ runs a local preview inside the node and updates nothing downstream - so you get an answer in the node and a blank viewer next to it, and conclude the workflow is broken. Use top Run or the node's ▷. If your Text / JSON Viewer stays empty while the node looks happy, that's the reason.
And the honest ceiling: the author's own notes say local smoke tests exposed incorrect answers and poor choices from the 0.6B starter. Build a scaffold that tolerates a wrong answer - two nearly equal scores mean "don't switch yet" - rather than one that treats the label as ground truth.
Inputs (5)
| Name | Type | Default | Description |
|---|---|---|---|
| model | COMBO | Local decision backend. d1 is a text-only specialist; Qwen uses language-model answer slots. | |
| prompt | STRING | A quiet moonlit lake with soft ripples. | State: the situation the model should judge. Change this to compare decisions. |
| choices_json | STRING | ["blue", "orange"] | Allowed answer labels, authored by you. Keep these unchanged for the first comparison. |
| max_tokens | INT | 2561–2048 | Qwen generation budget. Ignored by d1, which produces zero generated tokens. |
| questionopt | STRING | Which option best fits the situation? | The question to answer about the state. Define what each option means if needed. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| choice | STRING | — |
| decision_json | STRING | — |
| metrics | STRING | — |