OpenRouter Auto Router : fonctionnement, paliers de coût et cas où fixer un modèle

Quel modèle choisir pour chaque requête sans passer son temps à comparer les benchmarks ? C’est précisément le rôle d’Auto Router d’OpenRouter (openrouter/auto). Le service classe chaque prompt dans une trentaine de catégories, puis s’appuie sur les orientations prises par les 55 T+ tokens dépensés chaque semaine sur la plateforme, plutôt que sur un classement figé. Depuis le 10 août 2026, OpenRouter a abandonné son routage basé sur NotDiamond au profit d’un signal communautaire glissant sur 7 jours. La promesse : réduire les coûts au palier par défaut et viser une qualité de niveau frontier au palier maximal. Attention toutefois : aucun supplément n’est facturé par requête, mais c’est le modèle finalement choisi qui détermine la facture. Sans réglage, une demande banale peut donc être envoyée vers un modèle coûteux.

Auto Router nouvelle génération : ce qu’il fait concrètement

Auto Router est un méta-routeur. Vous adressez votre requête à openrouter/auto comme nom de modèle, puis le service la transmet à un modèle sous-jacent précis. Vous payez le tarif standard de ce modèle, sans frais de routage additionnels. La réponse inclut un champ model indiquant le modèle retenu, ce qui permet d’auditer chaque requête.

La mise à jour d’août 2026 a remplacé l’ancien moteur de routage, auparavant alimenté par NotDiamond, par ce qu’OpenRouter appelle la « sagesse du marché ». Au lieu de laisser un modèle de classification fixe décréter quel modèle est le « meilleur », le routeur examine des données de dépenses anonymisées sur les 7 derniers jours. Si des milliers de développeurs ont transféré leur charge de travail de code d’un modèle vers un autre la semaine précédente, le routeur suit cette évolution en quelques jours.

Le classement des prompts s’effectue à la volée, sans conservation obligatoire des prompts, dans près de 30 catégories : génération de code, débogage, planification d’agents en plusieurs étapes, questions-réponses de connaissance, mathématiques, support client ou rapports de recherche, entre autres. Si les données de classification ou de classement ne sont pas disponibles, le système bascule vers un ensemble de modèles par défaut afin qu’un échec de routage ne fasse pas échouer la requête.

Deux slugs sont proposés :

Le nouveau routeur a fonctionné quelques semaines sur auto-beta avant de passer sur le slug stable le 10 août 2026. Envoyer une configuration avec le mauvais ID de plugin la fait ignorer silencieusement : un piège de configuration fréquent.

La sélection des modèles : 30 types de tâches et 5 paliers de coût

La logique de sélection repose sur deux éléments : la classification de la tâche et le palier de coût. Le routeur commence par identifier la nature de la demande à partir du prompt. Dans cette catégorie, il classe ensuite les modèles candidats selon leur part d’usage communautaire des 7 derniers jours, tout en tenant compte des restrictions de votre compte : modèles autorisés, garde-fous, paramètres de confidentialité et politiques ZDR.

Les paliers de coût déterminent jusqu’à quel niveau de prix le routeur peut monter. Ils sont au nombre de cinq, du moins cher au plus capable : low, medium, high, xhigh et max. Le réglage par défaut est low. Un palier correspond à une tranche, et non à un plafond : les modèles moins chers comme ceux plus chers que cette tranche sont exclus.

La matrice de routage publiée par OpenRouter le 10 août 2026 couvre l’ensemble des quelque 30 types de tâches. Les 15 exemples représentatifs ci-dessous montrent comment la tâche et le palier de coût orientent le choix du modèle :

Le palier low privilégie des modèles plus abordables, tels que GLM-5.2 et DeepSeek V4 Flash pour les tâches de code, ainsi que les variantes Gemini Flash pour la classification et le support. Au palier max, le routage mène vers Claude Opus 5, Claude 5 Fable ou GPT-5.6 Sol selon la tâche.

cost_tier ou l’ancien cost_quality_tradeoff ?

L’ancien paramètre numérique cost_quality_tradeoff est obsolète, mais reste accepté. Il allait de 0 à 10, avec 0 privilégiant la qualité et 10 le coût ; sa valeur par défaut était 7. Le nouveau paramètre cost_tier utilise à la place des tranches nommées. Si vous envoyez les deux, cost_quality_tradeoff est prioritaire. Ce choix de compatibilité ascendante peut provoquer un routage inattendu lors d’une migration de code existant. Retirez donc l’ancien paramètre avant d’adopter cost_tier.

Exemple de configuration dans une requête API :

{
  "model": "openrouter/auto",
  "messages": [{ "role": "user", "content": "Debug this Python function" }],
  "plugins": [{
    "id": "auto-router",
    "cost_tier": "max",
    "allowed_models": ["anthropic/*", "openai/*"]
  }]
}

