provider.sort and allow_fallbacks on Sume images: accepted, no effect

If your image code sends a provider object to Sume, three of its fields are harmless: ignore, sort and allow_fallbacks are accepted and have no effect. only and order accept just the value "sume"; anything else returns 400 provider_not_available. Sume publishes one endpoint per image model, so there is nothing to sort between or fall back to. That makes it safe to leave existing routing preferences in a ported request.

Which provider fields does POST /v1/images accept?

The request schema takes the full provider shape: only, order, ignore, sort, allow_fallbacks and options. Behavior is fixed in v1, as listed below.

The distinction matters for error handling. A 400 provider_not_available means the request named a backend Sume does not expose, and retrying it unchanged will never succeed. A request that only adds sort or allow_fallbacks will succeed exactly as it would without them.

Why is there nothing to route?

Each catalog model has a single Sume endpoint, shown in GET /v1/images/models/{id}/endpoints with provider_slug sume. The public docs describe provider_slug and provider_tag as the values for provider-specific parameters and pinning, and with one endpoint the pin is trivially satisfied.

The per-model endpoints response also carries pricing lines and an empty allowed_passthrough_parameters list, which is why options must stay empty. If your client builds provider.options from a config file, strip it before the call.

What should a ported request do?

Keep provider out of the body unless you need it. If a shared client always sends one, make sure only and order are either absent or ["sume"], and options is empty. Do not rely on allow_fallbacks to retry on another backend: it does nothing here. For resilience, retry the job or choose a second model from the catalog yourself.

Also remember that parameters outside a model's supported_parameters fail with 400 unsupported_parameter, so validate those separately.

A quick test: send the same prompt twice, once with your full provider object and once without it, and compare the responses. If the only difference is a 400 on only or order, fix those two fields and leave the rest. Sume does not name the upstream vendor in any response, so nothing in the body will reveal which backend served the request.