Nodes/comfyui-lumi-tools/Lumi OpenRouter Imagen Provider
ComfyUI Node

Lumi OpenRouter Imagen Provider

Gemini imagen through OpenRouter — one key, one bill, no Google account juggling

By illuminatianon·Created 9 months ago·Updated 4 months ago· 0
Lumi OpenRouter Imagen Provider
    • provider
    env_keyOPENROUTER_API_KEY
    modelgoogle/gemini-2.0-flash-preview-image-generation

    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, with gemini-3-pro-image-preview, gemini-3.1-flash-image-preview, and gemini-2.5-flash-image alongside. 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.

    CategoryLumi/LLM

    Inputs (2)

    NameTypeDefaultDescription
    env_keySTRINGOPENROUTER_API_KEYEnvironment variable name containing the OpenRouter API key
    modelCOMBOgoogle/gemini-2.0-flash-preview-image-generationSelect the imagen model to use

    Outputs (1)

    NameTypeDescription
    providerIMAGEN_PROVIDER