Choosing the right model for your use case

Selecting models for generative media tasks remains a challenge for builders. With dozens of options available from numerous vendors and growing, keeping up with the field can be a full-time job, and is for some. Models are not interchangeable; for example, image and video generation models vary in several ways:

• Capability tradeoff: large frontier models offer the best overall quality, but are slower and more expensive, while small models are cheaper and faster but may struggle with prompt adherence and visual details.
• Use case specialization: some models may be better at art and illustration; some may be better at advertising or photorealism; still others may be better for diagrams or other text-heavy imagery.
• Inputs: models may or may not accept keyframes, reference images, or sound as inputs, and the influence of those inputs may not be consistent between models.
• Outputs: models may or may not add sound or vocals to videos, produce scene cuts, or offer the same duration, resolution, or aspect ratio options.
• Prompting characteristics: models behave very differently against the same prompts.
• Availability: models may have region locks, concurrency limits, and capacity issues.

Furthermore, the landscape is ever changing. A builder may take weeks to implement a workflow that meets their needs, just in time for the next model release to force them to re-adapt.

Decoupling model selection from preferences

Runway’s Model Routers solve this problem in the following way: instead of manually selecting a model and designing their application around its quirks, a builder defines the model requirements in terms of high-level preferences and the router automatically chooses the best model for the job.

Preferences may include an objective to optimize for like cost, quality, or latency; a maximum cost per generation; or a list of acceptable models.

At runtime, the router first filters all available models to those that meet the criteria, and then chooses the one that best satisfies the target objective. When the target is quality, the router analyzes your prompt to select the best model for the use case, based on internal benchmarks compiled by the expertise of professional creatives and artists.

Using a model router in place of a specific model is advantageous to builders because it outsources model selection to an expert, ensures they get the best model for the task, and lets them structure their applications against durable preferences that do not change with every new model generation.

Routing can drop into almost any workflow, but is particularly valuable in a few common situations:

• Products must keep up with catalog: builders can configure their router to automatically make new models eligible the day they are released.
• Preview versus final render: a draft routed for cost or latency and a final render routed for quality, from the same code path.
• Requests vary in shape: user-driven inputs where duration, resolution, references and aspect ratio are variable, and no single model works for every call. Routers eliminate the need for complex logic to handle the variability.
• Teams without in-house model evaluation: most builders are occupied enough making their applications work for their users and may not already know which models are best for their use case.

How to create and use a Model Router

1. Create the router

Go to the Model Routers section in the Runway dev platform and click New router. Give it a name; the console derives a Config ID from it, which is the value requests will reference.

2. Specify the preferences

The configuration page has three parts.

• Cost caps: an optional maximum credit cost per generation, set separately for video, image and audio. Models whose estimated cost for a request would exceed the ceiling are excluded from that request.
• Optimization target: cost, quality, or latency. Exactly one.
• Providers and models: the routable catalog, grouped by provider, with a checkbox per model. All models are eligible by default; if you wish to exclude any, uncheck them.

Two switches at the bottom of the page decide how the model list is interpreted. With Include newly released models on, the unchecked models are a deny list and any model Runway adds later is eligible automatically. With it off, only the checked models are ever used. Fall back when a model is at capacity lets the router pick the next-best eligible model instead of queueing when the chosen model is at its concurrency limit.

Save. Changes apply to future requests only. The same configuration can be created and updated through the API, which is what a deployment pipeline would do:

POST /v1/routers

{
  "slug": "preview-clips",
  "name": "Preview clips",
  "settings": {
    "optimizeFor": "cost",
    "models": { "mode": "allow_new_except", "ids": ["veo3"] },
    "maxCreditsPerGeneration": { "video": 60 }
  }
}

allow_new_except corresponds to the first switch being on (the ids are excluded); allowlist_only to it being off (the ids are the only models allowed).

Creating a router from a coding agent

The same thing can be done without opening the console, through the Runway Dev MCP. Connect it once to Claude Code, Cursor or Codex (it authenticates with OAuth in the browser):

claude mcp add --transport http --scope user runway-dev-mcp https://dev.runwayml.com/mcp
claude mcp login runway-dev-mcp

Then describe the router in plain language:

Create a Model Router called preview-clips in my Runway project. Optimize for cost, cap video at 60 credits per generation, and exclude Veo 3.

The agent lists the available models, creates the router, applies the settings, and reads the result back:

list_projects          → { "id": "…", "name": "Gene" }

create_model_router    → { "slug": "preview-clips", "version": 1, "settings": { "optimizeFor": "cost", … } }

