Qwen Image Edit (API) [LP]
Instruction-based photo editing without loading the model yourself
- image1
- image2
- image3
- images
- json_response
Qwen-Image-Edit is the model that made a lot of masked inpainting unnecessary: you hand it a picture and a sentence - "change her dress to blue," "remove the watermark" - and the edit just happens, no mask, no ControlNet, no separate adapter. It's Apache 2.0, which is a big part of why it exploded the way it did (Flux Kontext's license treats an NSFW fine-tune as a violation; Qwen's doesn't say anything about content at all), and by 2026 it had absorbed the job that used to need a mask plus a ControlNet plus an IP-Adapter stacked together. This node is a way to use it without any of that running on your own machine.
What this node actually is
Read the category carefully: LevelPixel/API/Qwen. This isn't the local diffusion pipeline - it's not loading a 20B checkpoint into your VRAM. It's an API node that calls a hosted Qwen Image Edit endpoint and hands you back the result. That matters for two reasons. First, it means you skip the very real VRAM problem the actual model has (20B at full precision doesn't fit on a consumer card, which is why the local version lives and dies by community GGUF quantizations) - the API node sidesteps all of that. Second, it means you're dependent on whatever credentials that hosted endpoint requires, which the pack's README doesn't spell out in any detail. If the node fails on first run with an authentication-shaped error, that's almost certainly what's happening - check the node's own error output before assuming it's broken.
How it works, and what it's good for
You're not driving raw diffusion parameters here - you're writing an instruction, the same way you'd talk to the actual model. That's the whole design of Qwen-Image-Edit: object removal, garment swaps, relighting, background changes, re-posing, all through plain-language prompts rather than a mask stack. The honest limitation, true of the underlying model regardless of how you're calling it, is that it re-emits the whole frame rather than patching just the region you asked about - pixels you didn't touch can still drift slightly, and that drift compounds if you chain edits. If pixel-perfect preservation outside the edited region matters, this isn't the tool; a masked inpainting workflow still guarantees more.
Inputs and outputs that matter
image1(required) - the image you're editing.positive_prompt(required, multiline) - your instruction in plain language.image2/image3(optional) - additional reference images, for compositing two or three inputs together (person + product, person + scene) rather than editing one image alone.negative_prompt(optional) - what to steer away from.n(default 1, max 6) - how many variations to generate in one call.width/height(default 0 = auto, up to 2048, tooltip-documented on the node itself as "0 = auto") - set these if you need a specific output size; leave at 0 to let the service decide.prompt_extend(default on) - likely a server-side prompt-expansion step; the node doesn't elaborate further than the name.watermark(default off) - whether the API stamps the output.seed(default 0, tooltip: "0 = do not send, server picks") - set a nonzero value if you want a reproducible result; leave at 0 and the service will pick one for you each call.
Outputs: images, the edited result(s), and json_response, the raw API response as a string - feed that straight into Parse JSON String from this same pack if you want to pull structured data out of it rather than eyeballing raw text.
Installing it
Through ComfyUI Manager, search "ComfyUI Level Pixel" or "ComfyUI-LevelPixel." Or by hand: git clone https://github.com/LevelPixel/ComfyUI-LevelPixel.git into custom_nodes and restart. No model weights to download for this specific node - it's a network call, not local inference - but that also means it needs internet access and whatever credentials the hosted endpoint expects, which is where the README goes quiet.
Where people get burned
Because this is an API call rather than local inference, the usual local-model troubleshooting (VRAM, GGUF quantization, missing checkpoints) doesn't apply - and doesn't help you if something goes wrong. Watch for rate limits or auth failures instead, and expect n above 1 or larger width/height values to cost more per call if the service is metered, since you're not paying in GPU time anymore, you're paying whatever the API charges. And if you actually need the fine control the real model offers - depth/edge/keypoint conditioning, a specific quantization, running fully offline - that's the local Qwen-Image-Edit workflow, not this node; this one trades that control for not having to manage any of it yourself.
Inputs (11)
| Name | Type | Default | Description |
|---|---|---|---|
| image1 | IMAGE | — | |
| positive_prompt | STRING | — | |
| image2opt | IMAGE | — | |
| image3opt | IMAGE | — | |
| negative_promptopt | STRING | — | |
| nopt | INT | 11–6 | — |
| widthopt | INT | 00–2048 | Output width in px (512-2048). 0 = auto. |
| heightopt | INT | 00–2048 | Output height in px (512-2048). 0 = auto. |
| prompt_extendopt | BOOLEAN | true | — |
| watermarkopt | BOOLEAN | false | — |
| seedopt | INT | 00–2147483647 | Random seed. 0 = do not send (server picks). |
Outputs (2)
| Name | Type | Description |
|---|---|---|
| images | IMAGE | — |
| json_response | STRING | — |