Omni Node Guide

OmniNodeGuide doesn't touch an image, a model, or a latent. It has no outputs at all. What it holds is the configuration that makes the pack's AI-powered Omni Node work: your OpenRouter API key, the model that writes your node code, and the knobs that control how hard that model thinks. You drop one of these into any graph that contains an OmniNodeAPI, fill in the key, and the whole thing starts functioning.

It's the quiet partner node. The interesting mechanics live in OmniNodeAPI; this is the node you configure once and forget - until you paste it into a shared workflow and realize everyone else needs their own key in it.

How it works

When the Omni build route needs to generate node code, it scans the graph for a node of class OmniNodeGuide, reads its inputs, and uses them to call OpenRouter's chat completions endpoint. The api_key is the bearer token (the tooltip says it plainly: Supported: OpenRouter), model picks which model writes the code, and reasoning_effort / service_tier control how the model is run on OpenRouter's side. If you leave system_prompt empty, the node falls back to the pack's bundled system prompt (workflows/omni_node_system_prompt.txt) - a long, carefully written instruction set that teaches the model how to write a valid ComfyUI node class for the Omni runtime. That file is the real secret sauce; it's why the generated code tends to come back structurally correct instead of confident garbage.

The node also hunts the graph for the OmniNodeAPI's prompt input, sends it along with the system prompt, takes the model's generated class, strips the markdown fences, and pushes it back to the UI. It executes as a normal graph node (hence the execute function), which means the generation happens when the workflow runs.

The inputs that matter

• api_key - your sk-or-v1-... OpenRouter key. The only mandatory thing.
• model - the writer model, default openai/gpt-5.6-luna. Change it to any model on OpenRouter that's good at code; this is the single biggest quality lever after the key.
• reasoning_effort - none/minimal/low/medium/high/xhigh. The default none is fastest and cheapest and gets you decent scaffolding; bump it when the generated node comes back broken.
• service_tier - default/flex/priority. OpenRouter's routing tiers; default is fine.
• system_prompt (optional) - override the bundled instructions if you want to steer the model.

Outputs: none. It's a config node - expect nothing on the canvas.

Install and setup

Part of the Rebalance Pack. ComfyUI Manager: search "ComfyUI-Conditioning-Rebalance" (or "Rebalance Pack"). Manual:

cd ComfyUI/custom_nodes
git clone https://github.com/nova452/ComfyUI-ConditioningKrea2Rebalance

Restart. You'll also want the requests package available (the API calls use it), and an OpenRouter account with a key. Grab one at openrouter.ai - they accept credit card or prepaid credits, and generation is metered per token.

Troubleshooting

The two failures that matter. First: the API call hard-fails if the key is missing or doesn't start with sk-or-, with a clear runtime error - so if generation "doesn't happen," check the key on this node before anything else. Second, and sneakier: the model name. openai/gpt-5.6-luna is the default, but if you (or a workflow you downloaded) set a model that doesn't exist on OpenRouter, you'll get a 404-ish failure from the API. Use a model you can actually see in OpenRouter's catalog. One more practical note: keys in a graph are visible to anyone you share the workflow with, so don't post your graphs with your real key in them - use OpenRouter's ability to create a low-balance key, or a key with a spending cap, for shared workflows.