update_model_router    → { "version": 2, "settings": {
                            "optimizeFor": "cost",
                            "models": { "mode": "allow_new_except", "ids": ["veo3"] },
                            "maxCreditsPerGeneration": { "video": 60 } } }

The router appears in the console immediately, and the rest of this tutorial applies unchanged. After a generation, the agent can explain a routing decision with get_task_routing, which returns the same record shown in step 5.

3. Call the router instead of a model

Routed generation uses one endpoint per modality, /v1/generate/video, /v1/generate/image and /v1/generate/audio, with configId in place of a model name. The input is model-agnostic: aspectRatio: "16:9", resolution: "720p", duration: 5, rather than a specific model’s ratio strings. The Get code button in the console shows the request for each modality in the SDKs, cURL, Node and Python; for example, in the Node SDK:

import RunwayML from '@runwayml/sdk';

const client = new RunwayML();

const task = await client.generate.video
  .create({
    configId: 'preview-clips',
    input: {
      promptText:
        'Slow push-in on a ceramic pour-over coffee dripper on a walnut counter, steam rising, warm morning light',
      duration: 5,
    },
  })
  .waitForTaskOutput();

4. Dry run

Adding dryRun: true to the request runs the routing pipeline and returns the decision and its estimated cost without creating a task or charging credits. The console’s Dry-run test button does the same from a form.

POST /v1/generate/video

{ "configId": "preview-clips", "dryRun": true,
  "input": { "promptText": "Slow push-in on a ceramic pour-over coffee dripper …", "duration": 5 } }

{
  "dryRun": true,
  "routing": {
    "model": "gemini_omni_flash",
    "provider": "google",
    "configId": "preview-clips",
    "resolvedSettings": { "optimizeFor": "cost", "priceCeiling": 60 },
    "resolvedInput": {
      "duration": 5,
      "ratio": "1280:720",
      "resolution": "720p"
    },
    "estimatedCost": { "credits": 50 }
  }
}

When no model satisfies the rules, the request is refused with the stage that emptied the candidate pool. Here the same request at 10 seconds exceeds the 60-credit ceiling on every eligible model:

HTTP 400

{ "error": "No eligible model: all models exceed the configured price ceiling.",
  "code": "no_eligible_model",
  "pipeline": [
    { "type": "filter", "filter": "allow_deny",    "models": [ …13 ] },
    { "type": "filter", "filter": "capability",    "models": [ …13 ] },
    { "type": "filter", "filter": "input_support", "models": [ …11 ] },
    { "type": "filter", "filter": "prompt_length", "models": [ …11 ] },
    { "type": "filter", "filter": "price",         "models": [ ] } ],
  "emptiedBy": ["price"] }

The response lists the surviving models after each filter.

The fix depends on the stage named in emptiedBy: raise the ceiling or shorten the request for price, drop a constraint for input_support, widen the model list for allow_deny. With the ceiling raised to 120, the 10-second request routes to gemini_omni_flash at 100 credits.

5. Deploy

Without dryRun, the same request returns a task id alongside the routing decision. Poll the task as with any other generation; the final cost is reported on the task.

{ "id": "49a89781-277a-4724-9584-7dff5fe57d64",
  "routing": { "model": "gemini_omni_flash", "estimatedCost": { "credits": 50 }, … } }

GET /v1/tasks/49a89781-277a-4724-9584-7dff5fe57d64

{ "status": "SUCCEEDED", "output": [ "https://…/…mp4" ], "cost": { "credits": 50 } }

Every routed request is recorded with its pipeline and a reason code, in the router’s Activity tab and through the API:

GET /v1/routers/{id}/requests?limit=20

{ "data": [ {
    "status": "routed", "model": "gemini_omni_flash", "provider": "google",
    "reasonCode": "lowest_cost", "reason": "Lowest cost among eligible models",
    "estimatedCredits": 50, "taskId": "49a89781-…",
    "pipeline": [ …, { "type": "rank", "outcome": "cost" } ], "emptiedBy": [] } ] }

Changing the router’s preference changes the decision without changing the request. With the target set to quality and the ceiling at 120, the 5-second request routes to gemini_omni_flash_1.1 at 50 credits; Seedance 2.5, which ranks higher, is excluded at 150.

When not to use a Model Router

Some cases where it’s better to call a model directly:

• When you need reproducibility or consistency: routing can change its pick between calls as the catalog updates.
• When you need model-specific formats and controls: ProRes, HDR, and the like live on the model endpoints. The router’s input is generic.
• When you already know: if your evaluation says one model wins for your look, you do not need a router.

Create a router in a couple of minutes and point your next request at it instead of a model name. Create an account to start building.

FAQ

How do I choose the right video model?

