Superside Grok Imagine Image v2 Edit

Superside Grok Imagine Image v2 Edit wraps xai/grok-imagine-image/v2.0/edit on fal.ai. It's an API node, so the honest framing first: you reach for it when you want a look you cannot get locally. Grok/Aurora is closed, and it's the least restrictive of the mainstream hosted models - either the reason you're here or the reason you're not. Everything you wire in goes to xAI's servers, the filter follows the model rather than the node, and there's no abliteration trick for weights you don't have. If an open edit model gets you there, use it.

What you get is a decent multi-image editor with a small, predictable control surface, returned as a normal IMAGE, and defaults aimed at one production pattern: crop-stitch inpainting - crop a region out, edit it at full resolution, paste it back. Anyone who has done that with a hosted editor knows the paste is where it goes wrong.

The crop-stitch problem, and what output_size does

Grok takes aspect_ratio and resolution - 1k or 2k - and that's it. Unlike GPT Image 2, there is no width/height, so you cannot ask it for the exact pixel size of the crop you're editing. A crop is rarely a neat 3:2, so hand the result to a stitch node that rescales it straight onto the crop rectangle and you get a visibly stretched edit.

output_size closes that hole. Left on the default, match input image_1 (crop-stitch safe), the node takes whatever Grok returned and fits it to image_1's exact width and height using the same cover-then-centre-crop maths a resize node would - scaled up until it covers, then centre-cropped, never squashed. If that crops more than 8% of the generated area away, it warns you in the log and suggests setting aspect_ratio to auto, which is the fix: on auto Grok follows image_1's own ratio and there's almost nothing left to trim. Set output_size to fal native (aspect_ratio + resolution) only when you want the raw output shape and nothing downstream cares.

The inputs that matter

Required: prompt, image_1, api_key.

Three optional images, image_1 through image_3. There is no mask input anywhere on this node - Grok has no mask concept, and every wired image is just a reference the model blends. This is the number one way people break a crop-stitch graph: wire a mask image into image_2 the way you would on an editor that takes one, and Grok paints the mask's white area into the result. In a crop-stitch graph, wire only cropped_image into image_1 and leave the other two slots for genuine reference photos.

reference_max_dimension (default 0, off) caps the long side of image_2/image_3 on upload; image_1 always goes at full size. Why it exists: Grok's API takes one flat list of "images to edit" with no designated base image, so a reference that out-resolves image_1 can end up driving the result - a 4700px product shot against a 2700px crop invites Grok to hand back the product instead of the edited crop. Cap it at roughly image_1's size and that stops.

Then the ordinary dials: aspect_ratio (fourteen options, default auto), resolution (1k/2k), quality (low/medium, default medium), output_format (jpeg/png/webp), num_images (1-4) and sync_mode. Set output_format to png if the result gets composited or stitched - you don't want jpeg ringing sitting on your seam.

Outputs are images (IMAGE) and revised_prompt (STRING) - the prompt Grok actually ran. Worth wiring into a text display for the first few runs, because hosted models rewrite as they please.

Cost, since it's per call

fal's published price at the time of writing: $0.04 (low) / $0.06 (medium) per 1K image, $0.06 / $0.08 per 2K image, plus $0.01 per input image. Three input images and one 2K output at medium is about eleven cents - and num_images multiplies it. The node shows its price in green text under the body; before you queue forty of them, put a Superside Fal Cost Report at the end of the graph and read the total.

Install

cd ComfyUI/custom_nodes
git clone https://github.com/Superside/comfyui-superside-nodes
cd comfyui-superside-nodes && pip install -r requirements.txt

Restart, then type "Superside" in the node search. requirements.txt is light - fal-client, pillow, numpy, torch, requests. No model downloads, no compilation. ComfyUI Manager can install by repo URL too.

The API key, and the gotcha around it

There is no config file. Every node has an api_key widget and the normal flow is pasting the key in once per node. If you leave it blank, the node falls back to the FAL_KEY environment variable - that exists for headless deployments that would otherwise embed the key as literal text in the workflow JSON, where it shows up in request logs. On a shared, multi-tenant ComfyUI, do not rely on that fallback: the explicit per-workflow key input is the access-control gate. Blank on both counts fails immediately with an error, which is at least loud about it.

Two smaller notes: leave sync_mode off (the pack routes slow endpoints through fal's queue with a bounded timeout, since long-held connections drop mid-generation), and restart ComfyUI after any git pull - new widget UIs don't load without it.

One honest caveat: there is essentially no community discussion of this endpoint. That's a house pipeline node - a production workflow shipped in public - not one with a forum consensus to lean on.