allowed_models accepte des motifs génériques comme anthropic/* pour limiter le choix à un fournisseur. La liste excluded_models est appliquée après allowed_models et permet de réduire encore le pool. S’il ne reste aucun modèle après filtrage, l’API renvoie une erreur 404.

Benchmarks : le nouveau routeur face à l’ancien

OpenRouter a évalué les anciens et nouveaux routeurs sur cinq benchmarks variés, avec leurs réglages par défaut et leurs réglages maximaux. Pour l’ancien routeur, le réglage par défaut était cost_quality_tradeoff=7 ; pour le nouveau, il s’agit de cost_tier=low.

Au palier par défaut, le nouveau routeur égale ou dépasse l’ancien sur 3 benchmarks sur 5. Les gains les plus nets apparaissent sur DSQA, pour la recherche (+45,6 %), et WideSearch, pour la recherche web (+16,0 %). Il recule légèrement sur MMLU Pro (-1,6 %) et tau-bench Banking (-1,9 %), et fait jeu égal sur SWE-Atlas QnA. Les coûts du palier par défaut sont inférieurs sur MMLU Pro (-64,2 %), tau-bench (-51,3 %) et SWE-Atlas (-35,9 %), mais supérieurs de 87,6 % sur DSQA ($276 contre $147.11). Au palier maximal, le nouveau routeur remporte les 5 benchmarks : tau-bench Banking passe de 7,2 % à 31,6 % (+338,9 %), tandis que SWE-Atlas QnA progresse de 2,4 % à 60,7 % (+2429,2 %). En contrepartie, les coûts au palier maximal sont plus élevés dans 4 benchmarks sur 5, SWE-Atlas atteignant $1,325 contre $205. Ces résultats sont instantanés : OpenRouter prévient que le comportement du routage évolue avec les préférences de la communauté.

Maîtriser les coûts et éviter les mauvaises surprises

Les frais imprévus sont une inquiétude récurrente autour d’Auto Router. Comme le résume un utilisateur de r/openrouter :

« It might just keep using Opus. » — u/xtekno-id, qui alerte sur le risque de sélection non contrôlée de modèles coûteux dans le contexte d’une équipe d’ingénierie.

Cinq mesures concrètes permettent de garder les dépenses prévisibles :

1. Le suffixe :free n’a pas l’effet attendu. openrouter/auto:free ne limite pas Auto Router aux modèles gratuits : il peut toujours router vers des modèles payants. Pour un routage sans aucun coût, utilisez plutôt openrouter/free, qui restreint le pool aux seuls endpoints du niveau gratuit. Le centre d’aide d’OpenRouter le confirme.

2. Associez cost_tier et allowed_models. Définir uniquement cost_tier=low n’empêche pas le routeur de choisir un modèle qui devient coûteux à votre volume. Ajoutez allowed_models pour vous limiter à certaines familles : ["deepseek/*", "google/*"] vous maintient dans une tranche budgétaire pour la plupart des types de tâches.

3. Fixez un plafond strict avec provider.max_price. Ce paramètre filtre les endpoints éligibles selon leur prix. Vous obtenez ainsi une limite de coût par token, indépendante du choix de palier du routeur.

4. N’oubliez pas les frais de plateforme de 5,5 %. OpenRouter facture 5,5 % lors de l’achat de crédits, avec un minimum de $0.80, et non à chaque token. Un dépôt de $20 en crédits revient donc à $21.10. Ces frais s’appliquent que vous utilisiez ou non Auto Router : ils correspondent à la monétisation de la plateforme, pas à un supplément de routage.

5. Tenez compte de l’affinité de session et du coût du cache. Si le routeur change de modèle au milieu d’une conversation, le cache d’entrée doit être reconstruit, ce qui augmente le coût en tokens. Pour limiter cela, le routeur maintient une affinité de session : il reconnaît les conversations via un session_id explicite ou une empreinte des messages, reclasse les candidats à chaque tour, mais privilégie le modèle précédent s’il reste parmi les meilleurs choix. Si la tâche change sensiblement, le routeur basculera vers un autre modèle, avec le coût de reconstruction du cache qui l’accompagne.

Auto Router ou modèle fixé : lequel choisir ?

Auto Router convient aux charges de travail variables, avec différents types de tâches à différents moments et un choix manuel de modèle qui finirait par devenir un frein. Sa matrice de routage fournit un bon point de départ pour comprendre à quels modèles la communauté fait confiance selon chaque usage.

Pour les équipes d’ingénierie, le compromis le plus pragmatique consiste à contraindre Auto Router : définissez cost_tier selon votre budget, limitez allowed_models aux fournisseurs validés par votre organisation et utilisez provider.max_price comme plafond strict.

FAQ

OpenRouter Auto Router coûte-t-il plus cher ?

Non. Auto Router n’applique aucun supplément. Vous payez le tarif standard du modèle sélectionné. Les revenus d’OpenRouter proviennent des frais de 5,5 % prélevés lors de l’achat de crédits.

openrouter/auto:free est-il réellement gratuit ?

Non. Le suffixe :free ne restreint pas le routage aux modèles gratuits. Utilisez plutôt openrouter/free, le routeur dédié exclusivement aux modèles gratuits.

Puis-je limiter Auto Router à certains fournisseurs ?

Oui. Employez le paramètre allowed_models avec des motifs génériques comme ["anthropic/*", "openai/*"] dans le plugin auto-router.

Comment savoir quel modèle a été choisi ?

Consultez le champ model dans la réponse de l’API. Il contient l’identifiant du modèle qui a traité votre requête, et non openrouter/auto.

Quelle différence entre auto et auto-beta ?

openrouter/auto est le routeur stable. openrouter/auto-beta reçoit les améliorations de routage avant leur arrivée sur la version stable.

Auto Router prend-il en charge le streaming et le tool calling ?

Oui. L’ensemble des fonctionnalités du modèle sélectionné, dont le streaming, le tool calling et la vision, reste disponible.