Routeur de modèles LLM : quand il bat un modèle unique, et quand il perd

Le 2 octobre 2026, OpenRouter a mis en ligne ses Model Router Benchmarks : sept routeurs de modèles comparés sur six benchmarks, en qualité, en vitesse et en coût¹. Le même billet, signé Brian Thomas, dresse la liste des cas où un routeur fait moins bien qu'un modèle appelé directement. Un routeur de modèles LLM choisit à votre place quel modèle répond à chaque requête ; un modèle unique vous laisse cette décision, et sa facture. La question pour une équipe qui met un agent en production tient en une ligne : confier ce choix à un routeur automatique, ou coder une escalade que l'on mesure ?

Le verdict tient en deux lignes. Un routeur se juge sur votre trafic, avec vos critères, et aucun index public ne remplace cette mesure. En production, le défaut défendable reste un modèle de base choisi sur une barre de qualité par tâche, avec une escalade codée dans l'application vers un modèle plus fort ; les routeurs gardent l'exploration, le prototypage et les segments de trafic où vous avez vérifié qu'ils ne perdent rien. Cet article traite du choix du modèle ; la grille des trois métiers des AI gateways et la configuration d'OpenRouter en production sont traitées à part.

Que mesurent les Model Router Benchmarks d'OpenRouter ?

La page publique compare les routeurs sur des benchmarks de code (deep_swe, swe_atlas_qa, terminal-bench-4.0 ajouté les 2 et 3 octobre), de raisonnement scientifique (GPQA Diamond), de vision (mmmu_pro_vision), de recherche (search_hle) et d'agent bancaire (tau3_bench_banking)². Les routeurs évalués sont l'Auto Router d'OpenRouter et ses paliers de coût, Jev Router de TypeSafe, Pareto d'Unbiased, Fugu de Sakana (variantes Max et Ultra) et Switchyard de NVIDIA.

Un Router Index « synthétise la qualité, la vitesse et le coût en un score de 0 à 10 pour chaque benchmark », pondéré par défaut à 60 % pour le score au benchmark, 20 % pour le temps par tâche et 20 % pour le coût¹. OpenRouter ne publie aucun classement en texte : la page expose des exécutions, et c'est le lecteur qui compare. Nous avons consulté ces exécutions brutes le 12 octobre 2026 ; les chiffres ci-dessous en viennent, et ils ne constituent pas un palmarès.

Pourquoi un index à trois pondérations ne décide rien pour vous

Le billet d'annonce le dit : ces techniques « ont chacune des difficultés qui peuvent parfois conduire à de moins bonnes performances que l'usage direct d'un seul modèle »¹. OpenRouter cite quatre limites. Changer de modèle rend les requêtes plus chères le temps de reconstruire le cache d'entrée. Les routeurs « n'ont souvent pas assez d'information pour évaluer la complexité d'une tâche en regardant seulement le prompt ». Les signaux heuristiques sur l'étape de la session peuvent contredire le prochain pas du modèle. Et chaque traitement ajouté à la décision de routage ajoute de la latence.

Les exécutions brutes montrent ce que la pondération lisse. Sur GPQA Diamond, les précisions se tiennent dans une fourchette étroite pour des coûts sans rapport : Fugu Ultra atteint 0,946 pour 227,45 $ d'inférence sur 594 questions ; Switchyard, 0,949 pour 7,09 $ sur 198 questions ; Jev Router, 0,939 pour 3,15 $ sur 198 questions². Ramené à la question, puisque les volumes diffèrent, l'écart entre Fugu Ultra et Switchyard dépasse un facteur dix pour une précision équivalente. Un index qui pèse le coût à 20 % absorbe cet écart ; votre facture, non.

Le palier de coût n'achète pas la qualité. Sur le même GPQA Diamond, avec 990 questions dans les deux cas, l'Auto Router en palier « low » obtient 0,882 pour 8,99 $, et en palier « high » 0,832 pour 60,23 $². Sur la vision, les routeurs perdent contre les modèles seuls : sur mmmu_pro_vision, GPT-6 Astra appelé directement obtient 0,842 et Claude Opus 5.5 0,818 ; le meilleur routeur, Auto en palier « medium », 0,812 ; Pareto 0,746 ; Auto « low » 0,654². Quand la modalité tranche déjà le choix du modèle, un routeur n'ajoute qu'une occasion de se tromper.

L'Auto Router mesure la popularité, pas la qualité

