Runway Media Router Routes Image, Video, and Audio Generation Models Through a Single Endpoint

Runway has launched Media Router on its Runway Dev platform, replacing the workflow in which applications specify a model for each generation request with one where developers set constraints, call a single endpoint, and let the platform select the model. The initial release supports video, image, and audio generation, routing requests among Runway’s Gen-4.5, Aleph 2.0, and Act-Two, as well as third-party models including Seedance, GPT Image 2, and ElevenLabs.

Developers first create reusable routing configurations that specify a per-generation price cap, model or provider allow/deny lists, and preferences across cost, quality, and latency. Requests only need to include the configuration ID, rather than hard-coding a model name. The router first filters out ineligible models based on modality, required capabilities, and hard constraints, then scores the remaining candidates. Along with the generated output, the response identifies the model actually used and explains why it was selected. If the constraints exclude every candidate, the API returns an explicit error instead of silently relaxing price or provider rules.

Notably, Media Router offers a dry-run mode that neither performs generation nor incurs generation costs, allowing teams to inspect where a given request would be routed before deployment. This is particularly important for enterprise workflows subject to data residency, provider approval, or budget constraints. It can also reduce the cost of updating applications as the model catalog changes frequently. Teams can use separate configurations for previews and final outputs: the former can prioritize low latency, while the latter assigns greater weight to quality.

Media routing is harder to validate than text-model routing because “quality” varies with the prompt, visual style, character consistency, temporal stability, and audiovisual synchronization. Runway has not explained whether its evaluator is based on rules, a human-preference model, or an online feedback system. Nor has it published data comparing routing with fixed model selection in terms of success rate, cost savings, or tail latency. Engineering teams therefore should not treat the model-selection rationale as a quality guarantee. Before going live, they should still retain the underlying model ID, inputs, and outputs; establish their own offline evaluations and fallback strategies; and verify whether updates to third-party models could affect the reproducibility of existing workflows.