Agent Request 0.7.1
Agent Request 0.6.0 hands you a tool call and walks away — that's the feature
- profile
- request
- image
- result
Agent Request is the low-level piece of the RM-LLM agent pair: it sends one request to OpenRouter's Responses API, streams it back, and returns the answer as structured data. If the model decided to call a tool instead of writing prose, you get the call - name, ID, arguments - and nothing happens next. No execution, no loop, no second turn. Your workflow owns that.
That makes this a niche node, and honestly a deliberate one. Tool-calling inside ComfyUI has mostly meant heavy block-based agent libraries or an MCP server that lets a chat model drive the app from outside. Agent Request is the opposite end of that: a single primitive you'd reach for if you're building the loop yourself, or if you want a tool-capable model's structured output as graph data rather than as text you have to regex apart.
How it works
Three inputs, one output. profile comes from Agent Model Profile and carries the model, reasoning effort, output cap and the environment variable name holding your OpenRouter key. request is the conversation itself, typed RM_LLM_AGENT_REQUEST - a structure with instructions (a string), input (a list of input items), and tools (a list of function tools). Nothing in this pack builds that object for you, which is the first thing to get straight: the socket expects a payload you construct, and if instructions isn't a string or input isn't a list, the node stops with "Agent request needs instructions and an input-item list."
image is optional, for one inspection image. There's a real constraint attached: one image, at most 4 megapixels, and only if the selected model advertises image input.
The request goes out streaming with store off, truncation disabled, and required parameters enforced. Before sending, the node checks that the model advertises function tools at all - and if you connect tools it also forces parallel tool calls off when the endpoint would otherwise accept the parameter, because requiring an unsupported parameter makes OpenRouter fail to find a tool-capable endpoint and return a 404. It also estimates the request size and refuses to send if it blows the profile's input ceiling. That estimate is deliberately crude - roughly a third of the JSON byte count plus a 32,000-token reserve for an image - so treat it as a guard rail, not a tokenizer.
What you get back
result, typed RM_LLM_AGENT_RESULT. It's a dictionary with a status of complete, tools, or failure; text for the assembled answer; calls for the tool calls; output for the raw provider items; and usage when the provider reports it. A tools status means "there are calls waiting, your turn."
Failures are honest and specific, which is more than most API nodes manage. A refusal returns status: failure with an explicit instruction not to auto-retry - bypassing a provider's refusal isn't a bug you fix. An incomplete response, a tool call with malformed JSON arguments, a response with neither text nor a call, and an over-budget input all have their own codes, and transport errors come back with a retryable flag and retry-after when the provider supplies one. Credentials are redacted out of everything returned to the graph.
Install
Same pack, same install as the rest of it - ComfyUI Manager or:
cd ComfyUI/custom_nodes
git clone https://github.com/RevenueMonkey/RM-Comfyui-LLM.git
Restart, refresh, look under RM/API. No pip installs, no downloads. Update with git pull --ff-only.
Gotchas worth knowing before you build
It's OpenRouter only, and your credential must be an environment variable. The main RM-LLM node has an agent_request socket too, and there it goes further: a masked session key is refused outright, model settings have to live in parameters_json, user_prompt must be a JSON array of conversation items, system_prompt becomes the instructions, and video is rejected. Route tool conversations through environment variables and you'll avoid all of it.
It supports function tools only. Provider-side tools are rejected on the spot, so if you were hoping the model would browse the web for you, that's not this node - that's the provider-executed path, which the README notes the pack deliberately doesn't drive.
A model that can't do tools fails cleanly, which is the good news. The capability check happens before the request, so you get a named error rather than a provider 400.
And the usual caveat for this whole pack. It's days old, from one author, with zero footprint in the community corpus I can search - no threads, no issues, no reputation either way. It's a key-holding node that calls the network by design, which is precisely the shape of the one node in this ecosystem that shipped malware. Read it before you trust it with a funded key.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| profile | RM_LLM_AGENT_PROFILE | — | |
| request | RM_LLM_AGENT_REQUEST | — | |
| imageopt | IMAGE | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| result | RM_LLM_AGENT_RESULT | — |