La documentation de l'Auto Router décrit son critère : la dépense de la communauté OpenRouter sur une fenêtre glissante de sept jours, par type de tâche (une trentaine de types fins), modulée par un réglage cost_tier de « low » à « max » dont le défaut est le moins cher³, un fonctionnement détaillé dans notre analyse de la marketplace OpenRouter. Vous pouvez restreindre ou exclure des modèles (allowed_models, excluded_models, l'exclusion l'emportant). La documentation actuelle ne mentionne plus le moteur Not Diamond que décrivait le centre d'aide.

Ce critère a une propriété à connaître avant de s'y fier : il suit ce que les autres paient, pas ce qui marche chez vous. C'est utile pour découvrir un modèle que le marché vient d'adopter sur votre type de tâche. C'est inexplicable devant un comité d'architecture qui demande pourquoi, mardi, le modèle a changé.

La méthode qui tient : une barre de qualité par tâche

OpenRouter publie, le 1er octobre, un cadre d'arbitrage coût contre qualité pour les modèles d'agents⁴. Il tient en quatre gestes. Fixer une barre de qualité propre à chaque tâche. Comparer un modèle économique, un intermédiaire et un modèle frontier sur 20 à 50 exemples propres. Retenir le moins cher qui « passe la barre avec une marge supérieure à l'écart de score que vous observez entre deux exécutions ». Lire le coût réel dans le champ usage.cost de chaque réponse plutôt que dans une grille tarifaire.

L'exemple fourni est un routage de tickets, environ 700 tokens en entrée et 150 en sortie, aux prix du 18 septembre 2026, barre fixée à 85. GPT-5.6 Luna coûte 0,32 $ pour 1 000 requêtes et obtient 82, sous la barre. Gemini 3.7 Flash coûte 1,09 $ et obtient 89, soit quatre points de marge. Claude Opus 5 coûte 7,25 $ et obtient 97. Le cadre retient Gemini 3.7 Flash, le moins cher au-dessus de la barre⁴. OpenRouter précise que « les comptes de tokens et les scores de qualité sont illustratifs » : la leçon est la méthode, pas le podium, et une autre tâche, une autre barre, donnent un autre gagnant.

La méthode rejoint notre analyse du coût par résultat : le prix au token ne dit rien du coût d'une tâche réussie.

L'escalade par seuil de confiance se code dans l'application

Le même jour, OpenRouter décrit une escalade à deux paliers⁵. Le modèle économique répond dans un schéma JSON strict (response_format avec json_schema et strict: true, plus provider.require_parameters: true pour écarter les fournisseurs qui ne garantissent pas le schéma) qui contient la réponse et un score de confiance. Sous un seuil, votre code renvoie la requête au modèle fort. Dans l'exemple, sur 200 requêtes avec un seuil de 0,7, 14 % des requêtes sont escaladées, et le taux d'erreur sur les réponses conservées passe d'un peu moins de 10 % à environ 4 %. L'éditeur le qualifie lui-même d'« illustration à l'arithmétique cohérente, pas une cible ».

Le point qui compte pour l'architecture tient dans une phrase du billet : « c'est votre code qui prend la décision d'escalade ». Les chaînes de secours de la passerelle « se déclenchent quand un modèle renvoie une erreur, pas quand il renvoie une réponse valide avec un score de confiance bas »⁵. Autrement dit, aucun paramètre de routage ne fait d'escalade qualitative à votre place. Elle vit dans l'application, elle se versionne, et elle se teste.

Un score de confiance produit par un LLM reste autodéclaré. Calibrez donc le seuil sur votre jeu d'évaluation, pas sur l'exemple du billet, ou confiez la décision à un modèle conçu pour trancher : Jev, le modèle de décision de TypeSafe, renvoie des choix et des probabilités calibrées sans générer de texte, et la question « faut-il escalader ? » est de celles qu'il est fait pour.

Le tutoriel d'OpenRouter sur les bots de support, publié le 2 octobre, donne la condition de rentabilité de ce schéma « cheap-first »⁶. Le coût attendu d'une requête s'écrit : coût du modèle économique, plus coût du premier contrôle, plus la fraction escaladée multipliée par le coût du modèle fort et de son contrôle. L'escalade gagne tant que cette fraction reste basse et que les contrôles coûtent moins que l'écart de prix entre les deux modèles ; sur un trafic majoritairement difficile, le modèle fort seul coûte moins que le détour. Le tutoriel ne donne aucun seuil chiffré, et rappelle qu'un HTTP 200 peut contenir une erreur applicative que le fallback de la passerelle ne verra jamais.

Les evals qui rendent la décision défendable

Barre par tâche, seuil d'escalade, comparaison de routeurs : tout repose sur un jeu d'évaluation. OpenRouter en documente la construction à partir du trafic de production⁷ : échantillonner au hasard une à deux semaines de journaux, commencer à 20 ou 50 items et viser 100 à 1 000 pour un jeu de régression, parce que « la couverture des modes d'échec compte plus que le volume », noter en « atteint » ou « non atteint », faire annoter un sous-ensemble par deux personnes, relire chaque trimestre les items de plus de six mois.

