Lumi LLM Imagen Processor

This is the payoff node. Lumi LLM Imagen Processor is where the pack actually generates an image - it takes a provider, a config, and a prompt, calls a Gemini imagen model, and hands you back a ComfyUI IMAGE tensor you can preview, save, or feed into the rest of your graph like any locally-generated image. If you've wanted Gemini's image generation in your ComfyUI workflows without leaving the canvas, this is the node that makes it happen.

The three inputs that matter

• provider (IMAGEN_PROVIDER) - from Lumi Google Imagen Provider (direct, ~4x faster) or Lumi OpenRouter Imagen Provider.
• config (IMAGEN_CONFIG) - from Lumi Gemini Imagen Config. That's where aspect ratio, resolution, and temperature live; this node stays stateless.
• prompt - what to draw. Multiline, so write a real description.
• seed - sent to the API where supported and always forces ComfyUI to reprocess, so bumping it guarantees a fresh call.
• error_mode - fatal (default) raises on failure and kills the job; return_text is the gentler path: it returns a placeholder image and pushes the diagnostics into the text output instead of crashing.

Two more optional inputs are worth knowing: instructions (a system prompt for the model, handy for style constraints) and input_images (a LUMI_IMAGE_CHAIN - the ordered image chain from Lumi Load Image nodes, which lets you do multimodal edits where Gemini sees your reference images before drawing).

What comes out

Two outputs:

• images - an IMAGE tensor, batch dimension included, so multiple returned images stack like any ComfyUI batch. Wire this to a preview or Lumi Save Image.
• text - whatever text the model produced alongside the image (often a caption or a "here's what I made" note). Also where return_text mode puts diagnostics.

How it works under the hood

Plain requests, no provider SDKs. The processor builds the payload the same way whether you're direct or via OpenRouter, POSTs it with a 120-second timeout, then decodes the base64 image data in the response into a tensor. It validates that your provider and config are compatible (matching model families), caps resolution to what the model actually supports - gemini-2.5-flash-image is 1K only, the 3.x image models go to 4K - and seeds are clamped to fit the API. The design doc is explicit about the failure philosophy: fail fast, no silent skips, and if you hit rate limits "that's on you."

Installing

cd ComfyUI/custom_nodes
git clone https://github.com/illuminatianon/comfyui-lumi-tools
cd comfyui-lumi-tools
uv sync

Restart ComfyUI (or search "Lumi Tools" in ComfyUI Manager). No weights to download - the whole imagen side is API calls, so you need a GOOGLE_API_KEY (or OPENROUTER_API_KEY) in the environment.

Real-world gotchas

The two things that trip people: forgetting the config node entirely (the processor needs both provider and config - one without the other is a hard error), and quota. Free Google tiers throttle imagen generation hard, and in fatal mode that means a dead batch. If you're iterating a lot, return_text mode plus a bumped seed keeps you informed instead of dead. And don't expect local-sampler determinism: the same seed on a paid API is closer to "similar composition" than "pixel-identical" - treat runs as samples.