Model Routers
Instead of building your integration around a single model, create a Model Router and let the platform select the best model for you based on your configured preferences. You define what “best” means for your use case — optimize for cost, latency, or quality — and the router picks the right model for every request.
As new models launch, your routing keeps pace with those preferences automatically, so you benefit from the latest models without ever touching your integration.
What it is
Section titled “What it is”A Model Router is a named, reusable configuration you create in the Developer Portal to capture your routing preferences for your integration. Each router gets a stable config ID that you pass in your requests, so your integration points at your preference rather than at a specific model.
You can create as many routers as you need — one for each use case. A creative app might run a Draft router tuned for latency and a separate Final Export router tuned for quality, each called by its own ID and optimized for what that surface actually needs.
The same config can serve video, image, and audio: modality is implied by which generate endpoint you call (/v1/generate/video, /v1/generate/image, or /v1/generate/audio).
How it works
Section titled “How it works”A Model Router resolves each request in two steps. First it narrows the catalog to the models that could satisfy the request — those that you’ve enabled, support the capabilities required by your request, and would stay under any price cap you’ve set for that modality. Then it picks the best of the remaining models according to your preference for cost, latency, or quality.
The JSON response includes which model ran and what it cost. If no model satisfies your request based on the configuration, the request will fail with a no eligible model error.
When to use one
Section titled “When to use one”Use a Model Router when you want the platform to select and maintain the model choice for you based on your priorities. Use a base model directly when a use case should always run on one specific model.
Cost predictability
Set a maximum spend per generation so a single request can never exceed the budget you’ve defined for that use case.
Less integration maintenance
Configure a router once and call it by ID. You don’t need to update your integration every time a model launches or pricing shifts.
Transparent decisions
Every response reports which model ran and what it cost, so you can verify the router is behaving the way you configured it.
Automatic access to new models
Newly released models become eligible automatically (if you choose), so your routing keeps improving without changes to your code.