Proxy GPT Image Generator
Run GPT Image in ComfyUI through any OpenAI-compatible proxy
- reference_image_1
- reference_image_2
- reference_image_3
- reference_image_4
- image
- image_source
- response_summary
The name oversells it slightly. This node doesn't call OpenAI directly, and it doesn't need you to be the official API either. It's a generic OpenAI-compatible image client: you point it at any proxy that speaks /v1/images/generations or /v1/chat/completions, paste a key, and a closed model like GPT Image drops back into your graph as a normal IMAGE tensor. It's a reseller-ecosystem node, aimed at the crowd that's routing around the first-party API for cost, region, or billing reasons - the same proxy layer the KB's [external-api-nodes.md] describes as the reseller market around every closed model.
Why reach for it? Because GPT Image has no open weights, so "local" isn't an option at any VRAM. If you want it inside a ComfyUI workflow you're calling someone's server, and this node is the plumbing. Its real selling point isn't the happy path though - it's what happens when the proxy misbehaves.
How it works
Under the hood it's a requests.post with Authorization: Bearer <api_key> to base_url + api_route. Then the interesting part: instead of expecting one rigid response shape, it walks the returned JSON for whatever looks like an image - b64_json, a data:image/... URL, raw base64, or an http(s) image URL in fields like url, image_url, images, content, file_url. If the proxy sends back raw image bytes (content-type: image/*), it decodes those directly. Found something? It downloads or decodes into a Comfy IMAGE tensor. Found nothing? It raises a hard error.
That fail-loudly behavior is the design, and it's the reason this pack exists. The README is explicit: the author built it to replace flaky GPT-image proxy nodes that quietly returned a white placeholder image when the upstream failed - which then looked like a successful generation and sent everyone chasing the wrong problem. This node would rather crash your queue than gaslight you with a blank frame.
Two implementation details worth knowing: RGBA images get composited onto a white background before conversion (so a genuinely transparent PNG doesn't masquerade as a "blank" one), and response_summary redacts long base64 strings so debugging output doesn't balloon your workflow JSON.
The inputs that matter
Most of the widget list is passthrough - whatever the proxy accepts, it forwards. The ones you'll actually touch:
- base_url + api_key - the only required pairing, and they must belong to the same service. Default
base_urlishttps://greenapi.ink; change it to your own proxy and put that proxy's key in. - api_route - the enum that matters.
/v1/images/generationsis the OpenAI Images-style body. Some proxies wrap image models behind/v1/chat/completionsinstead; flip the switch and the node sends an OpenAI-style message with your prompt and optional reference images asimage_urlcontent parts. - model - free-form string, default
gpt-image-2. Whatever your proxy exposes. - prompt - the only required text. An empty prompt is rejected before it reaches the server.
- size, quality, background, output_format - forwarded verbatim; sane defaults (
1024x1024,medium,opaque,png). - reference_image_1…4 (optional
IMAGE) - any connected image is base64'd into a data URL and sent along; on the images route it lands in animagesfield, on the chat route as image content parts.
Outputs: image (IMAGE) wires straight into PreviewImage, SaveImage, or anything a local sampler feeds. image_source (STRING) and response_summary (STRING) are your diagnostics - hook both to PreviewAny and you can see exactly what the proxy claimed to return.
Installing it
No model downloads, no heavy deps - the only requirement is requests, which ComfyUI ships anyway.
cd ComfyUI/custom_nodes
git clone https://github.com/kulefanle/comfyui_proxy_gpt_image_node
Then restart ComfyUI. Or just search "comfyui_proxy_gpt_image_node" in ComfyUI Manager and hit install. The node lives under api/proxy in the add-node menu.
Common issues
HTTP 401 - your key and base_url are from different services, or the account lacks model access. Matching pair, then it goes away.
did not contain a usable image - the proxy returned success JSON with no URL, data URL, or b64_json anywhere. This is the "wire response_summary to PreviewAny" moment: the actual payload is sitting in that output.
Still white? Check image_source first. Real URL but white preview means the download/decode path failed. Empty or auto means the upstream never returned a real image - it's the proxy's fault, and now the error message tells you so.
One genuine gotcha that's not a bug: the API key is stored as a widget value in the workflow JSON. Don't share a workflow with a real key in it - that's the same credential-exposure trap the KB flags for every API-wrapper node. If one leaks, rotate it at the provider. And since this node is designed to hold a key and phone home, it's the exact shape of thing you should only install from the official repo.
Inputs (14)
| Name | Type | Default | Description |
|---|---|---|---|
| api_key | STRING | — | |
| base_url | STRING | https://greenapi.ink | — |
| api_route | COMBO | /v1/images/generations | 2 options: /v1/images/generations, /v1/chat/completions |
| model | STRING | gpt-image-2 | — |
| prompt | STRING | a red apple on a wooden table, realistic photo | — |
| size | COMBO | 1024x1024 | 4 options: 1024x1024, 1024x1536, 1536x1024, auto |
| quality | COMBO | medium | 4 options: low, medium, high, auto |
| background | COMBO | opaque | 3 options: opaque, transparent, auto |
| output_format | COMBO | png | 3 options: png, jpeg, webp |
| timeout_seconds | INT | 18010–900 | — |
| reference_image_1opt | IMAGE | — | |
| reference_image_2opt | IMAGE | — | |
| reference_image_3opt | IMAGE | — | |
| reference_image_4opt | IMAGE | — |
Outputs (3)
| Name | Type | Description |
|---|---|---|
| image | IMAGE | — |
| image_source | STRING | — |
| response_summary | STRING | — |