llama.cpp Messages from JSON

What it's for

One text field in, one history value out. Messages from JSON is the import half of this pack's conversation pair: you paste a versioned JSON snapshot and it becomes a history you can hand to llama.cpp Generate (its messages input) or to llama.cpp Append Message to keep extending.

Two situations make it worth the node.

The first is few-shot prompting as a reusable asset. You work out three good example pairs for "rough idea → finished Z-Image prompt", save them once, and now every workflow you build starts from that exact context instead of you re-typing prose instructions and hoping. That's a real quality difference, not a ritual.

The second is restoring a conversation. Append Message has a messages_json output; that's a snapshot of a history you already built. Paste it back in later and you're in the same context in a fresh workflow, no rerun required. Because it's literal text in the graph, it survives being saved, shared, or committed to a repo - which is more than can be said for anything held in server state.

The mechanism, such as it is

The input is messages_json, a string, defaulting to an empty history:

{"schema_version":1,"messages":[]}

And a populated one looks like:

{
  "schema_version": 1,
  "messages": [
    {"role": "system", "content": "You write concise photographic prompts."},
    {"role": "user", "content": "a girl in a rainy alley"},
    {"role": "assistant", "content": "Young woman under an awning, wet asphalt..."}
  ]
}

The node validates it hard and returns messages, an immutable typed value. There's no second output and no error string path - malformed input fails. Whitespace inside content is preserved exactly, which matters more than it sounds: leading newlines and trailing spaces are part of what the model sees.

Roles are system, user and assistant. Nothing else. Images, tool calls, nested content objects and extra fields are rejected outright, and so are duplicate JSON keys - because a JSON parser that silently takes the last duplicate is how two people end up debugging a "history" that isn't the one in the file.

The bounds: 128 earlier messages, 262,144 characters per message, 1,048,576 serialized UTF-8 bytes. At most one system turn, and it must be first.

Those are data limits, not context-window guarantees. A 128-message history can be wildly over your model's slot context; the pack has a separate node for measuring that, and it's worth using before a long history bites you.

Getting it into a graph

messages goes to Generate's messages input, or to Append Message's messages input if you're extending it further. That's the whole wiring.

Then, the rule that catches people: if your JSON includes a system turn, leave Generate's system_prompt empty - and if a profile is connected, its system prompt has to be empty too. The pack refuses conflicting system sources before the runtime is admitted. One system prompt, one source.

Downstream of that, Generate appends its own prompt as the newest user turn, and any connected images belong to that current turn. Earlier messages are text-only - an earlier assistant turn cannot carry an image forward.

Installing

Part of the pack, nothing standalone:

comfy node install comfyui-llamacpp

Manager search "comfyui-llamacpp" works too, or clone into ComfyUI/custom_nodes and pip install -r requirements.txt with ComfyUI's own Python. Restart ComfyUI afterwards - the startup log lists every registered llama.cpp node, which is the quickest way to confirm it loaded at all. You'll also need a llama-server binary and a GGUF model under ComfyUI/models/LLM/gguf/; the pack installs the plumbing, not the runtime.

The messages-few-shot template under Workflow > Browse Templates > comfyui-llamacpp is the canonical example - it imports a system turn plus one example pair exactly this way.

Where people get burned

It doesn't validate your prompt engineering. A pasted history full of chat scaffolding ("Sure! Here's a prompt:") teaches the model to keep producing that scaffolding. Garbage in, reliably reproduced garbage out.

It's not a chat database. Nothing accumulates. Each queue rebuilds the value from this string. If you want to save a conversation, copy Append Message's messages_json into this node deliberately.

Schema drift. The envelope is versioned (schema_version: 1) for a reason - hand-edited JSON that drops the wrapper, or nests things the pack doesn't expect, fails. Read the error rather than trimming fields until it stops complaining; the strictness is protecting you from a history that isn't what you think it is.

Long history, small model. Check max_tokens and the model's real context. If you're consistently running out, the fix is a shorter history or a bigger slot context, not a retry.