Nodes/ComfyUI llama.cpp Suite/llama.cpp Model Info
ComfyUI Node

llama.cpp Model Info

Ask llama-server what model it's actually running

By Setmaster·Created 8 months ago·Updated 2 months ago· 6
llama.cpp Model Info
  • trigger
  • connection
  • model_name
  • context_length
  • info_json
server_url
model
api_key_envLLAMACPP_API_KEY
verify_tlstrue
request_timeout30

Every so often a workflow turns into an argument about what model is loaded. The dropdown said Qwen 8B, but the output reads like a different model entirely, or the context window ran out sooner than the math said it should. Model Info ends the argument: it asks the running llama-server for its /props metadata and hands you the model name, the context length the server actually reported, and the raw properties as JSON.

It's a read-only diagnostic, and a genuinely useful one - the server's report is authoritative where dropdowns and expectations are not.

How it works

The node makes a GET /props call to llama-server through the pack's client. From the response it extracts:

  • model_name - the active model alias, path, or router identity.
  • context_length - the context length as llama-server reports it, which reflects what the running instance actually allocated, not what you hoped for.
  • info_json - the complete server properties payload as formatted JSON, for when you want the whole raw answer.

Routing works the same as the other utility nodes: leave server_url empty to hit the pack's managed runtime, or point it at an attached endpoint; model pins an exact router model ID; connection can supply a whole profile. It's an output node, so it renders its results for you - feed the strings into a Prompt Output node if you want them readable on the canvas (info_json is pretty-printed JSON, so it's already fairly readable).

When you'd actually reach for it

Three moments:

  1. Debugging context issues - your prompts are getting truncated or generation dies mid-stream. Check context_length against the actual prompt+max_tokens you're sending.
  2. Verifying a router pick - in router mode, confirm exactly which model identity the server resolved, since the catalog can have aliases and paths that don't match the dropdown label.
  3. Checking an attached endpoint - you attached to a remote or hand-started server; Model Info tells you what's actually loaded there before you waste a generation on the wrong model.

The honest version

It's a thin node - one HTTP call, three outputs. That's the point. There's no model loading here, nothing to configure that can break, and no secret settings. If you're the sort who likes a little instrumentation in a workflow (and if you're running an LLM in a graph, you should be), this one sits quietly next to Server Status and Token Count as part of the pack's "tell me what's actually happening" layer. The one thing it won't do is tell you the model's quality - the server faithfully reports "the model I loaded" and not "whether that model is any good."

CategoryLlamaCpp

Inputs (7)

NameTypeDefaultDescription
server_urloptSTRINGllama-server URL, or empty for the managed runtime.
triggeropt*Optional dependency input used to refresh model metadata.
modeloptSTRINGOptional exact router model ID.
api_key_envoptSTRINGLLAMACPP_API_KEYEnvironment variable containing the API key.
verify_tlsoptBOOLEANtrueVerify HTTPS certificates.
request_timeoutoptINT301–3600Server metadata deadline in seconds.
connectionoptLLAMACPP_CONNECTIONOptional reusable connection profile.

Outputs (3)

NameTypeDescription
model_nameSTRINGActive model alias, path, or router identity.
context_lengthINTContext length reported by llama-server.
info_jsonSTRINGComplete server properties as formatted JSON.