Routage des fournisseurs OpenRouter : mise à jour d’octobre 2026

Depuis le 28 octobre 2026, OpenRouter a remplacé son mécanisme de routage par défaut. Le temps avant le premier token recule de 16,9 %, le nombre total d’événements 429 baisse de 67 %, mais les requêtes coûtent environ 6 % de plus. Un compromis à ne pas ignorer : le routage automatique peut aussi vous basculer discrètement vers un fournisseur plus cher.

Le nouveau routeur d’OpenRouter ne cherche plus simplement le tarif d’entrée par token le plus bas. Il estime le coût d’une bonne réponse — prix, attente et nouvelles tentatives compris — puis dirige chaque requête vers le fournisseur affichant le Routing Cost le plus faible.

Ce qu’il faut retenir en 30 secondes

Le routage des fournisseurs OpenRouter optimise désormais le Routing Cost, plutôt que le prix des tokens du prompt. Ce changement s’applique automatiquement dès lors qu’une requête ne définit pas explicitement provider.sort, provider.order, provider.only ou provider.ignore. Selon l’annonce d’OpenRouter, il concerne environ 77 % du trafic, soit les modèles proposés par plus d’un fournisseur.

Les résultats proviennent d’un test switchback d’une semaine, mené sur 24 millions de requêtes et 103 milliards de tokens d’entrée, répartis à parts égales entre l’ancien et le nouveau routeur.

\*Les proportions de requêtes et les réductions du nombre d’événements sont toutes deux rapportées dans l’annonce : les 67 % et 47 % concernent le total des événements 429 et des nouvelles tentatives, pas le ratio des taux d’incidence, puisqu’une même requête peut rencontrer plusieurs erreurs.

Toujours selon l’annonce, le TTFT p95 mesuré côté appelant est passé de 6,032 ms à 4,504 ms, la durée p50 d’une requête complète de 4.00 s à 3.24 s, et le temps perdu dans les tentatives échouées de 349 ms à 242 ms par requête.

En pratique : conservez le nouveau comportement par défaut pour un chat interactif ou des agents si vous acceptez environ 6 % de surcoût. Pour les gros traitements batch, où chaque centime compte, revenez au routage fondé uniquement sur le prix.

Le Routing Cost, simplement expliqué

Pour chaque fournisseur, le Routing Cost répond à deux questions : combien coûte un essai, et quelle est sa probabilité de réussir ? Dans l’exemple d’OpenRouter, un essai à $0.40 auquel s’ajoutent $0.60 d’attente revient à $1.00. Divisé par 80 % de chances de succès, cela donne $1.25 par bonne réponse. Le coût le plus bas attire davantage de trafic.

Ce calcul repose sur trois éléments :

1. Le prix réellement payé, pas le tarif affiché. OpenRouter estime les volumes de tokens d’entrée et de sortie à partir du trafic récent, puis applique pour chaque fournisseur le véritable taux de cache hit et les prix de tokens correspondants. Exemple détaillé dans l’annonce : 40K entrées non mises en cache à $2.00/M ($0.080), plus 60K entrées mises en cache à $0.50/M ($0.030), plus environ 4K sorties à $8.00/M ($0.032), soit $0.142. Un fournisseur aux entrées bon marché mais aux tokens mis en cache ou de sortie coûteux perd donc son avantage.
2. Le temps d’attente converti en dollars. Le débit correspond aux tokens de sortie de bout en bout par seconde, premier token inclus. Exemple : 5 s avant le premier token, puis 500 tokens générés en 5 s, soit 50 tok/s. Le routeur convertit cette attente à l’aide d’un tarif par modèle basé sur les prix et vitesses habituels des fournisseurs. Le délai avant le premier token est davantage pondéré, car les chaînes d’appels d’outils d’un agent l’attendent à chaque étape.
3. Le coût des échecs. Un 429 indique que le fournisseur a refusé la requête : il faut attendre le rejet, puis la renvoyer ailleurs. Exemple : 2.50 d’attente, plus une pénalité × un taux de 0.4 %, ajoute 0.01. Les erreurs de fiabilité sont pénalisées environ 8x plus lourdement : 1 % d’erreurs augmente le coût d’environ 8 %. Les fournisseurs nettement moins performants que leurs concurrents cessent de recevoir du trafic jusqu’à leur rétablissement. À ce stade, la qualité est évaluée notamment via des appels d’outils bien formés : 95 % d’appels bien formés font monter le coût d’environ 5 %. Les fournisseurs signalés sont limités à du trafic de test, selon l’annonce.