Le juge automatique est un modèle distinct de celui qu'il note : Anthropic le recommande⁸, et Zheng et al. (NeurIPS 2023) ont mesuré le biais d'auto-complaisance, avec ceux de position et de verbosité, tout en montrant qu'un juge LLM atteint plus de 80 % d'accord avec les préférences humaines⁹. Le jeu devient ensuite une porte de CI : il vit dans le dépôt des prompts, le seuil se mesure sur des exécutions répétées d'une branche inchangée, et sans contrôle requis la PR fusionne¹⁰. Pour un changement de modèle, les cas sont verrouillés, seul le modèle varie, et les alias « -latest » sont proscrits parce qu'ils changent de modèle sans commit¹¹. Ori Eval, l'outil d'OpenRouter, écrit ces evals en fichiers *.eval.ts exécutés par bun test, avec un juge LLM pour les réponses ouvertes ; l'éditeur annonce « une eval coûte généralement 10 à 30 $ »¹².

Cette discipline rejoint le TDD du contexte : le même jeu qui protège vos prompts protège votre choix de modèle.

Le piège qui annule l'économie : le cache

Chaque bascule de modèle repart avec un cache de préfixe vide. La documentation d'OpenRouter annonce « jusqu'à 80 à 90 % » de réduction du temps et du coût de préremplissage quand le cache tient, pour des tours de 20 000 à 90 000 tokens d'entrée, et précise qu'un changement de slug, même vers une variante :nitro du même modèle, invalide la clé de session¹³. Sa lettre d'information du 8 octobre mesure l'enjeu : le fournisseur médian servait 44 % des tokens de prompts agentiques depuis le cache en janvier 2026, 85 % en septembre¹⁴. Un routeur qui change de modèle au milieu d'une session d'agent rend cette économie, et la rend sur chaque tour suivant. C'est l'argument qui plaide pour router par tâche, au premier tour, comme le décrit notre guide un modèle par tâche, et jamais par requête au fil d'une session.

Ce que ça change pour vous

CTO, architecte. Écrivez l'escalade dans votre code, dans un module qui porte le seuil, le schéma de sortie et le jeu d'évaluation. Tout routeur externe se teste en observation sur votre trafic avant d'être activé, segment par segment, et seulement là où l'écart mesuré est nul. Fixez le modèle d'une session d'agent au premier tour et n'en changez plus.

FinOps, achats. Ne comparez jamais deux modèles ni deux routeurs sur le prix au token ni sur un index : demandez le coût par tâche réussie, lu dans usage.cost, sur votre jeu d'évaluation. Un routeur dont le critère est la dépense d'autres clients ne vous engage sur rien, et un palier de coût plus cher n'achète pas une qualité plus haute.

DSI. Exigez que chaque choix de modèle en production soit reproductible : un jeu d'évaluation versionné, une barre écrite, un seuil daté. Un routeur automatique répond à « que paient les autres », pas à « pourquoi ce modèle a traité ce dossier », et c'est la seconde question qu'un auditeur vous posera.

FAQ

Un routeur de modèles LLM fait-il mieux qu'un modèle unique ? Parfois, et OpenRouter le dit lui-même : ses techniques peuvent faire moins bien qu'un modèle appelé directement. Sur ses exécutions, les routeurs restent sous les meilleurs modèles seuls en vision, et des précisions comparables s'achètent à des coûts qui diffèrent d'un facteur dix. La réponse se mesure sur votre trafic.

Qu'est-ce qu'une escalade par seuil de confiance ? Un modèle économique répond dans un schéma JSON strict avec un score de confiance ; sous un seuil, votre code relance la requête vers un modèle plus fort. Dans l'illustration d'OpenRouter, seuil 0,7, 14 % des requêtes escaladent et l'erreur sur les réponses conservées passe d'environ 10 % à environ 4 %. Les fallbacks de la passerelle ne font pas ce travail : ils se déclenchent sur une erreur, pas sur une réponse valide mais mauvaise.

Comment choisir un modèle LLM entre coût et qualité ? Une barre de qualité par tâche, trois paliers de modèles comparés sur 20 à 50 exemples propres, et le moins cher qui passe la barre avec une marge supérieure à la variance entre exécutions. Le coût se lit dans la réponse de l'API, pas dans la grille tarifaire.

