Is FLUX.2 deprecated after FLUX 3? Keep production ids pinned on Sume

No. Black Forest Labs' documentation home, read on 2026-10-03, presents FLUX 3 as its newest model family and says FLUX.2 remains fully supported for production image generation and editing, with open weights on Hugging Face. The page shows no retirement date for FLUX.2, so there is nothing to migrate by a deadline.

For a Sume caller the safe move is to keep the model id you have tested, and to read the catalog before you test anything new. Sume's facts here come from its Image API docs and Jobs and results.

What does BFL's page actually say?

It calls FLUX 3 its latest model family, one model and one API, and lists four modalities: video (from a prompt, animating stills or pinning keyframes, with synchronized audio), image (generate and edit, combine references, and place elements with boxes), audio, and action with open weights for predicting robot or game actions. Separately it says FLUX.2 is fully supported for production image generation and editing.

The page has no changelog link and no dated entries, so it cannot tell you when FLUX 3 image arrived or whether FLUX.2 will later be retired. We do not guess either.

What should a Sume caller do today?

Treat the Sume catalog as the source of truth for what you can call. GET /v1/images/models returns each model's id, input and output modalities and supported_parameters. A FLUX.2 id appears in the Sume docs in the form black-forest-labs/flux.2-pro, and a request that sets a parameter the row does not list is rejected with 400 unsupported_parameter. The snippet lists the Black Forest Labs rows currently in the catalog:

curl -s https://api.sume.com/v1/images/models \
  -H "Authorization: Bearer $SUME_API_KEY" \
  | jq -r '.data[] | select(.id | startswith("black-forest-labs/")) | .id'

How do you decide whether to move at all?

The BFL page names box placement as an image capability of FLUX 3. Whether a Sume row exposes a matching field is something only the catalog row can tell you, so do not assume the vendor's field names carry over.

What about cost and speed?

Each catalog row's endpoint record carries pricing lines; cost_usd is the amount charged to your wallet with Sume's margin applied, so cost_usd times n is the call cost. Fetch it from GET /v1/images/models/{model_id}/endpoints rather than copying a number from a blog post. A request that runs past the 30-second blocking budget comes back as 202 with a job envelope, and failed or cancelled generations are not billed.

Keep a small golden set of prompts and references. Run it against your pinned FLUX.2 id and any newer row you consider, with the same size and quality settings, and compare.

Where does open weight FLUX.2 fit?

BFL's page notes the FLUX.2 weights are on Hugging Face. That matters if you self-host, but it is separate from calling a hosted model through Sume. Self-hosting is governed by the licence on the weights, which we did not read in this check, so read it yourself before using open weights commercially. Through Sume you call a catalog id and pay the per-image price on the endpoint record.

If you are unsure which route fits you, write down the one thing you need from the newer family. If it is a documented feature with a matching field in the Sume catalog row, test it. If it is only a headline, wait until the row lists it. That keeps a working production prompt from changing under you for a reason you cannot measure.