Deux garde-fous évitent que tout le trafic converge vers un seul gagnant, selon l’annonce : chaque fournisseur conserve un faible flux de requêtes afin que son rétablissement soit détectable, tandis que le routeur réduit progressivement le trafic vers les fournisseurs défaillants, apprend leurs plafonds de capacité et redirige l’excédent ailleurs.

Pourquoi le routage par défaut peut encore casser une app en production

Les retours d’utilisateurs font ressortir quatre modes de défaillance récurrents que le prix par token ne sait pas capturer.

Les changements de fournisseur cassent les schémas d’appels d’outils

ce qui a réellement cassé les appels d’outils chez moi, c’est le changement de fournisseur en cours de requête, pas le prix affiché par l’un ou l’autre.

— u/Michael_Jeffords, discussion r/openrouter sur les fournisseurs à éviter

À l’heure actuelle, le score de qualité repose surtout sur des appels d’outils bien formés et des signalements issus de benchmarks d’exactitude, selon l’annonce. Un changement en pleine conversation peut néanmoins modifier la quantification ou le comportement de refus, car la qualité varie selon les fournisseurs et certains servent des variantes davantage quantifiées.

Un cache invalide peut faire exploser la facture

Une discussion documente des contextes d’environ 700K tokens : des requêtes mises en cache qui auraient dû coûter $0.20 ont été facturées près de $2.00 après des changements de fournisseur. C’est le mécanisme derrière les cas de « paiement 10-32x supérieur à cause d’un cache cassé ». Le nouveau routeur conserve une conversation chez son fournisseur initial tant que le cache est chaud et ne choisit algorithmiquement que la première requête, selon le routage tenant compte du cache d’OpenRouter. Cette affinité disparaît toutefois lors d’un fallback vers un autre fournisseur. Les utilisateurs ayant résolu le problème ont fixé un fournisseur via des sessions persistantes.

Je pense que c’est une faiblesse assez fondamentale d’OR : il faut configurer cela manuellement à l’avance.

— u/welcome_to_milliways, discussion r/openrouter sur le cache cassé

Un fallback coûteux et silencieux

Un retour de production a observé qu’une partie du trafic passait silencieusement de Sonnet à Opus, pour environ 5x le prix affiché, alors que l’uptime restait au vert et que la dépense globale grimpait de $184/hr à $412/hr, d’après @CarbonOnX. Le nouveau routeur rend ce compromis explicite : un fournisseur plus rapide et plus fiable peut légitimement passer devant le moins cher.

Des 429 malgré un compte crédité

Disposer d’un solde OpenRouter ne augmente pas la capacité en amont, comme le relèvent les utilisateurs de cette discussion sur les 429. Un 429 reflète le pool partagé de ce fournisseur pour ce modèle. La refonte a réduit les événements 429 de 67 % en test, mais fixer un fournisseur ou ignorer celui qui est limité reste la solution de production. Commencez par comment corriger les erreurs OpenRouter 429, puis consultez le guide OpenRouter Auto Router pour l’ancien routage par défaut pondéré par le prix.

Trois configurations de routage qui tiennent la route

Le bon choix dépend de votre priorité : vitesse sans intervention, plafond de coût strict ou comportement déterministe. Toutes reposent sur le même objet provider : provider.order contourne la nouvelle logique et essaie les fournisseurs dans l’ordre exact indiqué ; provider.only et provider.ignore filtrent les candidats, puis le nouvel algorithme tranche entre les survivants ; tout provider.sort explicite — price, throughput ou latency — le remplace.

