AI routing can remove a model choice from every generation request, but it can also hide the reason a model was selected. Runway’s Model Router resolves an eligible model from a saved policy and returns the chosen settings. Before placing that decision inside a creative API workflow, audit cost, latency, quality, failure recovery, and realized credits with one controlled input.
Compare a deliberate multi-model video path in APOB
This is a safe test protocol with blank result tables, not a claim that dry runs or paid generations were executed for this article. The Runway pages were checked September 11, 2026. Use a disposable configuration, keep credentials out of screenshots, and remember that deleting a router configuration is permanent. APOB is included only as a manual multi-model creation context; it is not described as an automatic router.
Write the policy before choosing a model
Separate the project into draft and final lanes. Each lane gets a modality, accepted inputs, output constraints, credit ceiling, and optimization preference. Publishing the sheet first prevents a team from rewriting the policy after it likes an output.
Draft lane
The draft lane answers a creative question cheaply or quickly: does the camera move work, can the product action be read, or does the reference composition support the story? Define the minimum acceptable resolution, duration, audio need, and reference type.
Do not require final-delivery qualities by habit. A draft that meets its learning objective can proceed even if it would not ship.
Final lane
The final lane needs an approved visual contract: resolution, duration, audio, aspect ratio, reference behavior, motion, brand details, and acceptable revision cost. Add the destination and reviewer. “Best quality” is too vague for a routing policy.
If a required capability is non-negotiable, make it an eligibility condition rather than hoping the quality preference chooses a compatible model.
Credit ceiling
Set a maximum budget for one job and state whether it applies to a dry-run estimate, a single generation, or the whole revision loop. Record the unit exactly as the current docs present it.
Runway’s official pricing guide says routed work uses the selected model’s normal rate and returns realized credit cost. Recheck current rates before running; do not copy a dated number into a permanent policy.
Allowed capabilities
List the required modality and inputs, then create an explicit allowlist only if the team has approved particular models. The official Model Routers overview explains that the router first filters eligible models and then applies an optimization preference.
Keep the policy small enough to understand. A long allowlist with contradictory constraints turns automatic selection into an opaque maintenance burden.
Lane | Job | Required capability | Ceiling | Preference | Owner |
|---|---|---|---|---|---|
Draft | Answer one creative question | Cost or latency | |||
Final | Produce review-ready clip | Quality |
Ask the router without spending credits
Run three otherwise identical dry-run requests: cost, latency, and quality. Preserve the same prompt, references, output constraints, allowlist, ceiling, API version, and router configuration. A dry run is a policy inspection, not a generated result.
Cost preference
Set the optimization preference to cost and capture the resolved model, settings, eligibility information, estimated or returned cost fields documented by the interface, and timestamp. Do not change the ceiling to help the request pass.
The Runway Model Router may select a different model as availability or catalog information changes. Record the response, not an expectation.
Latency preference
Repeat the request with latency as the only policy change. Compare the resolved model and settings with the cost response. Do not measure network round-trip time and call it generation latency; the dry run has not rendered a clip.
If the response is identical, record that result without inferring that cost and latency are always equivalent.
Quality preference
Run the third request with quality as the only changed field. The label expresses a router preference under the eligible set; it does not establish an independent visual-quality score.
Preserve all three raw responses. A summary table is useful, but the response body is the evidence when someone asks why the AI model router chose a model.
Resolved settings
Normalize each response into the same ledger: policy ID, preference, eligible constraints, chosen model, resolved duration, resolution or ratio, estimated credits if returned, warnings, and timestamp. Do not publish credentials, request signatures, private asset URLs, or personal data.
Runway’s official generation guide documents the dry-run flow and response transparency. Follow the current schema rather than examples copied from an older post.
Dry run | Preference | Resolved model | Resolved settings | Credit field | Notes |
|---|---|---|---|---|---|
A | Cost | ||||
B | Latency | ||||
C | Quality |
Force the no-eligible-model branch
A routing policy is incomplete until its failure path is tested. Use a disposable configuration or request constraint that deliberately leaves no eligible model. Do not delete a production configuration merely to create evidence.
Failure trigger
Choose one reversible trigger: an unrealistically low ceiling, an allowlist that conflicts with the required input, or a capability combination not offered by the allowed models. Write the expected failure before sending the dry run.
Capture the exact error type and message allowed for retention. A failed request is useful evidence; it should not expose keys or private URLs.
Allowlist widening
First recovery option: add one approved model to the allowlist while preserving the brief and ceiling. Repeat the dry run and note whether eligibility returns. This tests governance flexibility without moving the budget.
Do not widen to “all models” unless that is an explicit policy decision. The recovery should remain reviewable.
Ceiling change
Second option: raise the ceiling by one approved step while keeping capabilities and allowlist fixed. Record the previous and new limit, owner, and reason. The step reveals whether the failure was financial rather than technical.
Never use a dry-run estimate as a guarantee. The live reconciliation later must compare returned realized credits.
Input softening
Third option: relax one nonessential input or output constraint—duration, resolution, audio, or reference type—without changing the story objective. Mark the creative compromise on the request.
The recovery order should be predetermined: widen allowlist, change ceiling, soften input, or stop. If none preserves the brief, a direct-model path or another workflow is safer than silent degradation.
Reconcile the chosen model after generation
Approve only one policy for a minimal live generation. Confirm the request contains no credentials or unapproved media in the evidence record. Save the dry-run response before sending the paid request.
Estimated route
Copy the chosen model, resolved settings, and displayed credit field from the final dry run. Add a hash or job label that binds it to the live request. If the API does not promise a reservation, label the route “estimate,” not “locked.”
This distinction matters because catalog, eligibility, or service conditions may change between calls.
Actual route
After completion, capture the returned model and resolved settings. Compare them field by field with the estimate. A difference is not automatically a defect; it is routing drift that the policy owner must understand.
Keep the output only when its media rights and safety requirements are satisfied. The audit is not permission to generate sensitive or unowned content.
Realized credits
Record the realized credit cost from the response and compare it with the dry-run field and ceiling. Do not calculate a platform-wide price from one job. Date-stamp the row and link the current Runway pricing documentation.
If the job exceeds the team’s allowed variance, pause the route rather than averaging the surprise into future budgets.
Drift note
Write one sentence: “Estimated and actual route matched,” or list the exact fields that differed. Include whether the output passed the creative contract and how many review minutes it required.
An inexpensive route that causes repeated revisions may fail the workflow even while respecting the per-generation ceiling. Cost quality routing needs both API and human-work evidence.
Adopt a routing charter—or stay explicit
The decision is not “automation good” or “manual choice good.” Choose the smallest policy that remains predictable and maintainable for the team.
Router condition
Adopt the router when multiple eligible models can satisfy the brief, the chosen preference represents a real business priority, dry-run transparency is sufficient, failure recovery is bounded, and realized credits stay within policy. Assign a configuration owner and retest date.
Do not let an abandoned configuration become invisible infrastructure. Record who may change allowlists, ceilings, and capabilities.
Direct-model condition
Choose a direct model when a client has approved a specific model, reproducibility matters more than optimization, the router frequently changes settings, or the eligible set collapses to one option. Explicit choice can be the more honest automation policy.
Use the same request and cost ledger so the two paths remain comparable.
Two-lane condition
Use a low-cost or low-latency router for drafts and a direct approved model for finals. For creators who prefer a visual interface, the APOB AI Video Generator provides a documented multi-model workflow, and the APOB AI Video Editor supports the later creative handoff. APOB is not an equivalent automatic router.
The advantage of the two-lane plan is visible intent: exploration is flexible; delivery is controlled.
Retest cadence
Recheck the charter when Runway changes routing docs, supported models, price rules, preferences, response fields, or configuration behavior; when APOB’s model surface changes; or when the team’s budget or delivery standard moves. The Runway API changelog is the date-stamped source for router availability.
Keep the policy sheet, three dry runs, forced failure, recovery sequence, one live reconciliation, and decision together. That packet makes AI routing auditable. If the evidence cannot explain a chosen model and its cost, stay explicit until it can.
Sources
Be the first to like this.
No credit card needed
