Configuring a Model Router
A Model Router configuration is a named, reusable set of routing preferences for a specific use case. You create it once in the Developer Portal and reference it by its config ID in your generation requests, so you don’t repeat routing preferences on every call.
Create a configuration
Section titled “Create a configuration”From the Developer Portal, open Model Routers and choose New config. A configuration has the following settings:
Config ID, name, and description
Section titled “Config ID, name, and description”Set a config ID — a short, immutable identifier (a URL-friendly slug like preview-fast) that you pass in your generation requests to apply this config. It’s set once at creation and can’t be changed afterward.
You also give the configuration a human-friendly name (required) so you can identify it later — for example, Preview or Final Export — and, optionally, a description.
Eligible models
Section titled “Eligible models”By default, every video, image, and audio model is available to the router, and newly released models become eligible automatically. If you’d rather constrain the pool, a config supports two modes:
- Allow list — only the models you list are eligible, and new models are never added automatically. Use this when you need a fixed, closed set.
- Deny list — every model is eligible except the ones you list. New models are included automatically as they launch. Use this to exclude specific models while keeping automatic access to new ones.
Models are identified by their model name (for example, gen4_turbo, gpt_image_2, or seed_audio). The allow or deny list can mix modalities; when you generate, the router only considers models that match the endpoint you called — see Generating through a Model Router.
Optimization preference
Section titled “Optimization preference”Choose the single dimension you want the router to optimize for among eligible models:
- Cost — prefer the least expensive eligible model.
- Latency — prefer the fastest eligible model.
- Quality — prefer the highest-quality eligible model.
The router applies this preference only after filtering to models that can satisfy the request, so it always chooses among models that already meet your other constraints.
Maximum credits per generation
Section titled “Maximum credits per generation”Optionally set a cap on how many credits a single generation may cost. Caps are per modality — video, image, and audio each have their own ceiling — so a single config can set a different budget for each generation type.
Any model whose estimated cost for a given request would exceed that modality’s ceiling is excluded before the optimization preference is applied. If a request can’t be satisfied by any model at or under the ceiling, it’s rejected with an explicit error — see no eligible model.
Leave a modality unset to apply no price constraint for that modality. Credits are the same unit used everywhere else in the API; see Pricing for per-model rates.
Save and reference a configuration
Section titled “Save and reference a configuration”Once saved, a configuration is applied by passing its config ID in your generation requests. You can create a configuration with all defaults and edit it later. To route requests using a config, see Generating through a Model Router.
Manage configurations
Section titled “Manage configurations”Manage configs from the Model Routers section of the Developer Portal:
- Edit — Update the name, description, or settings. Editing settings appends a new version; changes apply to requests made after the edit, never retroactively. The config ID is fixed and can’t be changed.
- Delete — Remove a configuration. A deleted config can no longer be used for generation, so any request referencing its config ID will fail.
If you’d rather manage configs programmatically, the same create, update, and delete actions are available through the Model Router API and the Runway SDKs.