1. Garder le nouveau comportement par défaut pour le chat et les agents

Aucune modification de code n’est nécessaire. Cette option convient aux chats orientés utilisateur et aux agents en plusieurs étapes, où chaque appel d’outil attend le premier token. Considérez le surcoût d’environ 6 % comme un budget de latence et de nouvelles tentatives. Pendant une semaine, journalisez le fournisseur ayant servi la requête — présent dans la réponse API et la page d’activité — avec le TTFT p50 et le taux de 429. Si votre part de 429 reste proche de la nouvelle base d’environ 4 % et que le taux de cache hit tient, conservez cette configuration. Si un fournisseur concentre les échecs ou si les cache hits s’effondrent, passez à la configuration 3.

2. Verrouiller le chemin le moins cher pour les batchs et les travaux plafonnés

Trois options permettent de privilégier le routage par prix lorsque le coût prime sur la vitesse :

{ "provider": { "sort": "price" } }

Vous pouvez aussi ajouter :floor au slug du modèle — meta-llama/llama-4-maverick:floor — ou choisir le tri par prix comme valeur par défaut dans les paramètres du compte, selon la FAQ de l’annonce. Attention : :floor inclut également les endpoints flex-tier, contrairement à sort seul, selon le guide de routage d’OpenRouter.

Ajoutez-lui un plafond :

{ "provider": { "sort": "price", "max_price": { "prompt": 1.0, "completion": 2.0 } } }

À privilégier pour les prompts longs, les sorties courtes et les nouvelles tentatives peu coûteuses.

3. Épingler un fournisseur stable pour la production, le cache ou les appels d’outils

Épinglez un fournisseur lorsque la justesse, les cache hits ou la conformité comptent davantage que l’optimisation requête par requête :

{
  "provider": {
    "order": ["deepinfra", "together"],
    "allow_fallbacks": true,
    "require_parameters": true
  }
}

require_parameters évite uniquement les endpoints auxquels il manque des paramètres requis ; cela ne garantit pas un comportement identique entre fournisseurs pour les appels d’outils ou les schémas. Réservez order avec allow_fallbacks: false aux cas de conformité ou de BYOK, où une indisponibilité vaut mieux qu’un fournisseur non approuvé. Pour la plupart des applications, autorisez les fallbacks, resserrez la sélection avec only/ignore, et transmettez un session_id stable afin de réutiliser le cache chaud (sticky routing). Si un fournisseur est instable, bloquez-le dans vos garde-fous et comparez avec ses API directes : plusieurs utilisateurs indiquent qu’un accès direct a éliminé les lenteurs et les problèmes de cache une fois le modèle choisi (exemple de discussion).

Le routage automatique est meilleur qu’avant. Il ne remplace toutefois pas l’épinglage lorsqu’un seul mauvais changement de fournisseur coûte plus qu’une semaine de prix par token légèrement plus élevés.

FAQ

Dois-je modifier mon code pour utiliser le nouveau routage ?

Non. Les requêtes sans tri, ordre, only ou ignore explicites pour le fournisseur utilisent automatiquement le nouveau routeur.

Comment conserver un routage fondé uniquement sur le prix ?

Définissez provider.sort sur "price", ajoutez :floor, ou faites du tri par prix le choix par défaut de votre compte.

Le nouveau routage remplace-t-il mon ordre de fournisseurs ?

Non. order le contourne ; only/ignore filtrent d’abord les fournisseurs, puis le nouvel algorithme choisit.

Le nouveau routage coûtera-t-il plus cher ?

Consultez le tableau récapitulatif : +6.0% pour 1K requêtes et +7.3% par M tokens dans les tests.

Comment savoir quel fournisseur a réellement servi ma requête ?

Consultez le champ provider de la réponse API et la page d’activité, conformément à la documentation OpenRouter.

Pourquoi reçois-je encore des 429 avec un compte crédité ?

À cause des limites du pool partagé en amont, et non de votre solde. Épinglez ou ignorez le fournisseur soumis à la limitation.