FLUX 3 Image on OpenRouter: n=1, seed, base64 vs Sume

On OpenRouter, FLUX.3 Image is called as black-forest-labs/flux-3-image through its Image API or Chat Completions, and the page lists a hard limit of one image per request (n of 1), a seed, up to 10 input_references, resolutions from 768 to 4K, and a base64 PNG in the response (read 2026-10-03). Sume's POST /v1/images has the same general shape, but it returns hosted URLs instead of base64, it sets a different n ceiling per model, it does not serve seed, and it does not list FLUX 3 Image today.

If you are moving a script between the two, five fields change. The sections below take them in the order they break a call.

Which FLUX 3 Image parameters does OpenRouter list?

OpenRouter's page for the model lists these request fields: model, prompt, resolution (768, 1K, 1.5K, 2K, 4K), aspect_ratio (15 options including auto), n (the page says one image maximum, a single-provider constraint), input_references (up to 10 image URLs), and seed. The documented error codes are 400, 401, 402, 413, 429, and 502, with upstream 502 failures not billed.

Black Forest Labs' own bounding-box layout, which places each reference at a target box on a 0-1000 grid, is described in BFL's docs. The OpenRouter page does not list a field for it, so I could not confirm how or whether a box list is accepted there.

How does Sume's POST /v1/images differ field by field?

Sume's docs describe POST /v1/images with model, prompt, n, resolution, aspect_ratio, input_references, output_format, and mode. The table compares each OpenRouter field with its Sume counterpart, using Sume's docs and OpenRouter's page as read on 2026-10-03.

What does a Sume request for a FLUX-family image look like?

The nearest FLUX row on Sume is FLUX.2 Pro. The script below sends two images in one call and handles both response shapes, because Sume answers 200 with the images or 202 with a job when the 30-second budget runs out. It requests n of 2 on purpose: on OpenRouter's FLUX 3 listing that is above the listed maximum, which is the main behavior change when you port a loop.

import os
import requests

H = {"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"}
r = requests.post(
    "https://api.sume.com/v1/images",
    headers=H,
    json={
        "model": "black-forest-labs/flux.2-pro",
        "prompt": "a ceramic mug on a walnut desk, soft window light",
        "n": 2,
        "aspect_ratio": "4:3",
    },
    timeout=60,
)
body = r.json()
if r.status_code == 200:
    for img in body["data"]:
        print(img["url"])
elif r.status_code == 202:
    print("still running:", body["data"]["status_url"])
else:
    print(r.status_code, body)

Why does the one-image limit change your cost maths?

With a one-image ceiling, a four-variant moodboard is four calls on OpenRouter, each with its own latency and its own failure chance. On Sume the same ask is one call with n of 4 on a model whose catalog row allows it, and Sume's docs state that a generation is either completed and billed in full or fails and is not billed. Read the n range descriptor in GET /v1/images/models before you assume a ceiling: Sume's docs say per-model ceilings are lower than the global limit of 10, and Grok Imagine's row is a one-image model.

Pricing is also per image on both sides, so cost_usd × n is what a Sume call costs, from the endpoint record rather than from a table in a blog post. Neither OpenRouter's page nor this post gives a FLUX 3 price for Sume, because Sume has none to give yet; the FLUX 3 price note explains how to look up a Sume price when a row exists.

What breaks when you port a loop between them?

Four things, in the order you will hit them. First, base64 decoding code is dead weight on Sume: the response carries URLs, so you download them instead. Second, a seed argument returns 400 unsupported_parameter on Sume, so strip it and treat repeatability as something you get from saved references and the saved output, as the seed explainer lays out. Third, resolution: "2K" is only valid on the Sume models that publish a resolution tier; FLUX.2 does not, so read supported_parameters first. Fourth, expect a 202 for slow work and poll the job with GET /v1/jobs/{id}/status.

The five-model comparison script shows the polling branch in full. When a FLUX 3 row is added to the Sume catalog, its supported_parameters will settle the n and seed questions in one request; until then, the OpenRouter page is the only listing I could read, and its limits are OpenRouter's, not the model's.