OpenRouter models fallback array and 3-entry limit vs Sume

OpenRouter's models array tries the next model on downtime, rate limits or moderation; fallbacks allows 3. Sume's allow_fallbacks has no effect.

4 min readSume
All posts

OpenRouter's models parameter takes a priority-ordered array of model ids and moves to the next one when the first model's providers are down, rate-limited, or refuse because of content moderation. Its fallbacks field, on the Anthropic Messages endpoint, accepts at most 3 entries. Sume has no such list: provider.allow_fallbacks on its image route is accepted but has no effect, because each model has one sume endpoint, and sume/auto lets Sume pick a family without telling you which one ran.

OpenRouter's behaviour is from its Model Fallbacks page, read on 2026-10-02; it describes chat requests. Sume's is from Image generation and Video generation.

How does OpenRouter's fallback work?

You send an array of model ids in priority order. If the first returns an error, OpenRouter tries the next. By default any error can trigger a fallback, including context length validation errors, moderation flags for filtered models, rate-limiting and downtime. If the fallback is also down, you get that error.

Requests are priced using the model that was ultimately used, which the response returns in its model attribute. On the Anthropic Messages endpoint, fallbacks takes entries with only a model field, cannot be combined with models (both returns a 400), and accepts at most 3 entries, with longer lists returning a 400.

What does Sume do on the same question?

The image route's provider object takes only, order, ignore, sort and allow_fallbacks. Sume publishes a single sume endpoint per model in v1, so only and order accept only "sume", and ignore, sort and allow_fallbacks are accepted and have no effect. Any other slug returns 400 provider_not_available.

model: "sume/auto" is Sume's own choice: it picks the family for you and never discloses which one ran. It is not listed in GET /v1/images/models, and job.model stays sume/auto. A failed image generation is not billed. For a model-level fallback with a model id you choose, the client has to do it: catch the failure and submit the next id.

How do the two compare?

One routes across models for you on error; the other leaves ordering to you.

OpenRouter's Model Fallbacks page and Sume's Image generation and Video generation docs, read 2026-10-02.
ItemOpenRouterSume
Ordered model listmodels array, priority orderNone; one model per request
TriggersDowntime, rate limits, moderation, context lengthNot applicable
Fallback capfallbacks: at most 3 entries (Messages endpoint)Not applicable
Provider fallback flagallow_fallbacks, default trueAccepted, no effect (one sume endpoint)
Which model ranReturned in model, billed on thatsume/auto: not disclosed; job.model stays sume/auto

What should I do if I need a fallback on Sume?

Pick the ids from the catalog (GET /v1/images/models or GET /v1/videos/models), submit the first with an Idempotency-Key, and if the job fails, submit the next id with a new key. Log the exact model id for each attempt, since a fallback changes the output.

Or use sume/auto when you do not care which family renders, accepting that you cannot see which one did.

Sources

Related posts

More in Comparisons

All Comparisons posts

Written by Sume