Automatic model selection
for each request

Send "model": "auto", optionally with your priorities and a price ceiling. The Runware Model Router picks a model from Runware's official catalog, ranked by quality, speed, and cost.

Read the docsSee how it decides
autoas the modelEverything else stays the same
MODEL ROUTER - NOW LIVE

The router picks a model that fits

The router drops the models that can't serve your request, ranks the rest by your priorities, and runs the top one.

Request
{  "taskType": "imageInference",  "taskUUID": "ef485de7-4ba6-4aeb-aa66-ac427bc974d8",  "model": "auto",  "positivePrompt": "a ceramic coffee mug on a marble counter, morning light",  "width": 1024,  "height": 1024,  "includeCost": true,  "routing": {    "preferences": {      "quality": 2,      "speed": 4,      "cost": 5    },    "maxPrice": 0.01  }}
  1. Exact checks
  2. Requirements
  3. Rank
  • GPT Image 2
  • Nano Banana Pro
  • Seedream 5.0 Pro
  • FLUX.2 [pro]
  • FLUX.1 [schnell]
  • HiDream-I1 Fast
  • TwinFlow Z-Image-Turbo
Your weights
quality2
speed4
cost5
Response

Final picks and costs from Runware test runs, Oct 2026. Candidate tiles are illustrative, and the router isn't deterministic, so your pick may differ.

How the router picks a model

Schema checks come first, then your requirements, then a ranking. The task runs as soon as a model is chosen, so there's nothing extra to poll and no second request.

Send in your request

Send the same task and parameters, with the model set to auto in place of a model ID. Every value you set is kept, and your prompt is never rewritten.

01 · Request

Dial in your preferences and rules

preferences

Preferences rank

Weight quality, speed, and cost from 0 to 5. Weights change only the order of the models that fit. A 0 removes that dimension; leave them out and all three count equally.
maxPrice · requirements

Rules decide

maxPrice

A price ceiling for this request, in USD, checked against your actual request: per-second models over your duration, per-image models over your result count, multi-rate models at their most expensive rate. While it's set, models with no price to check against are skipped. It's best effort for realistic settings; with extreme parameters, a compute-billed model can cost more than its listed price.

requirements

Up to 3,000 characters for what no parameter can hold, like "with audio" or "an open-source model". Settings such as size or steps work there too, but they're more reliable as parameters like width and steps. Your prompt still describes the subject, and if you send none, the router writes one from your requirements.

curl https://api.runware.ai/v1 \
  -H "Authorization: Bearer $RUNWARE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '[
    {
      "taskType": "videoInference",
      "taskUUID": "<uuid-v4>",
      "model": "auto",
      "positivePrompt": "a drone shot over a harbor at sunrise",
      "duration": 5,
      "includeCost": true,
      "routing": {
        "preferences": {
          "quality": 5,
          "speed": 2,
          "cost": 1
        },
        "maxPrice": 1,
        "requirements": "with audio, 1080p or better"
      }
    }
  ]'

Where the router fits

Use it when the result and the budget matter more than which model made it.

  • Stay current without a code change

    New models join the catalog every few days. When one fits your rules and ranks higher, requests sent with "model": "auto" go to it, with no model ID to swap and no redeploy.

  • Batch jobs on a fixed budget

    Set maxPrice once, and the router checks every request in the batch against it at listed prices before anything runs. Weight cost higher to lean toward cheaper models that still meet your requirements.

  • Prompts your users write

    When your users type the prompts, you can't tell whether the next one needs readable text, a transparent background, or a photoreal face. Send their prompt as usual, put any must-haves from your UI in requirements, a "transparent background" checkbox, say, and the router picks a model that can deliver them.

  • Free and paid plans from one code path

    Give free-plan requests a low maxPrice and a high cost weight, and paid-plan requests a high quality weight. It's the same call either way; only the routing object changes.

  • Agents that don't track models

    An agent working through the Runware MCP server can send "model": "auto" with its needs in requirements, so it doesn't have to keep notes on which model handles which job.

  • Prototypes before you've picked a model

    Start building while you're still deciding. Each response names the model that ran, and with includeCost on it shows the charge too, so you can compare picks before settling on one.

Errors that name the cause

When no model can serve the request as sent, the router runs nothing rather than downgrading it, and the error says why.

noEligibleModel
The reason field names what ruled every model out, such as above 0.05 when your maxPrice is below every model's price. Loosen that setting and send the request again.
invalidParameter
The request has a parameter no model declares, or a key routing doesn't recognize. The message names it and suggests a near match when there is one, which usually points to a typo.
modelRouterNeedsDescription
You sent media without saying what to make from it, and the model the router picked needs that. Describe the result in requirements, or send the parameter the message names.
modelRouterUnsupportedTaskType
The router doesn't handle this task type. Send the same request with a model ID in place of "auto" and it runs as usual.
modelRouterUnavailableRetryable
Routing is temporarily unavailable. Retry after a short wait, or name a model directly to skip routing for now.

Need the same model every time?

The router chooses from Runware's official catalog. It isn't deterministic, so the same request can land on a different model from one call to the next. Pin a model when your product depends on one model's exact look or on prompts tuned to it. Community and private models are always called by ID.

It works across image, video, and audio generation, text and 3D, upscaling, background removal, captioning, vectorizing, prompt enhancement, and more, and through the Runware MCP server. Routing is free: you pay for the model it picks.

Read Model Router Docs
Same request, three calls
"model": "auto"Routed
  1. Call 1PixVerse V6
  2. Call 2Vidu Q3
  3. Call 3PixVerse V6
"model": "pixverse:1@8"Pinned
  1. Call 1PixVerse V6
  2. Call 2PixVerse V6
  3. Call 3PixVerse V6

Illustrative. The router isn't deterministic, so routed calls can land on different models. A pinned call runs the model you name.

FAQs

It picks a model for each request when you set "model": "auto". It chooses from Runware's official catalog, ranked by quality, speed, and cost, within the requirements and price ceiling you set. Everything else in the request stays the same.

First, each model's published schema and listed prices rule out the clear mismatches: a task it can't run, a value it can't accept, or a price above your ceiling. Then decision models and LLMs judge your plain-language requirements against the models that remain. What's left is ranked on measured signals, among them public benchmark scores, run times, and cost, weighted by your preferences, and the top model runs. Like every routing decision, this is best effort, and the router isn't deterministic.

No. Every value you set is kept as sent, and the router never rewrites your prompt. It fills in only what you leave out, and a model that can't accept one of your values is not considered.

Weight cost higher in preferences, set a ceiling with maxPrice, or both. maxPrice is measured against your actual request, and a model with several rates is checked at its most expensive one. While a ceiling is set, models with no price to check against are skipped; leave maxPrice out and weight cost to reach them. Treat the ceiling as best effort for realistic settings.

The router runs nothing and returns noEligibleModel, with a reason that names the cause, such as a price ceiling no model meets.

No. It chooses only from Runware's official model catalog. Call community models and your organization's private models by their model ID, as you do today.

When your product depends on one model's exact look, or when your prompts are tuned to a specific model. The router isn't deterministic, and its choice can also change as new models arrive, so pin a model when you need the same one every time.

No. Routing is free; you pay the price of the model it picks.

Model Router - Now live

Change one field.

Send "model": "auto" and let the router pick the model for each request.

Read the docsTalk to an engineer