OpenRouter route automatiquement vos requêtes - et c’est là que les problèmes commencent
Un développeur identifie plusieurs comportements incohérents sur OpenRouter dus au routage automatique entre fournisseurs, soulevant des questions concrètes pour quiconque utilise la plateforme en production.
👁 117 lectures
OpenRouter promet de simplifier l’accès aux grands modèles de langage en acheminant chaque requête vers le fournisseur le plus économique disponible - mais ce mécanisme de routage automatique introduit des incohérences de comportement que Mohamed Moustafa a documentées en détail le 11 septembre 2026, relayé par Simon Willison sur son blog.
- Le routage automatique d'OpenRouter peut rediriger une même requête vers des fournisseurs aux configurations très différentes
- Certains fournisseurs manquent de capacités vision pour des modèles supposément compatibles, et traitent différemment l'option reasoning effort
- L'option provider.only et l'endpoint /endpoints permettent de contrôler et d'auditer les fournisseurs disponibles
La promesse d’OpenRouter est séduisante pour tout développeur qui travaille avec plusieurs modèles : un seul point d’entrée API, une seule clé, et la plateforme « gère les fallbacks automatiquement et choisit l’option la plus rentable pour chaque requête », selon la description officielle du service. En pratique, cela signifie qu’une requête identique envoyée deux fois peut emprunter deux chemins différents, via deux fournisseurs distincts - avec des conséquences qui ne sont pas anodines.
Même modèle, comportements différents
Le cœur du problème réside dans la diversité des environnements de déploiement. Chaque fournisseur intégré à OpenRouter fait tourner son propre logiciel de serving, avec ses propres optimisations et ses propres paramètres de configuration. En théorie, ces différences sont transparentes pour l’utilisateur final. En pratique, elles produisent des réponses qui peuvent diverger de manière significative pour une même invite envoyée au même identifiant de modèle.
Moustafa identifie plusieurs cas concrets. Premièrement, le traitement de l’option reasoning effort - qui permet de moduler la profondeur de raisonnement d’un modèle - n’est pas standardisé : selon le fournisseur vers lequel OpenRouter redirige la requête, cette instruction peut être interprétée différemment, ignorée, ou appliquée avec des effets distincts sur la sortie. Pour un développeur qui calibre soigneusement le comportement de son application, ce type de variabilité est une source de bugs difficiles à reproduire.
Deuxièmement - et c’est peut-être le cas le plus surprenant - certains fournisseurs référencés sur OpenRouter ne disposent pas des capacités vision pour des modèles qui sont pourtant censés les prendre en charge. Envoyer une image dans une requête multimodale peut donc aboutir à un résultat dégradé ou à une erreur selon le fournisseur sélectionné à ce moment précis, sans que l’utilisateur ait reçu d’avertissement explicite lors de la configuration de son workflow.
Les conséquences pour les applications en production
Ces variations ne sont pas uniquement un problème théorique. Pour un créateur qui automatise la génération de contenu, un développeur qui construit un pipeline d’analyse d’images, ou une petite entreprise qui déploie un agent conversationnel, la stabilité du comportement du modèle est une condition de fiabilité du produit. Un agent qui fonctionne correctement lors des tests peut échouer en production si OpenRouter le redirige vers un fournisseur différent de celui utilisé pendant la phase de développement.
La nature même de l’optimisation de coût proposée par la plateforme aggrave le problème : plus un fournisseur est économique à un instant donné, plus il sera favorisé par le routage - ce qui signifie que les changements de comportement peuvent survenir précisément lors des pics d’utilisation, quand les coûts augmentent et que la plateforme cherche des alternatives moins chères.
Pour les cas d’usage impliquant des appels en lot, des évaluations comparatives ou des benchmarks internes, le routage automatique rend les résultats non reproductibles : deux séries de tests avec les mêmes paramètres peuvent avoir été traitées par des infrastructures différentes, rendant toute comparaison caduque.
Google · Vos sourcesPromptif plus haut dans Google - en un clicAjouter aux sources préférées →Les solutions disponibles - et leurs limites
OpenRouter propose des mécanismes pour reprendre le contrôle. L’option provider.only permet de restreindre explicitement le routage à un fournisseur spécifique, éliminant la variabilité au prix de la flexibilité automatique que la plateforme est censée apporter. C’est une solution efficace, mais elle demande que l’utilisateur sache d’abord quel fournisseur utiliser - ce qui implique un travail de qualification préalable.
Pour faciliter ce travail, la méthode /endpoints retourne la liste des fournisseurs disponibles pour un identifiant de modèle donné, avec leurs caractéristiques. Cet outil d’audit est précieux, mais il suppose que les développeurs pensent à l’utiliser et comprennent les implications des différences entre fournisseurs - une charge cognitive supplémentaire dans des workflows déjà complexes.
La leçon pratique est claire : utiliser OpenRouter comme une boîte noire, en faisant confiance au routage automatique sans vérification, revient à accepter implicitement un comportement non déterministe de ses applications. Pour tout usage critique - production, évaluation, ou tout workflow où la cohérence des sorties du modèle importe - la configuration explicite du fournisseur cible via provider.only n’est pas une option parmi d’autres : c’est la seule approche qui garantit que ce que vous avez testé est bien ce qui sera exécuté.
More on this from PROMPTIF
actualités·25 médaillés Fields accusent OpenAI de menacer la culture de la recherche mathématique