OpenRouter est une infrastructure pour développeurs qui réunit plus de 500 modèles de plus de 80 fournisseurs derrière une seule API compatible OpenAI. Elle classe chaque requête pour choisir un modèle, répartit la charge entre fournisseurs, bascule automatiquement en cas de panne et répercute les tarifs sans marge.
Vous avez utilisé cet outil ? Notez-le
Vous avez utilisé cet outil ? Notez-le
OpenRouter est une infrastructure qui s'intercale entre votre application et les fournisseurs de modèles d'IA que vous souhaitez utiliser. Son positionnement tient en une phrase : une interface unifiée pour chaque modèle, assortie d'une promesse de meilleurs prix, d'une meilleure disponibilité et d'aucun abonnement. Concrètement, vous intégrez une seule fois, contre un seul point d'accès, et vous obtenez un catalogue qui exigerait autrement des dizaines de comptes fournisseurs distincts, de kits de développement, de relations de facturation et de chemins de gestion des pannes.
La documentation énonce la proposition de valeur sans ornement : accéder à des centaines de modèles d'IA par un point d'accès unique, avec une gestion automatique des bascules et le choix d'une option économiquement pertinente pour chaque requête. Ces deux phrases contiennent tout le produit : l'agrégation, plus l'intelligence qui détermine quel modèle et quel fournisseur doivent traiter un appel donné.
Il faut être direct sur le public visé, car OpenRouter est fréquemment mal classé. Le site héberge bien une interface de discussion dans le navigateur, ce qui conduit certains annuaires à le ranger auprès des produits de conversation destinés au grand public. C'est une lecture erronée. Cette page de discussion existe pour que les développeurs essaient des modèles et déboguent des invites ; le produit est une couche d'API accompagnée de facturation, de routage et d'observabilité. Si vous n'écrivez pas de code et ne configurez pas d'application pour appeler une API, ce n'est pas un outil que vous utiliseriez directement. Si vous le faites, il traite un problème qui devient vite pénible : chaque fournisseur de modèles a son propre kit de développement, sa propre authentification, ses propres limites de débit et ses propres pannes.
Le service est exploité par OpenRouter, Inc., enregistrée au 169 Madison Avenue à New York, les conditions étant régies par le droit de l'État de New York. La société a été fondée par Alex Atallah, auparavant cofondateur d'OpenSea, et un commentaire d'investisseur résume la proposition ainsi : une API, une facturation centralisée. Cette formule capture la seconde moitié de la valeur : consolider les dépenses réparties entre de nombreux fournisseurs sur un seul compte plutôt que de rapprocher une douzaine de factures.
Songez à ce qu'implique l'intégration directe de cinq fournisseurs de modèles : cinq clés d'API à faire tourner, cinq kits à maintenir à jour, cinq pages tarifaires à surveiller, cinq pages d'état à consulter, et une logique maison de bascule lorsque l'un se dégrade. Multipliez cela par le rythme d'apparition des nouveaux modèles et la maintenance d'intégration devient un coût d'ingénierie permanent. OpenRouter convertit ce coût récurrent en une dépendance unique. Savoir si l'échange en vaut la peine est la véritable question d'évaluation, traitée frontalement dans la section des limites.
La fonctionnalité la plus distinctive est la sélection automatique de modèle, et son mécanisme est assez inhabituel pour mériter une description précise. Le routeur attribue d'abord à chaque invite l'un d'environ trente types de tâches finement découpés — des catégories comme le débogage de code, la planification d'agent en plusieurs étapes, les questions de connaissance, les mathématiques ou le support client. La classification se fait en vol et, selon la documentation, sans exiger de conservation des invites.
La seconde étape est celle qui l'écarte du routage conventionnel. Plutôt que de s'appuyer sur un classement de qualité figé, le routeur observe ce sur quoi la communauté dépense réellement pour ce type de tâche, mesuré sur une fenêtre glissante de sept jours. L'entreprise compare cela à un indice de marché : lorsque l'usage se déplace vers un modèle récent plus performant en débogage, le routage suit automatiquement la dépense. Deux identifiants font tourner ce système, la voie stable openrouter/auto et la voie d'accès anticipé openrouter/auto-beta.
Choisir un modèle ne résout que la moitié du problème, car un même modèle est souvent servi par plusieurs fournisseurs aux prix, vitesses et fiabilités différents. Par défaut, les requêtes sont réparties entre les meilleurs fournisseurs afin de maximiser la disponibilité. Au-delà de ce défaut, le routage se configure largement via un objet provider dans le corps de la requête, exposant des champs tels que l'ordre des fournisseurs, l'autorisation de bascule, l'exigence de prise en charge de tous les paramètres, la politique de collecte de données, la restriction sans conservation, les listes d'autorisation et d'exclusion, le filtrage par niveau de quantification et un plafond de prix.
Pour les équipes techniques, le tri et les seuils comptent le plus. Vous pouvez trier les fournisseurs par prix, débit ou latence, définir un débit minimal ou une latence maximale souhaités avec des seuils par centile, ainsi qu'un prix maximal pour la requête. Une préférence vague du type « pas cher mais pas lent » devient ainsi un paramètre de requête explicite et applicable.
La fiabilité est souvent l'argument qui emporte la décision d'adoption. Le comportement documenté est sans ambiguïté : si un fournisseur renvoie une erreur, la plateforme bascule automatiquement vers le suivant. Cela se produit de manière transparente, ce qui signifie que votre application n'a pas besoin de sa propre logique de reprise et de réacheminement. Pour un système en production où la panne d'un fournisseur provoquerait sinon une défaillance visible par l'utilisateur, c'est la fonctionnalité qui justifie la dépendance.
La plateforme propose l'API brute pour un contrôle complet dans n'importe quel langage, des kits clients typés, et un kit destiné aux agents pour construire des systèmes avec appels d'outils, boucles et gestion d'état. Cette gradation est sensée : un script qui interroge le point d'accès avec curl n'a rien à installer ; une application typée gagne à utiliser le kit ; et un système agentique avec appels d'outils et gestion d'état reçoit une couche conçue pour cela plutôt qu'une orchestration bricolée.
La surface fonctionnelle dépasse largement le choix du modèle. La documentation couvre la mise en cache des réponses, la mise en cache des invites, l'appel d'outils, les sorties structurées, les transformations de messages, la diffusion en continu, le traitement par lots, les classificateurs personnalisés, les garde-fous, les niveaux de service, les préréglages et l'assurance contre les complétions vides. Côté équipe, on trouve des espaces de travail avec budgets, l'authentification unique, la correspondance de groupes SCIM et des analyses. C'est la différence entre un proxy amateur et quelque chose qu'une organisation peut standardiser.
L'usage principal est simple : vous développez un produit qui appelle un modèle de langage et ne voulez pas vous lier irréversiblement à un fournisseur. Intégrer via OpenRouter signifie que changer de modèle relève d'une modification de chaîne de caractères plutôt que d'une refonte. Quand un modèle meilleur ou moins cher paraît, vous l'évaluez sans devoir d'abord monter un projet d'intégration.
Des tâches différentes appellent des modèles différents, et payer le prix des modèles de pointe pour une simple classification est du gaspillage. Comme les tarifs sont répercutés tels quels, que les fournisseurs peuvent être triés par prix et qu'un plafond s'applique par requête, les équipes peuvent orienter les tâches bon marché vers des modèles bon marché et réserver les modèles coûteux au travail qui les exige, le tout dans une seule relation de facturation.
Pour les applications où les appels de modèle se trouvent sur un chemin critique visible par l'utilisateur, la bascule automatique entre fournisseurs transforme une dépendance dure en dépendance souple. Combinée aux préférences de débit et de latence, elle permet de tenir des objectifs de niveau de service sans construire une couche de routage en interne.
Les équipes qui comparent des modèles pour une tâche précise peuvent exécuter les mêmes invites sur de nombreux modèles via une seule interface. Les classements publics et les palmarès d'applications ajoutent un second signal : ce que d'autres développeurs utilisent réellement en production pour un travail comparable.
Les charges agentiques amplifient chaque faiblesse d'une configuration mono-fournisseur : elles émettent de nombreux appels, requièrent l'appel d'outils, et une défaillance en cours de route gâche toute la trajectoire. Le kit pour agents associé à la bascule automatique vise exactement cette forme de travail.
Pour les organisations régulées, la plateforme prend en charge un routage dans la région pour l'Union européenne et les États-Unis à destination des clients d'entreprise, aux côtés de la restriction aux points d'accès sans conservation et des contrôles de politique de données au niveau du fournisseur. Cette combinaison permet d'exprimer des exigences de conformité comme une configuration de requête plutôt que comme une négociation avec un fournisseur.
Fixez un prix maximal par requête. Le paramètre max_price est la protection la plus simple contre la sélection inattendue d'un modèle coûteux. Sur les chemins à routage automatique en particulier, il transforme un coût ouvert en coût borné.
Adaptez la stratégie de routage au chemin de code. Fixez les modèles là où la constance des sorties compte : une invite ajustée pour un modèle peut se comporter différemment sur un autre. Utilisez le routage automatique là où la tâche est générique et où l'adaptation à un marché mouvant vaut mieux que le déterminisme.
Ne restreignez pas trop votre liste de fournisseurs. La réduire à un seul fournisseur préféré reproduit le point unique de défaillance que vous cherchiez à fuir. Autorisez les bascules, sauf règle de conformité contraire.
Exprimez la politique de données dans le code, pas dans un document. Si votre charge doit éviter la conservation, définissez la restriction sans conservation et la politique de collecte sur la requête. Une contrainte configurée est applicable ; une intention écrite ne l'est pas.
Réservez les modèles gratuits à l'évaluation. La documentation est explicite : les modèles gratuits ont des limites de débit basses et ne conviennent généralement pas à la production. Ils relèvent de la commodité de test.
Vérifiez l'identifiant de greffon en configurant le routage automatique. Les réglages envoyés sous l'identifiant de l'autre voie sont acceptés mais silencieusement ignorés — un mode de défaillance qui ne produit aucune erreur pendant que vos restrictions de modèle et votre palier de coût ne font discrètement rien.
Attribuez votre application si vous cherchez de la visibilité. Les en-têtes d'attribution facultatifs placent votre application sur les classements publics, ce qui aide à la découverte si vous construisez un produit destiné au public.
Budgétez avant de monter en charge. Les budgets d'espace de travail et les analyses existent parce que la dépense en jetons croît de façon non linéaire avec l'usage. Configurez des limites avant un pic de trafic plutôt qu'après une facture.
Les développeurs d'applications qui intègrent des modèles de langage constituent le public central : quiconque devrait autrement écrire et maintenir des intégrations contre plusieurs API de modèles.
Les équipes qui optimisent le coût d'inférence profitent de la répercussion des tarifs combinée aux contrôles de routage, ce qui permet des arbitrages coût/qualité par requête plutôt qu'un compromis global unique.
Les ingénieurs responsables de la fiabilité en production obtiennent une bascule automatique entre fournisseurs, difficile et fastidieuse à bien construire en interne.
Les constructeurs d'agents sont servis par le kit dédié et par la robustesse qu'exigent les charges en plusieurs étapes.
Les entreprises soumises à des exigences de gouvernance sont couvertes par les espaces de travail, l'authentification unique, SCIM, le routage régional et les contrôles de politique de données.
Les chercheurs et évaluateurs en IA peuvent comparer de nombreux modèles via une interface unique, sans créer un compte chez chaque fournisseur.
À qui cela ne s'adresse pas : aux utilisateurs finaux cherchant un assistant conversationnel. Une interface de discussion existe sur le site, mais il s'agit d'infrastructure pour développeurs, et l'utiliser suppose d'écrire du code ou de configurer une application. Qui veut un produit grand public prêt à l'emploi devrait en utiliser un. Les équipes engagées auprès d'un fournisseur unique par contrat d'entreprise pourront aussi trouver que cette couche apporte peu.
OpenRouter se livre comme une API web ; la question de plateforme n'est donc pas celle du système d'exploitation mais de la surface d'intégration. L'API implémente la spécification OpenAI au point d'accès de complétion de conversation, ce qui signifie que tout langage doté d'un client HTTP peut l'utiliser, et que du code existant fonctionne généralement en changeant l'URL de base.
Les chemins d'intégration officiellement maintenus comprennent l'API brute, des kits clients typés et un kit pour agents. Au-delà, la documentation fournit des guides dédiés pour les principaux cadres de développement : côté orchestration on trouve LangChain et Mastra, côté frontal et applicatif Vercel AI SDK ainsi que TanStack AI, côté serveur typé PydanticAI, pour l'observabilité Langfuse, pour la voix en temps réel LiveKit, auxquels s'ajoutent des notes de migration depuis les kits d'OpenAI et d'Anthropic, ainsi que des modes de connexion pour des environnements de développement et d'automatisation comme Replit, Xcode et Zapier. C'est un signal utile : ce sont des intégrations documentées de première main, non des affirmations communautaires.
Les chiffres d'échelle publiés en page d'accueil font état de plus de deux cents billions de jetons mensuels, de plus de dix millions d'utilisateurs dans le monde, de plus de quatre-vingts fournisseurs et de plus de cinq cents modèles. Traitez-les comme déclarés par l'éditeur et comme un instantané : un commentaire d'investisseur d'une autre période cite des comptes sensiblement différents, ce qui indique que ces nombres bougent vite et devraient être vérifiés en direct plutôt que cités depuis un article, y compris celui-ci.
Les capacités destinées aux équipes et aux entreprises comprennent des espaces de travail avec budgets, l'authentification unique, la correspondance de groupes SCIM et, pour les clients d'entreprise, un routage dans la région en Union européenne et aux États-Unis.
Le modèle tarifaire est l'aspect le plus souvent mal compris d'OpenRouter, et il est assez inhabituel pour être énoncé avec précision.
Aucune marge n'est prise sur l'inférence. La documentation est explicite : les tarifs des fournisseurs de modèles sous-jacents sont répercutés sans aucune marge, vous payez donc le même taux qu'en traitant directement avec le fournisseur. Les coûts par jeton sont par conséquent ceux que facture le fournisseur. Comme ces taux varient énormément au sein d'un catalogue de centaines de modèles et évoluent quand les fournisseurs ajustent leurs propres prix, aucun chiffre par jeton n'est cité ici : consultez la page des modèles pour les tarifs en vigueur.
Le revenu provient de l'achat de crédits. Des frais s'appliquent à l'achat de crédits, non aux appels d'inférence. L'entreprise les décrit comme de faibles frais et répète que les tarifs des fournisseurs ne sont jamais majorés. Le pourcentage exact est présenté dynamiquement sur le site plutôt que dans le texte récupérable des pages : vérifiez donc le chiffre en vigueur au moment de payer.
Les crédits sont prépayés, avec des bornes définies. Les achats vont d'un minimum de cinq dollars à un maximum de vingt-cinq mille dollars par transaction. Les paiements par Stripe se règlent en dollars américains et ceux par Coinbase passent par un portefeuille de cryptomonnaie ; une recharge automatique peut compléter le solde lorsqu'il passe sous un seuil que vous définissez.
L'usage de vos propres clés obéit à sa propre économie. Si vous détenez des contrats directs avec des fournisseurs, cette option vous permet de les utiliser via la plateforme. Elle s'accompagne d'une dotation gratuite dépendant de l'offre, mesurée en coût d'inférence au tarif public et non en nombre de requêtes — distinction importante, puisque la dotation s'épuise plus vite avec des appels coûteux qu'avec de nombreux appels bon marché. Au-delà, des frais proportionnels sont déduits des crédits.
Un accès gratuit existe mais reste délibérément limité. Les nouveaux comptes reçoivent une petite dotation, et le catalogue comprend des modèles gratuits. Ceux-ci imposent de faibles plafonds de requêtes quotidiennes et la documentation indique qu'ils ne conviennent généralement pas à la production. Notons que la limite de débit des modèles gratuits augmente avec les crédits achetés : les comptes payants disposent donc de plafonds gratuits plus élevés.
Les remboursements sont étroits. Les crédits non utilisés peuvent être remboursés dans les vingt-quatre heures suivant la transaction ; passé ce délai, tout crédit inutilisé devient non remboursable. Les paiements en cryptomonnaie ne sont jamais remboursables. Achetez par tranches que vous comptez consommer.
Pas d'abonnement. La promesse d'absence d'abonnement affichée en page d'accueil vaut pour le produit standard : vous payez ce que vous consommez plutôt qu'une redevance récurrente, les arrangements d'entreprise étant traités séparément.
L'ensemble de comparaison dépend de la partie de la valeur que vous remplacez.
Résumé honnête : OpenRouter concourt sur l'étendue du catalogue, la finesse du routage et une structure tarifaire sans marge. Si vous utilisez un modèle d'un fournisseur pour toujours, le direct est plus simple. Si le choix du modèle est une décision continue, cette couche mérite sa place.
Vous ajoutez une dépendance sur votre chemin critique. Chaque appel d'inférence transite par un tiers. Cela achète une résilience face aux pannes d'un fournisseur donné, mais introduit la plateforme elle-même comme point de défaillance potentiel. Pour les applications où les appels de modèle portent la charge, cet arbitrage devrait être une décision d'architecture délibérée.
Un saut de latence est inévitable. Passer par un intermédiaire ajoute une surcharge réseau par rapport à un appel direct. L'entreprise travaille à la réduire et des contrôles de préférence existent, mais ce saut est réel et compte pour les boucles interactives serrées.
Les crédits sont prépayés et la fenêtre de remboursement est courte. Les crédits inutilisés deviennent non remboursables après vingt-quatre heures, les paiements en cryptomonnaie ne le sont jamais, et les conditions précisent que les crédits ne constituent pas une monnaie légale. Supprimer votre compte fait perdre les crédits restants.
Des échecs de configuration silencieux sont possibles. L'incompatibilité d'identifiant de greffon sur le routage automatique en est l'exemple le plus net : des réglages incorrects sont acceptés mais silencieusement ignorés, de sorte que restrictions de modèle et paliers de coût peuvent ne pas s'appliquer sans lever d'erreur. Vérifiez les effets plutôt que de les supposer acquis.
Les modèles gratuits ne sont pas un palier de production. Des limites de débit faibles et une indication explicite d'inadéquation à la production signifient que le catalogue gratuit sert à l'évaluation seulement.
Le traitement des données est configurable, donc de votre responsabilité. La valeur par défaut de la politique de collecte autorise les fournisseurs susceptibles de stocker des données. Le routage sans conservation et les restrictions existent, mais doivent être activés. Une équipe qui présume un traitement strict par défaut peut se tromper sur sa propre posture.
Les règles d'usage sont des clauses contractuelles applicables. Les conditions interdisent l'usage illégal, la fausse déclaration d'identité, le moissonnage, le contournement des dispositifs de sécurité et les tests adverses non autorisés sur les modèles. Les équipes de recherche prévoyant de tels tests devraient lire cette clause avant de commencer.
Les métriques déclarées varient selon la source. Nombres de modèles, de fournisseurs et volumes de jetons diffèrent entre la page d'accueil et des articles tiers de périodes différentes. Traitez tout chiffre précis comme daté.
Le comportement des modèles n'est pas uniforme. Une invite ajustée pour un modèle peut rendre différemment sur un autre : le routage automatique peut donc modifier les caractéristiques de sortie. Là où la constance importe, fixez le modèle.
C'est une infrastructure pour développeurs. Le produit est une API que votre application appelle, avec le routage, la facturation et l'observabilité autour. Une interface de discussion existe sur le site pour essayer des modèles et déboguer des invites, ce qui explique certains classements erronés, mais utiliser OpenRouter suppose d'écrire du code ou de configurer une application.
Non. La documentation indique que les tarifs des fournisseurs sont répercutés sans marge et que vous payez le même taux qu'en direct. Le revenu provient de frais prélevés à l'achat de crédits, non de l'inférence.
Un classificateur léger attribue à votre invite l'un d'environ trente types de tâches finement découpés, puis le routeur classe les modèles selon la dépense réelle de la communauté pour ce type de tâche sur une fenêtre glissante de sept jours. Il se comporte comme un indice de marché, se déplaçant vers les modèles qui gagnent en adoption réelle pour ce genre de travail.
Généralement non. L'API implémente la spécification OpenAI au point d'accès de complétion de conversation, si bien qu'une intégration existante fonctionne d'ordinaire après changement de l'URL de base et de la clé. Des kits clients typés et un kit pour agents sont disponibles si vous voulez plus que du HTTP brut.
La plateforme bascule automatiquement vers le fournisseur suivant, de façon transparente pour votre application. C'est l'argument central de fiabilité : votre code n'a pas besoin de sa propre logique de reprise et de réacheminement pour survivre à la panne d'un fournisseur.
Les nouveaux comptes reçoivent une petite dotation gratuite et le catalogue comprend des modèles gratuits. Ces modèles ont de faibles plafonds quotidiens et la documentation indique qu'ils ne conviennent généralement pas à la production. La limite des modèles gratuits augmente une fois des crédits achetés : l'offre gratuite se conçoit donc comme une voie d'évaluation.
Oui, et il s'agit d'une configuration par requête plutôt que d'un réglage de compte. Vous pouvez refuser les fournisseurs susceptibles de stocker des données, restreindre le routage aux seuls points d'accès sans conservation, et utiliser des listes d'autorisation ou d'exclusion pour des fournisseurs précis. Les clients d'entreprise peuvent en outre exiger un routage dans la région en Union européenne ou aux États-Unis.
Oui. Cette option s'accompagne d'une dotation gratuite dépendant de l'offre, mesurée en coût d'inférence au tarif public plutôt qu'en nombre de requêtes, l'usage au-delà entraînant des frais proportionnels déduits de vos crédits. Elle convient aux équipes disposant déjà de contrats négociés mais souhaitant un routage unifié.
Uniquement dans les vingt-quatre heures suivant la transaction, via le bouton de remboursement de la page des crédits. Passé ce délai, les crédits inutilisés ne sont plus remboursables, et les paiements en cryptomonnaie ne le sont jamais. Les crédits restants sont également perdus si vous supprimez votre compte.
Trois considérations dominent. Vous ajoutez un tiers sur le chemin critique de votre inférence. Vous acceptez un saut réseau supplémentaire et son coût en latence. Et vous vous engagez dans un modèle de crédits prépayés à fenêtre de remboursement étroite. Si vous êtes standardisé sur un fournisseur sous contrat d'entreprise, ou s'il vous faut une latence minimale absolue, l'appel direct peut mieux vous servir.
Comment utiliser OpenRouter
Étape 1 : créer un compte et charger des crédits
L'usage repose sur des crédits prépayés. Les nouveaux comptes reçoivent une petite dotation gratuite pour les essais, et les crédits s'achètent sur la plateforme avant tout usage en production.
Étape 2 : générer une clé d'API
Créez une clé depuis le tableau de bord. Comme une seule clé atteint tous les modèles du catalogue, sa gestion mérite le même soin que n'importe quel identifiant à privilèges élevés : les conditions vous rendent seul responsable de la confidentialité de vos identifiants de compte.
Étape 3 : pointer votre code existant vers le point d'accès
C'est généralement l'étape la plus courte. L'API implémente la spécification OpenAI, vous envoyez donc des requêtes HTTP standard vers le point d'accès de complétion de conversation ; dans la plupart des cas, modifier une URL de base et une clé dans une intégration existante suffit.
Étape 4 : choisir votre stratégie de routage
Décidez si vous nommez un modèle précis ou si vous déléguez au routeur automatique. Nommer un modèle apporte du déterminisme ; le routeur automatique apporte une adaptation au paysage mouvant des modèles. Beaucoup d'équipes font les deux : modèles fixés sur les chemins sensibles à la sortie, routage automatique pour le travail courant.
Étape 5 : configurer les préférences de fournisseur
Si vous avez des contraintes, exprimez-les explicitement plutôt que d'accepter les valeurs par défaut. Fixez des plafonds de prix pour maîtriser les coûts, des seuils de latence ou de débit pour les chemins visibles par l'utilisateur, et des restrictions de collecte de données ou de conservation lorsque la conformité l'exige. Ce sont des paramètres par requête, donc des chemins de code différents peuvent porter des politiques différentes.
Étape 6 : tester la bascule avant d'en dépendre
Vérifiez que le comportement de repli correspond à vos attentes pour votre configuration, surtout si vous avez restreint la liste des fournisseurs. Restreindre agressivement réduit le vivier disponible pour basculer, ce qui affaiblit discrètement le bénéfice de fiabilité pour lequel vous avez adopté la plateforme.
Étape 7 : surveiller la dépense et l'usage
Utilisez les analyses du tableau de bord pour suivre la consommation par modèle et par application. Comme les coûts par jeton varient de plusieurs ordres de grandeur au sein du catalogue, un changement de routage peut déplacer sensiblement la dépense : traitez la surveillance comme une partie de l'intégration et non comme un ajout tardif.