Un routeur casse-t-il le cache de prompt ? Oui dès qu'il change de modèle en cours de session : le cache de préfixe est propre à un modèle et à un fournisseur, et OpenRouter note qu'un changement de slug invalide la session collante. Routez par tâche au premier tour, pas par requête.

---

Sources

1. Brian Thomas, « Model Router Benchmarks », blog OpenRouter, 2 octobre 2026 — sept routeurs, six benchmarks, Router Index pondéré 60 / 20 / 20, quatre limites citées (cache reconstruit, information insuffisante dans le prompt, signaux de session, latence). Documentation éditeur. openrouter.ai
2. Page « Router Benchmarks », OpenRouter, exécutions brutes consultées le 12 octobre 2026 — précisions et coûts d'inférence par exécution (GPQA Diamond, mmmu_pro_vision, tau3_bench_banking, terminal-bench-4.0 ajouté les 2 et 3 octobre). Données éditeur, nombre de questions variable d'une exécution à l'autre, aucun classement publié en texte. openrouter.ai
3. Documentation OpenRouter, « Auto Router » — critère de dépense communautaire sur sept jours glissants, une trentaine de types de tâches, cost_tier, allowed_models / excluded_models, cost_quality_tradeoff déprécié mais accepté, en-tête de métadonnées. Documentation éditeur, consultée le 12 octobre 2026. openrouter.ai
4. « Cost vs. Quality Tradeoff Framework for Agent Models », blog OpenRouter, 1er octobre 2026 — barre par tâche, trois paliers sur 20 à 50 exemples, marge supérieure à la variance, usage.cost ; exemple de routage de tickets aux prix du 18 septembre 2026, déclaré illustratif. Documentation éditeur. openrouter.ai
5. « Confidence Thresholds for Model Escalation Routing », blog OpenRouter, 1er octobre 2026 — schéma JSON strict, require_parameters, exemple de 200 requêtes à seuil 0,7, décision prise par le code applicatif, fallbacks déclenchés sur erreur seulement. Illustration déclarée comme telle par l'éditeur. openrouter.ai
6. « Model Routing for Support Bots: Cheap-First FAQ Handling », blog OpenRouter, 2 octobre 2026 — règles, classifieur ou contrôle de réponse côté application, formule du coût attendu, aucun seuil chiffré, erreur possible dans un HTTP 200. Documentation éditeur. openrouter.ai
7. « Building a Golden Eval Dataset from Production Traffic », blog OpenRouter, 30 septembre 2026 — échantillonnage d'une à deux semaines de journaux, 10 / 20-50 / 100-1 000 items selon l'usage, couverture des modes d'échec, double annotation, juge distinct, revue trimestrielle. Documentation éditeur. openrouter.ai
8. Anthropic, « Define success criteria and build evaluations », documentation Claude — critères mesurables, distribution réelle des tâches, trois méthodes de notation, modèle évaluateur distinct recommandé. Documentation éditeur, consultée le 12 octobre 2026. platform.claude.com
9. Lianmin Zheng et al., « Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena », NeurIPS 2023 Datasets and Benchmarks — plus de 80 % d'accord entre un juge GPT-4 et les préférences humaines, biais de position, de verbosité et d'auto-complaisance. Publication académique. arxiv.org
10. « How to Gate Pull Requests on LLM Evals in CI », blog OpenRouter, 1er octobre 2026 — jeu d'évaluation dans le dépôt des prompts, seuil mesuré sur des exécutions répétées, vote majoritaire quand température et graine ne sont pas supportées, contrôle requis. Documentation éditeur. openrouter.ai
11. « AI Agent Regression Testing After a Prompt or Model Change », blog OpenRouter, 30 septembre 2026 — cas verrouillés, une seule variable, invariant dur bloquant, alias « -latest » à éviter. Documentation éditeur. openrouter.ai
12. Jacky Liang, « Ori Eval », blog OpenRouter, 3 août 2026 — fichiers *.eval.ts, bun test, assertions sur appels d'outils, juge LLM pour les réponses ouvertes, « an eval usually costs $10 to $30 », intégration GitHub Actions. Annonce éditeur. openrouter.ai
13. Documentation OpenRouter, « Latency and Performance » — session collante de dix minutes au mieux, « up to 80–90% » de réduction du préremplissage, 20 000 à 90 000 tokens d'entrée par tour, changement de slug invalidant la clé, provider.order désactivant la session collante. Chiffres éditeur, non datés. openrouter.ai
14. Peter Walker, « Cache is Crucial », lettre Inferred n° 03, OpenRouter, 8 octobre 2026 — part médiane de tokens de prompts agentiques servis depuis le cache par fournisseur d'inférence : 44 % en janvier 2026, 85 % en septembre. Mesure éditeur sur son propre trafic. openrouter.ai