llama.cpp Model Info
Ask llama-server what model it's actually running
- trigger
- connection
- model_name
- context_length
- info_json
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:
- Debugging context issues - your prompts are getting truncated or generation dies mid-stream. Check
context_lengthagainst the actual prompt+max_tokens you're sending. - 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.
- 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."
Inputs (7)
| Name | Type | Default | Description |
|---|---|---|---|
| server_urlopt | STRING | llama-server URL, or empty for the managed runtime. | |
| triggeropt | * | Optional dependency input used to refresh model metadata. | |
| modelopt | STRING | Optional exact router model ID. | |
| api_key_envopt | STRING | LLAMACPP_API_KEY | Environment variable containing the API key. |
| verify_tlsopt | BOOLEAN | true | Verify HTTPS certificates. |
| request_timeoutopt | INT | 301–3600 | Server metadata deadline in seconds. |
| connectionopt | LLAMACPP_CONNECTION | Optional reusable connection profile. |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| model_name | STRING | Active model alias, path, or router identity. |
| context_length | INT | Context length reported by llama-server. |
| info_json | STRING | Complete server properties as formatted JSON. |