The choice turns on what you feed in and what you need out: whether the model accepts keyframes or reference images, whether it adds sound, which durations, resolutions and aspect ratios it offers, and how it behaves against your prompts. Cost and latency then trade against quality, since large frontier models give the best overall quality while smaller models are cheaper and faster. Rather than settling it once and hardcoding the answer, you can express those requirements as preferences on a Model Router and let it pick per request.

How do I choose the right image model?

Image models specialize, so the answer depends on the work: some are stronger on art and illustration, others on photorealism or advertising, others on diagrams and text-heavy imagery. Whether a model accepts reference images, and how much influence those carry, differs too. A Model Router set to optimize for quality analyzes your prompt and selects against internal benchmarks compiled from the expertise of professional creatives and artists.

How do I choose the right audio model?

As with video and image, the choice turns on inputs, outputs and cost per generation rather than a single ranking: what the model accepts, what it returns, and what it costs. Audio has its own routed endpoint, so a Model Router set for cost, quality or latency applies to audio exactly as it does to the other modalities.

What is a Model Router on Runway Dev?

A Model Router is a saved configuration that picks a model per request against preferences you set, instead of your code naming a model. You define an optimization target, which models are eligible and an optional cost ceiling, then pass a configId in place of a model name.

How do I create a Model Router?

Go to the Model Routers section in Runway Dev and click New router, then set the optimization target, the eligible models and any cost caps. The console derives a Config ID from the name you give it, and that is the value your requests reference.

Can I create a Model Router through the API?

Yes. POST /v1/routers with a slug, a name and a settings object containing optimizeFor, a models mode and ids, and optional maxCreditsPerGeneration per modality. This is how a deployment pipeline would manage router configuration.

Can a coding agent create a Model Router for me?

Yes, through the Runway Dev MCP. Connect it once to Claude Code, Cursor or Codex, then describe the router in plain language. The agent lists the available models, creates the router, applies the settings and reads the configuration back.

What can a Model Router optimize for?

Cost, quality or latency. Exactly one target per router. When the target is quality, the router analyzes your prompt to pick the best model for the use case, based on internal benchmarks compiled from the expertise of professional creatives and artists.

How do I cap what a single generation costs?

Set a maximum credit cost per generation, separately for video, image and audio. Models whose estimated cost for a request would exceed that ceiling are excluded from the request.

Which endpoints do I call to generate through a router?

One per modality: POST /v1/generate/video, POST /v1/generate/image and POST /v1/generate/audio, with configId in place of a model name. The input is model-agnostic, so you pass values like aspectRatio, resolution and duration rather than a specific model’s ratio strings.

Can I use the same Model Router for video, image and audio?

Yes. One router configuration covers all three modalities. Cost ceilings are set separately per modality with maxCreditsPerGeneration, and you generate by calling the endpoint for the modality you want, POST /v1/generate/video, POST /v1/generate/image or POST /v1/generate/audio, passing the same configId each time.

Does a Model Router cost extra?

No. You are billed for the model the router selects, at that model’s standard rate.

How do I know which model the router picked, and what it cost?

Every routed response reports the routing decision, and the final cost is reported on the task. Every routed request is also recorded with its pipeline and a reason code, in the router’s Activity tab and through GET /v1/routers/{id}/requests.

How do I test a routing decision without spending credits?

Add dryRun: true to the request. It runs the routing pipeline and returns the decision and its estimated cost without creating a task or charging credits. The console’s Dry-run test button does the same from a form.

What happens when no model satisfies my routing rules?

The request is refused with HTTP 400 and no_eligible_model, and the response names the stage that emptied the candidate pool in emptiedBy. The fix depends on the stage: raise the ceiling or shorten the request for price, drop a constraint for input support, widen the model list for allow and deny.

Will new models be used automatically?

Only if you want them to be. With Include newly released models on, unchecked models act as a deny list and any model Runway adds later becomes eligible automatically. With it off, only the models you checked are ever used.

What happens if the selected model is at capacity?

With Fall back when a model is at capacity on, the router picks the next-best eligible model instead of queueing at the chosen model’s concurrency limit.

Do changes to a router affect requests already in flight?

No. Changes apply to future requests only.

When should I not use a Model Router?

When you need reproducibility, because routing can change its pick between calls as the catalog updates. When you need model-specific formats and controls such as ProRes or HDR, which live on the model endpoints while the router’s input is generic. And when your own evaluation has already settled on one model for your look.

Can I restrict a router to a specific list of models?

Yes. Use allowlist_only so that only the ids you list are ever used, or allow_new_except to treat the listed ids as exclusions and let anything Runway adds later become eligible.