Image Generation Models: Choosing One, Fixing Errors
OpenRouter ·

The image generation tutorial walks through the request itself. You send a model and a prompt to POST /api/v1/images, decode data[0].b64_json, and write the bytes to disk. This article covers the two decisions that tutorial leaves to you. Which model goes in the model field, and what to do when the API returns an error instead of an image.
The model catalog behind the endpoint covers the major image labs, and the slugs change with every release. The catalog changes are why the model choice needs a method rather than a bookmark, and why a few error messages come up again and again.
Tl;dr
- Pick a model by the job first (text-to-image, editing a reference image, vector output, readable text), then by parameter support, then by price.
GET /api/v1/images/modelslists every model the Image API serves with the union of its providers’supported_parameters, and each entry links to a per-provider breakdown. - For data, our comparison ran one prompt through 20 models and recorded the bill for each, and the image benchmarks score 39 models on 15 prompts.
- No image model carries the
:freesuffix, so every generation draws on your credit balance. Low-cost models start around a cent per image. - “No endpoints found that support image input” means you sent an image to a model on
/chat/completionsthat doesn’t accept image input. Switch to a model whoseinput_modalitiesincludeimage. - On
/api/v1/images, a 400 or 404 that quotes your model slug is a slug, capability, or provider-filter problem. The troubleshooting section maps each message to its fix. - Once you have a model, the tutorial has the runnable Python and JavaScript for the call.
Which image models are available?
The catalog includes Google (the Gemini image family), OpenAI (GPT Image), Black Forest Labs (FLUX), xAI (Grok Imagine), ByteDance (Seedream), Microsoft (MAI-Image), Recraft, Krea, and Sourceful (Riverflow). Specific model names shift with every release, so for the current lineup, capabilities, and per-model pricing, use the image model catalog.
Three ways to find an image model:
- From code:
GET /api/v1/images/modelslists every model thatPOST /api/v1/imagesaccepts.GET /api/v1/models?output_modalities=imagereturns the broader set of image-output models, including ones that only generate through/chat/completions. - From the UI: The Models page filter surfaces the same results visually, with pricing visible at a glance.
- From the Chatroom: The image button lets you test prompts against a model before wiring them into an app, with no code.
How do I choose between them?
Start with the job. The catalog splits along a few capability lines, and each line maps to a field in the model record that you can check before you spend a credit. Unless the row says otherwise, the field comes from GET /api/v1/images/models.
| You need | Look for |
|---|---|
| A new image from a text prompt | Any model in the GET /api/v1/images/models list. The image collection shows the same models with pricing, plus a few that generate only through /chat/completions |
| An edit or variation of an existing image | input_references in supported_parameters |
| Readable text inside the image | Text-rendering scores in the image benchmarks |
| Editable vector output | svg in output_format (Recraft vector models) |
| A specific size or ratio | The resolution and aspect_ratio values the endpoint accepts |
| Several images per call | The n range (not every provider accepts n > 1) |
| Partial images while generating | supports_streaming: true |
| A picture and a text reply in one turn | Both image and text in output_modalities, called through /chat/completions |
Then price. One image at default settings billed between $0.006 and $0.134 across the 20 models in our comparison, a 22x spread, and on OpenAI models the quality setting alone moved the same image from $0.006 to $0.211. Pricing units differ too. Some endpoints bill per image, some per megapixel, and some per token, so a longer prompt costs more on a token-priced model and nothing extra on a per-image one. When the response includes usage, its cost field reports what that call billed, and recording it next to the model slug during test runs is the fastest way to build your own price table. usage is optional in the response schema, so fall back to the activity page for any call that omits it.
Then quality on your own prompts. The benchmarks and the comparison are a shortlist, not a verdict. Run three or four of your production prompts through the two or three finalists in the Chatroom before committing. For editing work specifically, the Nano Banana tutorial shows the reference-image flow end to end.
How do I check what a model supports?
GET /api/v1/images/models is the authoritative source. Each model’s top-level supported_parameters is the union across its providers, so if input_references, n, or a given aspect_ratio is missing there, no provider serves it and the request will fail. If it is present, at least one provider accepts it and routing narrows to those providers when you send it. To see which provider accepts what, follow the model’s endpoints URL (GET /api/v1/images/models/{author}/{slug}/endpoints), which lists each provider’s own supported_parameters. Check it before pinning a provider with provider.only or provider.order.
curl https://openrouter.ai/api/v1/images/models \
-H "Authorization: Bearer $OPENROUTER_API_KEY"
The parameters you’ll filter on most:
| Field | What it does |
|---|---|
resolution | Normalized tier, one of 512, 1K, 2K, or 4K |
aspect_ratio | Ratio from 1:1 up to extended values like 21:9, clamped to each provider’s supported subset |
quality | auto, low, medium, or high |
output_format | png, jpeg, webp, or svg (vector models only) |
input_references | Reference images (URL or base64) for image-to-image work |
n | Number of images per request, up to 10 where the provider allows it |
Providers can also take provider-specific options through provider.options, and models with supports_streaming: true can stream partial images over SSE with stream: true. The image generation doc covers the full request schema.
Do I need an image model or a vision model?
Two different jobs run through the same base URL and key, and confusing them produces the most-searched error in this article.
| Image job | Endpoint | Model needs | Tutorial |
|---|---|---|---|
| Generation (prompt to image) | POST /api/v1/images | image in output_modalities | Image generation |
| Understanding (image to text) | POST /api/v1/chat/completions | image in input_modalities | Send an image to an LLM |
Use generation when the output is a new visual asset. Use understanding when you already have an image and need OCR, alt-text, classification, or a description from it. Some models do both, and those are the ones that can return a picture and a text reply in a single chat turn.
There’s a third option for apps where the conversation itself should decide when an image is needed. The openrouter:image_generation server tool (beta) lets a chat model generate an image mid-conversation without your application code making that call explicitly. Add { "type": "openrouter:image_generation" } to the request’s tools array, and the model determines when to invoke it. It defaults to openai/gpt-5-image. The server-tool doc covers the available parameters.
Is there a free way to generate images?
Not at the moment. The free tier covers models with the :free suffix at 50 requests/day and 20 RPM with no credit card (1,000 requests/day with $10 or more in credits), and no image generation model currently carries that suffix. The free pool changes as models come and go, so it’s worth re-checking /models?output_modalities=image.
Generation therefore draws on your credit balance, but testing costs little. Per-image pricing on low-cost models starts around a cent, and each response’s usage.cost reports what the request cost when the endpoint returns usage. The free models guide covers the free tier’s mechanics for text models.
Do routing and failover work for image calls?
Yes. On /api/v1/images, the provider object accepts order, only, ignore, sort, and allow_fallbacks. An image model served by more than one provider can fail over between them if the first is unavailable or slow.
{
"model": "google/gemini-2.5-flash-image",
"prompt": "A minimalist logo for a coffee roaster",
"provider": {
"order": ["google-ai-studio", "google-vertex"],
"allow_fallbacks": true
}
}
This request prefers one provider and falls back to the next if it fails. You pay the catalog rate with no markup from us, and under Zero Completion Insurance, an image call that fails over and never completes isn’t billed. For how the router picks a provider, see how OpenRouter model routing works.
The same provider object is also the most common reason a request that used to work starts returning “No endpoint found”. The next section covers that.
How do I fix Image API errors?
Log the HTTP status, and log the response body only when the status isn’t 2xx. A successful body carries the image as base64 in data[].b64_json, often megabytes of it, which doesn’t belong in application logs. Every error below names the thing that didn’t match, and the fix follows from the message.
”No endpoints found that support image input”
This is a /chat/completions error, not an Image API error. You sent an image_url content part to a model that doesn’t accept image input. We filter available endpoints by request content, so when the model you named has no endpoint that supports images, the request fails with this 404 instead of silently dropping the image.
Fix it in three steps:
- Confirm the model supports image input. Its
input_modalitiesmust includeimage. Text-only models never will. - Find a vision-capable model. Run
GET /api/v1/models?input_modalities=image, or use the input modality filter on the Models page. - Update the model string in your request and resend.
Two variants narrow the cause further. “No endpoints found that support base64 image input” means the model takes images but its available endpoints only accept URLs, so host the file and send a URL. “No endpoints found that support image URLs” is the reverse, so fetch the file and send it as a base64 data URL.
Generation models can hit this too. Image generation still works on /chat/completions, and an image-to-image request there fails with this message when the generation model you named doesn’t accept image input. Pick a generation model whose input_modalities include image, or move the request to /api/v1/images and send the reference through input_references.
No model found for "<slug>"
A 404 from /api/v1/images. The slug isn’t in the catalog. Check for a typo, then check whether the model was retired or renamed, which happens often in the image catalog. Copy the slug from GET /api/v1/images/models or from the model’s page in the collection rather than from memory.
Model "<slug>" does not support image output
A 400 from /api/v1/images. The slug exists but it’s a text or vision model, not a generation model. google/gemini-2.5-flash reads images and google/gemini-2.5-flash-image generates them, and the same pattern holds across the catalog. Pick a model from GET /api/v1/images/models. That list is the image-output models with an Image API adapter, so it leaves out the handful of image-output models that only generate through /chat/completions.
No endpoint found for model "<slug>"
A 404 from /api/v1/images. The model exists and generates images, but every provider serving it was filtered out before the request went upstream. Common causes, in the order to check them:
provider.onlyorprovider.orderwithallow_fallbacks: falsenames a provider that doesn’t serve this model. Remove the list or setallow_fallbackstotrue.provider.ignorecovers every provider for the model.- Your account’s data policy excludes the endpoints that remain. The Image API’s
providerobject doesn’t takedata_collection, so this is set in privacy settings, not in the request. - The model has no active endpoint right now. The model page shows its providers and their status.
Remove the filters one at a time and resend after each change. The first one that makes the call succeed is the one to fix properly.
No provider for <slug> supports the requested parameter(s)
A 400 from /api/v1/images. You asked for a resolution, aspect_ratio, n, output_format, or other parameter that none of the model’s endpoints accept. The message lists the parameters it couldn’t satisfy and each provider’s reason for rejecting them. Drop the parameter, change it to a supported value, or pick a model whose supported_parameters include it.
Streaming is not supported with n > 1
A 400 from /api/v1/images. Partial-image streaming works for one image at a time. Either set n to 1 or remove stream.
401 and 402
A 401 means the request reached us without a valid key. Check that the process can read OPENROUTER_API_KEY without printing its value, and that the header is Authorization: Bearer <key>. A 402 means your available balance is at or below the Image API’s flat $1 pre-authorization. Every paid image request checks for more than $1 of credit before it runs, regardless of what the image will cost, and the actual charge is billed afterward. An account with $0.50 gets a 402 on a one-cent generation, so top up past $1 rather than sizing the deposit to the image. No image model is free, so a key that works for :free text models still needs credits for image generation.
The call succeeds but the image is wrong
- Missing
data[0].b64_json. Check the response body first. Confirm the request went to/api/v1/images, and iteratedatarather than hardcoding index 0 if you asked forn > 1. - Unexpected file format. Read
media_typefrom the response. Some models return JPEG or WebP bytes rather than PNG, and Recraft vector models returnimage/svg+xml. - Reference image ignored or rejected. Confirm
input_referencesappears in the provider’ssupported_parameterson the model’sendpointsURL, and that a local file is sent as a data URL with the right prefix, such asdata:image/jpeg;base64,. - Unexpected cost. Check the endpoint’s pricing unit before running a batch. Token-priced models bill more for longer prompts, and the
qualitysetting can move the bill by an order of magnitude on the same model.
Once the request works, the image generation tutorial covers saving the output, adding a reference image, and making the request reusable.
Frequently asked questions
Which image generation models are available on OpenRouter?
The catalog includes Google (Gemini image family), OpenAI (GPT Image), Black Forest Labs (FLUX), xAI (Grok Imagine), ByteDance (Seedream), Microsoft (MAI-Image), Recraft, Krea, and Sourceful (Riverflow). Filter /models?output_modalities=image or browse the image model collection for the current lineup and pricing.
How do I choose an image generation model?
Decide the job first (text-to-image, editing a reference image, vector output, readable text), then filter to models whose supported_parameters cover what you need, then compare per-image price. GET /api/v1/images/models returns the parameter support per endpoint, and usage.cost in each response reports what a call billed.
How do I fix “no endpoints found that support image input”?
You sent an image_url to a model on /chat/completions that doesn’t accept image input. Confirm the model’s input_modalities include image, find a vision-capable model with GET /api/v1/models?input_modalities=image, and update the model string in your request.
Why does the Image API say “No endpoint found for model”?
Every provider serving that model was filtered out before the request went upstream. The usual causes are a provider.only or provider.order list with allow_fallbacks: false that names a provider not serving the model, a provider.ignore list that covers them all, or a data policy the endpoints don’t meet. Remove the filters one at a time until the call succeeds.
Is there a free way to generate images on OpenRouter?
Not at the moment. The free tier (50 requests/day, 20 RPM, no credit card) covers models with the :free suffix, and no image generation model currently carries it, so generation draws on your credit balance. Low-cost models start around a cent per image.
Do routing and failover work for image calls?
Yes. The /api/v1/images endpoint accepts provider.order, only, ignore, sort, and allow_fallbacks, so ordering, cost/latency sort, and cross-provider failover work the same way as on chat.