LLM Server Live Log 📜

If you run the pack's Local LLM Server - a managed llama.cpp or koboldcpp process serving an OpenAI-compatible endpoint that a chat client like SillyTavern talks to - then the questions you actually have are "did that request land?", "how long did it take?", "how full is the context now?" and "what sampler settings is my preset really sending?". This node answers all four, live, on the canvas.

It has no inputs, no outputs, and never runs on the backend. Drop it anywhere.

Why it can't be a normal log node

The pack has other live logs, and they're all tied to a ComfyUI run: you queue a prompt, the log fills as the graph executes, it stops when the run does. This one is a different animal. The server is talked to whenever the chat client feels like it - no prompt queued, quite possibly no browser open. So the events are recorded on the backend and pushed over a websocket (kinburg.llmserver), and when the node appears it fetches the backlog from /kinburg/llm_server/log. Open ComfyUI after an hour of chatting and the log is already full. That's the feature that makes it useful rather than decorative.

A request is also two events: a row opens the moment a request arrives and is filled in when it finishes. That's deliberate - the forty seconds a cold start takes read as a load in progress rather than as a hang, which is the single most common "is it broken?" moment with a local LLM server.

What a row tells you

Finished rows carry the status, the duration, tokens in and out, the rate, and context fill against the n_ctx the server was started with. That last number is the one to watch: it's how you see a long chat approaching the point where the model starts forgetting its own beginning.

Under that sits the line this node exists for - the sampler settings the client actually sent. Temperature, top_p, top_k, min_p, the DRY and XTC parameters, mirostat, seed, max_tokens. Otherwise that's guesswork on the SillyTavern side, where presets are easy to lose track of and a forgotten override quietly changes every reply. Loads, unloads with their reason, errors in the server's own wording, and every parameter repair get rows of their own. Repeated model-list or health polls collapse into one row with a counter instead of burying everything else - a nice touch if you've ever watched a log drown in /v1/models.

Privacy is the default, not an extra

Message text is not logged. What's recorded by default is shape and numbers: how many messages, how many characters, which samplers, how many tokens, how long. The text previews are opt-in on the server node, via log_text, and even then trimmed to a few hundred characters. The author's reasoning is correct: this log is drawn on a ComfyUI canvas, which whoever is sitting at the machine can read. With log_text off, the message text never leaves the gateway at all rather than being sent and then not displayed.

The other switches live on the server node too. log_events is the log itself. log_server_output folds in llama.cpp's own stdout - slots and prompt-eval timings - which is genuinely useful when a model misbehaves and pure noise the rest of the time; it always reaches the server_log output regardless of this setting.

The reason half these rows exist

Parameter repairs. SillyTavern stores list-valued options as JSON strings, and llama.cpp's server refuses the whole request when one isn't a real array. dry_sequence_breakers is the one everybody hits - llama.cpp's own source comments that its format is "not compatible with TextGen WebUI, Koboldcpp and SillyTavern" - and the server node's fix_params rewrites those shapes on the way through. auto_retry covers the fields nobody has hit yet: a 400 that names a field is retried once without it, then that field is stripped from later requests. drop_fields is the manual version, one name per line.

Without that layer you'd get a 400 and a chat that doesn't answer; with it, you get a row here saying what was repaired, which is exactly the amount of information you want.

Installing it

ComfyUI Manager → search Kinburg-Nodes, or:

cd ComfyUI/custom_nodes
git clone https://github.com/Kinburg/Kinburg-Nodes

Restart ComfyUI. The display is a frontend extension (web/llm_server_log.js), so follow the usual rule for any node that ships JS: if the panel looks blank or stale after an update, hard-refresh the page before assuming something's broken.

Where people get burned

Expecting text. It's off by default and that's a feature. Turn on log_text on the server node, not here - this node has no widgets at all.

Looking for it after a chat happened, and seeing nothing. Check that the server node has log_events on and that the server is actually the pack's managed one; this logs its gateway, not an Ollama instance you're running separately.

Confusing it with the in-graph logs. The pack's Local LLM (GGUF) nodes have their own log node for prompts running inside a graph. This one is for the served endpoint and its clients.

Long sessions. The ring holds roughly 400 events; older ones drop off. The clear button empties the backlog as well as the view, so a reload doesn't bring it all back.