Runway Model Router dryRun: preview the pick, and what Sume Auto shows

Runway's Model Router lets you create a routing configuration, pick an optimization goal of cost, latency or quality, set credit ceilings per modality, and run a dryRun preview before you generate. Sume's sume/auto is a different bargain: you send one model id, Sume picks the family, and the response echoes sume/auto without ever disclosing which family ran.

Runway's entry is dated July 23 on its API changelog; Sume's behavior is in the video generation docs. Both were read on 2026-10-03.

What can you configure on Runway's router?

The changelog lists these pieces: a routing configuration that you reference with a configId, routing across video, image and audio generations, an optimization of cost, latency or quality, a credit ceiling for each of the video, image and audio modalities, and a dryRun preview. The documentation for it lives under Runway's /model-routers section.

The earlier posts on allow and deny lists and the model billed in the response cover those two parts. This post is about the preview step, which they do not.

Why does a dry run matter?

A router that picks a model for you can pick an expensive one. A preview that returns the choice before any credits move turns the router from a gamble into something you can test in CI: submit a set of representative prompts as dry runs, check that none selects a model above your ceiling, and only then enable real generation.

The changelog does not spell out the preview's response fields, so this post does not describe them. Read Runway's router page before wiring assertions to a particular field.

What is the Sume equivalent?

There are two, and neither is a preview of the router's choice.

First, sume/auto is Sume-only: the docs say responses echo sume/auto and that the family that ran is never disclosed. So there is nothing to assert about which model was selected. Second, if you need a known model and a known cost, pin a catalog id from GET /v1/videos/models instead. Sume reserves provider list price times 1.25 on submit, and usage.cost on the finished job is the billable amount.

How should you choose between them?

Use a router when you want the vendor to arbitrate and you are happy to review its choices. Pin a model when a clip has to match a brand test or a comparison you published. For a fair comparison between Runway's router and Sume Auto, run the same ten prompts through both and judge the clips, since neither tells you the other's reasoning. For Sume, record the job id and the cost per clip, because those two facts are the audit trail you will actually have.

What would a CI check around a preview look like?

Keep a short file of prompts that stand for your real traffic: a product shot, a talking head, a vertical ad, an image edit. Run each as a dry run against your configuration after any change to its ceilings or goal, and fail the build if a prompt routes somewhere you did not expect or the preview reports a cost above your budget.

On Sume the equivalent habit is to pin a model in the request and read usage.cost from a handful of real jobs after each model change. It is slower and it spends money, but it is the evidence Sume's docs make available.