Llama.cpp One-Shot CLI

If you've ever wanted a local GGUF LLM inside a workflow without standing up Ollama or waiting for some node pack to add support for the model you just downloaded, this is the node that does exactly that - by refusing to be a convenient node at all.

Llama.cpp One-Shot CLI (LlamaOneShotNode) is a raw wrapper around your local llama.cpp binaries. It doesn't load weights, doesn't manage VRAM, and doesn't download anything. You point it at a compiled llama-cli or llama-completion executable, paste the exact flags you'd type in a terminal, and it hands back the text output. The author built it because he wanted full control over offloading flags, context shifting, and running GLM-4.x "without waiting for node wrappers to update, deal with crap ollama, or fighting with VRAM management in Comfy" - his words from the release thread. It's the DIY answer to the community want the KB tracks: any GGUF LLM as a graph node, no external server in the loop.

How it works

Two moving parts. First, the bridge: run python llama_bridge.py in a terminal and it starts a tiny HTTP server on 127.0.0.1:5050 that does the actual work. The node itself POSTs a JSON payload (binary_path, flags, prompt, and any saved image paths) to that URL. The bridge shlex-splits your flags, appends -p <prompt> and a --image per attached image, and executes the binary inside a pseudo-terminal. The PTY bit matters: llama-cli's progress bars and interactive output misbehave when there's no TTY, and this avoids that whole class of weirdness.

Back in the node, the captured stdout gets scrubbed: ANSI codes and block characters stripped, the ggml_/llama_/main: log lines filtered out, the echoed prompt cut away, and any <think>...</think> block split off from the actual response.

The inputs that matter

Four required, and only two you'll actually touch most days:

• prompt - the text sent to the model (appended as -p).
• binary_path - absolute path to your binary, e.g. /home/you/llama.cpp/build/bin/llama-cli.
• flags - the power knob: raw command-line args. Must include -m /path/to/model.gguf. The default (-c 32768 -ngl 99 -st --simple-io) is a sensible starting point; --simple-io and -st keep output clean for parsing.
• bridge_url - leave it at http://127.0.0.1:5050 unless you changed the port in the script.

Plus up to six optional image inputs (image_1–image_6) for vision models; each is saved to a temp PNG and passed as --image.

Outputs

Three strings: Final Text (the cleaned response - this is what wires into a text display or a prompt-enhancer chain), Thinking (the extracted reasoning block, empty if the model doesn't emit one), and Raw Log (every captured byte - your debugging friend when the parse leaves tags behind).

Installing it

Grab it through ComfyUI Manager (search ComfyUI_LlamaOneShot), or:

cd ComfyUI/custom_nodes
git clone https://github.com/skatardude10/ComfyUI_LlamaOneShot

Restart ComfyUI. No pip install, no model downloader - the only real dependencies are numpy and Pillow, which ComfyUI already ships, plus a working llama.cpp build and a .gguf file you bring yourself. Then, from inside the node's folder:

python llama_bridge.py

Keep that terminal open while you work. One note: the README's clone URL uses dashes (ComfyUI-Llama-OneShot); the actual repo is underscores, as above.

Where people get burned

• Forget the bridge and the node returns NODE ERROR: ... Connection refused as its Final Text. Start the bridge, rerun.
• The bridge blocks any binary whose filename isn't llama-cli, llama-completion, llama-server, main, or server (basename check, .exe stripped). A wrapper script or renamed copy gets a "Security Alert" error.
• It won't unload your diffusion model, so a GGUF offloaded at -ngl 99 and your checkpoint fight over VRAM. That's between you and llama.cpp.
• Output cleaning is heuristic; models with unusual chat templates can leak structural tags. Check Raw Log.

A straight talk note: this is a tiny, 0-adoption pack from a real hobbyist (same author as ComfyUI-Optical-Realism), which means you're the beta tester. The bridge executes shell commands, so the allowlist and localhost-only binding matter - it's fine on a box you control, and the wrong thing to put on a shared machine. Transparent about it, which is more than most LLM nodes manage.