Lumi OpenRouter Imagen Provider
Gemini imagen through OpenRouter — one key, one bill, no Google account juggling
- provider
Lumi OpenRouter Imagen Provider is the "keep it simple" route to Gemini image generation. Where the Google provider talks directly to Google's API, this node routes the same imagen models through OpenRouter - which means you authenticate with the exact same OPENROUTER_API_KEY you already use for LLM work. One key, one account, one bill. The tradeoff, and the pack is upfront about it: OpenRouter is roughly 4x slower than going direct. It's the convenience option, not the fast one.
Like every provider in this pack, it does nothing by itself. It packages a model choice plus a credential into an IMAGEN_PROVIDER object and hands it to Lumi LLM Imagen Processor, where the actual generation happens.
The inputs that matter
- env_key - which environment variable holds the key. Defaults to
OPENROUTER_API_KEY. - model - a dropdown of the imagen-capable Gemini models OpenRouter exposes. The default is
google/gemini-2.0-flash-preview-image-generation, withgemini-3-pro-image-preview,gemini-3.1-flash-image-preview, andgemini-2.5-flash-imagealongside. Unlike the LLM provider, which pulls the full OpenRouter catalog at startup, this list is hardcoded to image-capable models - no digging through hundreds of text-only models to find the one that draws.
The single output, provider, wires into the processor along with a Lumi Gemini Imagen Config node.
When this is the right pick
Honestly? When you already live on OpenRouter. If your LLM enhancement pass and your image generation sit in the same workflow, running both through one provider means one env var, one billing account, and no second API key to lose in a .bashrc you forgot to source. It's also a decent fallback if your direct Google quota is exhausted - the same model via a different front door. Just know what you're trading: every image takes several times longer to come back, which gets old fast when you're iterating on prompts. The direct Google provider is the pack's stated recommendation for a reason.
Installing
cd ComfyUI/custom_nodes
git clone https://github.com/illuminatianon/comfyui-lumi-tools
cd comfyui-lumi-tools
uv sync
Restart ComfyUI, or install "Lumi Tools" through ComfyUI Manager. No model files - this is pure API plumbing. The key setup is the usual dance:
export OPENROUTER_API_KEY=sk-or-v1-...
What to watch for
Two things. First, the env var error that plagues every key-based node - "API key not found in environment variable" almost always means the var isn't visible to the ComfyUI process (you exported it in a shell, but launched ComfyUI from elsewhere). Second, the speed tax: if every generation feels like it's hanging, that's just OpenRouter imagen being slower, not a frozen node. The pack's failure mode is fail-fast with retries on transient errors, so a genuinely dead call will surface as an error, not silence. And since this provider (like its Google sibling) refuses to cache itself, your key never gets baked into saved workflow files.
Inputs (2)
| Name | Type | Default | Description |
|---|---|---|---|
| env_key | STRING | OPENROUTER_API_KEY | Environment variable name containing the OpenRouter API key |
| model | COMBO | google/gemini-2.0-flash-preview-image-generation | Select the imagen model to use |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| provider | IMAGEN_PROVIDER | — |