You wire up an image generation provider, get it working, and then a week later, you need to read an image. Maybe OCR on uploaded receipts, a quick object-detection pass before saving an asset, or alt-text generation for accessibility. That’s a different job. With most providers, it means a second SDK, a second API key, and a second billing relationship.
On OpenRouter：https://openrouter.ai/, both jobs run through one base URL, https://openrouter.ai/api/v1 , with one API key and one bill. To generate an image, POST a prompt to /images . To read one, send it to a vision model on /chat/completions .
The model catalog：https://openrouter.ai/docs/guides/overview/models behind those endpoints covers the major image labs, and provider routing and failover work on image calls the way they do on chat calls.
Yes, through one base URL and one API key. To generate an image, POST a prompt to the dedicated Image API. To read one, send it to a vision model on the standard Chat Completions endpoint：https://openrouter.ai/docs/quickstart.
An app that already generates images can add vision capability with the same key and billing account. Only the endpoint and the request shape change.
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：https://openrouter.ai/collections/image-models.
Send a POST to /api/v1/images with a model and a prompt. The images come back in the data array as base64.
Each entry in data carries the image as base64 in b64_json , plus a media_type field (typically image/png ; Recraft vector models can return image/svg+xml ). The usage field reports token counts and the request’s cost. Request up to 10 images per call with n (not every provider supports n > 1 ), and iterate data rather than hardcoding index 0.
The request body takes image-specific fields directly:
Check the model’s supported_parameters in GET /api/v1/images/models for what each endpoint accepts. 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：https://openrouter.ai/docs/guides/overview/multimodal/image-generation covers the full request schema.
Send a messages array containing a text part and an image_url part to a vision model on /chat/completions . You get a text completion back. The image_url accepts either a public URL or a base64 data URL.
The response comes back as a standard text completion, with the model’s answer in choices[0].message.content .
For PDFs, use the file content type rather than rendering pages to images first. OpenRouter also supports audio and video inputs through the same endpoint, using the same pattern of swapping the model and content type. The multimodal overview：https://openrouter.ai/docs/guides/overview/multimodal/overview covers every input type.
Use generation when the output is a new visual asset: mockups, product shots, illustrations, marketing creative, anything that begins as a text prompt and ends as pixels.
Use understanding when you already have an image and need information from it: OCR on receipts and forms, accessibility alt-text, object or defect detection on a production line, classification, or plain description.
The endpoint you call tells us which job you’re doing. Generation posts to /api/v1/images ; understanding posts to /chat/completions . Both use the same API key and land on the same bill.
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：https://openrouter.ai/docs/guides/features/server-tools/image-generation covers the available parameters.
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.
This request prefers one provider and falls back to the next if it fails. Vision calls on /chat/completions take the full chat provider object：https://openrouter.ai/docs/guides/routing/provider-selection, including data_collection: "deny" .
You pay the catalog rate with no markup from us：https://openrouter.ai/pricing. 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：https://openrouter.ai/blog/insights/model-routing/.
Not at the moment. The free tier：https://openrouter.ai/pricing 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：https://openrouter.ai/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. The free models guide：https://openrouter.ai/blog/tutorials/free-llm-apis-compared/ covers the free tier’s mechanics for text models.
This error means you sent an image_url to a model that doesn’t accept image input. We auto-filter available models by request content：https://openrouter.ai/docs/guides/overview/multimodal/overview, so when the model you named has no available endpoint that supports images, the request fails with this error instead of silently dropping the image.
Sibling errors like no endpoints found that support tool use and the data-policy variants work the same way. The error names the requirement that didn’t match; relax it or pick a model and provider combination that meets it.
Start with the image model catalog：https://openrouter.ai/collections/image-models, test a prompt in the Chatroom, and wire the call with the snippets above.
Yes, through one base URL and one API key. To generate an image, POST a model and a prompt to https://openrouter.ai/api/v1/images . To read one, send it as an image_url to a vision model on /chat/completions . Both land on the same bill.
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：https://openrouter.ai/models?output_modalities=image or browse the image model collection：https://openrouter.ai/collections/image-models for the current lineup and pricing.
You sent an image_url to a model 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.
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.
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. Vision calls on /chat/completions take the full chat provider object, including data_collection: "deny" .
In the response’s data array; each entry has b64_json with the base64-encoded image bytes and a media_type field (typically image/png ). Request up to 10 images per call with the n parameter and iterate data rather than hardcoding index 0.
Scan to open this article