Image generation’s deepest integration problem isn’t the request formats — it’s that model capabilities genuinely differ. Supported resolutions, aspect ratios, reference-image counts, batch sizes, and streaming support vary model by model. Normalizing field names without addressing those differences just trades one flavor of 400 error for another. The Unified Image API OpenRouter launched on June 23 takes the other path: alongside a single request shape, every model’s capabilities, parameters, and pricing become queryable schema. Per the announcement, this dedicated API gives unified access to 30+ models from Google, OpenAI, Black Forest Labs, Recraft, ByteDance, Sourceful, Microsoft, and xAI, with more on the way.
Query capabilities before you send
The core split is simple: capabilities come from /api/v1/images/models, generation goes to POST /api/v1/images (authenticated with a Bearer API key). The former returns typed capability descriptors for each model — supported resolutions and ratios, max images per call, reference-image limits, seed support, streaming support — as structured fields, not marketing copy.
The gaps are bigger than you would guess. Per the announcement: Seedream 4.5 supports 18 aspect ratios while Gemini 3.1 Flash Image supports 14 — overlapping but not identical. Some models generate up to 10 images per call; others cap at 1. Input-reference limits vary too, and the post’s prose says some models accept 16 references while others accept 4. One detail worth flagging: the same post’s Seedream 4.5 descriptor example shows an input_references range of 0 to 14 — prose and example disagree, so cite the section you are quoting. Rather than guessing, read the descriptor:
{
"resolution": { "type": "enum", "values": ["1K", "2K", "4K"] },
"n": { "type": "range", "min": 1, "max": 10 },
"input_references": { "type": "range", "min": 0, "max": 14 },
"seed": { "type": "boolean" },
"supports_streaming": false
}That is an abridged excerpt of the announcement’s descriptor for bytedance-seed/seedream-4.5 — id, the supported_parameters wrapper, and aspect_ratio are trimmed here; the values shown match the source. Your code — or your coding agent — can validate parameters locally before sending, instead of hardcoding each provider’s limits into separate adapters and paying for trial-and-error. And as the model list keeps growing, hardcoded limit tables age fast; the descriptor turns adapter logic into one query plus a cache.
One request shape, three billing units
On the request side, resolution, aspect_ratio, quality, output format, background transparency, input references, and streaming are normalized across providers. Provider-specific options like Black Forest Labs’ steps and guidance pass through provider.options keyed by the provider slug, and every endpoint publishes an allowed_passthrough_parameters list naming exactly which keys it accepts — no guessing about what passes through.
A single model can be served by multiple providers, and /api/v1/images/models/{id}/endpoints returns what each endpoint actually accepts, its streaming support, and granular pricing. Each endpoint response carries a pricing array; Seedream 4.5’s entry reads {"billable": "output_image", "unit": "image", "cost_usd": 0.04} — the billable output, its unit of measure, and the price in a single row, so a cost estimator reads data instead of docs. Pricing is where this API is most honest, because billing units are not unified:
| Model (per announcement) | Billing unit | Price |
|---|---|---|
| Seedream 4.5 | per image | $0.04 |
| FLUX.2 Pro | per megapixel | $0.03, and resolution drives the bill |
| GPT-5.4 Image 2, Gemini 3.1 Flash Image | per token | usage-based |
The three units imply three cost curves: per-image pricing is resolution-independent and easiest to estimate; per-megapixel pricing scales linearly with resolution — the announcement publishes the unit price, and any 1K-versus-4K multiplier is your own arithmetic, not a published figure; per-token pricing depends on actual generation effort and can only be estimated as a range up front. Cost-aware routing means normalizing those three units into comparable estimates before comparing them — and the usage object in every response includes the exact cost in USD, so reconciliation requires no guesswork.
Streaming previews, and who should migrate
Streaming support isn’t uniform either. Per the announcement, the OpenAI GPT Image family — GPT-5 Image, GPT-5 Image Mini, GPT-5.4 Image 2 — supports native SSE streaming: set stream: true and you receive partial image previews as they render. For renders that take a while, those previews turn “still working” into visible progress instead of a spinner holding the whole wait. For everything else, check the supports_streaming field; don’t assume.
There is one explicit migration line. Existing image models keep working in completions/responses, but new image models will be added exclusively to the dedicated Image API. OpenRouter recommends that users of openai/gpt-5-image, gpt-5-image-mini, and gpt-5.4-image-2 move to the dedicated image models: those versions generate images through an LLM, have incomplete parameter sets, and may incur extra inference cost. If your product still runs the old path, this launch is the reason to move — the cost of staying on completions goes beyond incomplete parameters: every future image model ships without you.
What’s unified is the wiring, not visual quality
Set expectations honestly: the unified API solves integration maintenance, not visual consistency. The same prompt across models yields different styles, and reference-image handling differs. Products should keep their own evaluation sets for critical models — composition, text rendering, character consistency, safety policy — questions an API cannot answer for you.
Capability descriptors make switching models reliable; they do not turn models into interchangeable parts. Model selection and quality evaluation remain your homework. (This section’s framing is the author’s judgment, not announcement content.)
The builder’s checklist
Three actions you can ship now. First, query /api/v1/images/models at startup and cache the capability schema for local validation — stop burning runtime calls on trial-and-error. Second, when routing on cost, normalize billing units into comparable estimates first, then reconcile against the per-response usage cost. Third, if you are still generating images through chat completions, follow the official advice and move to the dedicated image models — full parameter sets, without the extra inference cost. Start exploring in the playground; details live in the docs.
Sources
AI-assisted summary compiled from the sources above, reviewed by a human before publishing.