FLUX 3 Image 768sq and 1.5k tiers vs Sume's 512, 1K, 2K, 4K

FLUX 3 Image's tiers are 768sq, 1k (the default), 1.5k, 2k, and 4k, and Sume's published tiers are 512, 1K, 2K, and 4K, on Nano Banana 2 and Pro only. Two of FLUX 3 Image's names have no Sume twin: 768sq and 1.5k. When you translate, round up to the next Sume tier, and drop the field entirely for models, such as FLUX.2, that publish no tier.

The vendor pages do not define the pixel size of any tier, so this post maps names, not pixels. Measure the files you get back.

What do the FLUX 3 Image tier names mean?

Replicate lists resolution as 768sq, 1k, 1.5k, 2k, or 4k with 1k as the default; OpenRouter lists "768", "1K", "1.5K", "2K", and "4K" (both read 2026-10-03). Neither page gives pixel dimensions per tier. The sq in 768sq suggests a square frame, but I did not find that stated. Tech Times reports a native maximum near 5,456 by 3,072 pixels, which is about 16.8 megapixels and is reported, not a tier definition.

The point for a port is that tier names are the vendor's labels. Treat each as a bucket of total pixels, and expect a 4k request at 16:9 and one at 1:1 to differ in shape.

Which tiers does Sume publish, and where?

Sume's catalog gives a resolution descriptor to three families of row: Nano Banana 2 and Pro (512, 1K, 2K, 4K; default 1K), Imagen 4 Ultra (1K, 2K; default 2K), and Higgsfield Soul (720p, 1080p). FLUX.2 Pro and Flex have none. The docs also say a model accepts only values its descriptor lists, so a tier such as 1.5K that is not listed is rejected, not rounded.

A translator that checks the catalog

This function turns a FLUX 3 tier name into a value Sume will accept, or None when the model publishes no tier. It reads the live descriptor, so it keeps working when rows change. It prefers the next tier up and falls back to the largest one available.

import os
import requests

ORDER = ["512", "1K", "2K", "4K"]
WANT = {"768sq": "1K", "1k": "1K", "1.5k": "2K", "2k": "2K", "4k": "4K"}

def sume_tier(model_id, flux_tier):
    r = requests.get(
        "https://api.sume.com/v1/images/models",
        headers={"Authorization": f"Bearer {os.environ['SUME_API_KEY']}"},
        timeout=30,
    )
    r.raise_for_status()
    for m in r.json()["data"]:
        if m["id"] == model_id:
            vals = m["supported_parameters"].get("resolution", {}).get("values")
            if not vals:
                return None
            want = ORDER.index(WANT[flux_tier])
            ok = [v for v in ORDER if v in vals]
            return next((v for v in ok if ORDER.index(v) >= want), ok[-1])
    raise KeyError(model_id)

print(sume_tier("google/nano-banana-pro", "1.5k"))
print(sume_tier("black-forest-labs/flux.2-pro", "4k"))

Does the default tier matter?

Yes, because omitting resolution is a choice. Replicate defaults FLUX 3 Image to 1k. In Sume's code, Nano Banana's default is 1K and Imagen 4 Ultra's is 2K, so a request that leaves the field out gets a different size depending on the model. A script that compares two models without setting the tier is comparing their defaults, not their quality.

Set the tier explicitly on both sides of any comparison, record it next to the output, and check the descriptor with the translator above before the run. That also protects you from a catalog change: if a model drops or adds a tier, the function raises or adapts instead of sending a value the API rejects.

There is one more reason to be explicit. Sume's docs say 4K and other slow settings are the likeliest to come back as a 202 job after the 30-second wait, so a loop that assumes an immediate 200 will break on the largest tier first. Handle both outcomes, and poll GET /v1/jobs/{id}/status when the job envelope appears.

What does rounding up cost?

More. Sume prices per image from the endpoint's pricing line, and Sume's catalog notes say the Nano Banana 4K list price is above the 1K default. Rounding 768sq or 1.5k up to the next tier therefore costs at least as much as the lower tier would have, and probably more at 4K. If budget matters more than size, choose the largest tier at or below the one you want instead.

Because Sume does not publish a size in pixels for each tier in the docs I read, quote tiers, not pixel counts, in your own specs, and re-measure after a tier change. For price per tier on the FLUX 3 side, the FLUX 3 price note lists what was reported.

When no tier exists

For FLUX.2, the translator returns None, and the right move is to leave resolution out: sending it returns 400 unsupported_parameter. Pick the shape with aspect_ratio, accept the model's native size, and upscale afterwards if needed. The draft at 1K, finish at 2K post shows the same descriptor-reading habit for a two-pass workflow, and the Ideogram tiers note compares another vendor's labels with Sume's.