Runway Dev — Model Routers

Compagnon : Utilisez +runway-dev pour la configuration partagée quand disponible. Sinon connectez Dev MCP, sélectionnez un projet avec list_projects, lisez llms.txt, et conservez RUNWAYML_API_SECRET côté serveur.

Objectif

Maintenir un Model Router et son intégration applicative corrects. Vérifiez les modifications avec un appel SDK routé (client.generate.{video|image|audio}.create({ configId, input })) quand sûr.

Outils MCP

• list_model_routers / get_model_router — trouvez un routeur par configId, puis inspectez-le avec l'UUID d'enregistrement retourné.
• list_models — inspectez les modèles et capacités éligibles.
• create_model_router / update_model_router / delete_model_router — gérez les routeurs après approbation de l'utilisateur ; les mises à jour remplacent la configuration complète.
• get_credit_balance — vérifiez le budget avant de proposer des plafonds de crédits ou de tester.
• get_task_routing — expliquez quel modèle a géré une tâche routée existante.

Nouveau routeur

1. list_models sur les endpoints pertinents — ne devinez pas les modèles ou capacités éligibles.
2. get_credit_balance — comprenez le budget avant de proposer des plafonds de crédits.
3. Proposez : nom, slug configId immuable, description, préférence de routage, politique de liste de modèles, fallback de capacité, plafonds de crédits optionnels. Attendez l'approbation de l'utilisateur sauf s'il a fourni tous les champs.
4. create_model_router, puis update_model_router pour les paramètres si nécessaire.
5. Validez le payload prévu avec HTTP dryRun: true avant une génération facturable ; le SDK ne supporte actuellement pas les dry runs.
6. Quand la vérification facturable est appropriée, effectuez un appel SDK routé avec le helper d'attente chaîné directement depuis create(), puis utilisez get_task_routing pour expliquer quel modèle a exécuté.

Routeur existant

1. Utilisez list_model_routers pour résoudre le slug configId de l'application vers un enregistrement routeur, puis appelez get_model_router avec son UUID.
2. Clarifiez l'objectif d'intégration (intégrer dans l'app vs appel de test).
3. Implémentez l'appel generate routé derrière la limite serveur de l'application selon https://docs.dev.runwayml.com/model-routers.md, en chaînant le helper d'attente SDK directement depuis create().
4. Validez le même payload avec HTTP dryRun: true avant toute vérification facturable.
5. Après un test live approuvé, utilisez get_task_routing pour confirmer quel modèle a exécuté.

Terminologie

• id d'enregistrement routeur (UUID) ≠ configId (slug immuable utilisé dans le champ SDK configId).

Documentation

• https://docs.dev.runwayml.com/llms.txt (section model routers)
• https://docs.dev.runwayml.com/model-routers.md