Le BYOK d'OpenRouter expliqué : plus économique, souvent plus rapide et en pleine évolution

Conçu pour la vitesse : latence d'environ 10 ms, même en cas de charge
Une méthode incroyablement rapide pour créer, suivre et déployer vos modèles !
- Gère plus de 350 RPS sur un seul processeur virtuel, aucun réglage n'est nécessaire
- Prêt pour la production avec un support complet pour les entreprises
Si vous avez lu que le BYOK d'OpenRouter est gratuit pour votre premier million de requêtes par mois, sachez qu'il s'agit d'un chiffre qu'OpenRouter a abandonné le 14 juillet 2026. Cette information figure encore sur certaines anciennes pages de documentation d'OpenRouter, ce qui explique pourquoi tant de guides la répètent encore.
Les conditions actuelles sont plus avantageuses pour la plupart des équipes, et le BYOK est le moyen le plus économique d'utiliser OpenRouter. Lors de nos tests avec Anthropic, il s'est également avéré plus rapide. En cas de défaillance d'une clé, le système bascule automatiquement sur votre compte OpenRouter, sauf si vous modifiez ce paramètre sur la clé et restreignez les fournisseurs pour la requête.
Qu'est-ce que le BYOK d'OpenRouter ?
Le BYOK (« Bring Your Own Key » ou « utilisez votre propre clé ») consiste à ajouter vos propres identifiants de fournisseur à OpenRouter. Les requêtes acheminées vers ce fournisseur utilisent votre clé, le fournisseur vous facture directement, et vos propres limites de débit et conditions contractuelles s'appliquent. OpenRouter continue de gérer le routage, la traduction et les analyses, et vos prompts transitent toujours par sa plateforme.
Les clés sont ajoutées par espace de travail, dans les paramètres BYOK de l'espace de travail ou via l'API de gestion. Au 5 octobre, 72 des 92 fournisseurs répertoriés par OpenRouter prennent en charge le BYOK, notamment Anthropic, OpenAI, Google Vertex et AI Studio, Amazon Bedrock, Azure, DeepSeek, Mistral et Groq. Bedrock accepte une clé API Bedrock ou des identifiants AWS, Vertex un fichier JSON de compte de service, et Azure un nom de ressource et une clé.
Coûts du BYOK d'OpenRouter
Avec les forfaits Standard et Business, les premiers 25 000 $ d'utilisation BYOK chaque mois ne font l'objet d'aucun frais OpenRouter. Pour le forfait Enterprise, l'allocation est personnalisée ; certains guides mentionnent encore 200 000 $, mais la FAQ et la page tarifaire d'OpenRouter indiquent désormais simplement « personnalisé ». Au-delà de l'allocation, OpenRouter facture 5 % du coût qu'aurait représenté le même modèle et le même fournisseur sur OpenRouter, montant déduit de vos crédits OpenRouter.
Comparez cela à l'achat de crédits, où vous payez le prix catalogue d'OpenRouter pour l'inférence, majoré de frais sur chaque achat : 5,5 % sur le forfait Standard avec un minimum de 0,80 $, ou 8 % sur le forfait Business.

Le BYOK est moins cher quel que soit le volume, et l'écart est plus important en dessous de l'allocation et avec le forfait Business. Trois détails modifient les calculs.
Premièrement, les frais BYOK sont prélevés sur les crédits OpenRouter, et l'achat de ces crédits entraîne des frais d'achat de 5,5 %. Par conséquent, au-delà de l'allocation, les frais réels représentent environ 5,3 % du dépassement plutôt que 5 %, et vous devez conserver un solde de crédits même si toute votre inférence s'exécute avec vos propres clés. Les chiffres BYOK du tableau incluent ce paramètre.
Deuxièmement, les frais sont calculés sur le prix catalogue d'OpenRouter, et non sur ce que vous payez à votre fournisseur. Si vous avez négocié une remise de 20 % avec Anthropic, une utilisation de 100 000 $ au prix catalogue vous coûte 80 000 $, et les frais de 3 956 $ représentent environ 5 % de votre facture réelle plutôt que 4 %.
Troisièmement, il est facile de perdre le fil des dépenses BYOK. Elles ne sont pas comptabilisées dans les budgets des garde-fous ou des espaces de travail, sauf si vous activez include_byok_in_budgets, de sorte qu'un budget peut sembler confortablement en dessous de son plafond alors que les dépenses liées au fournisseur augmentent. De plus, la page Activité estime les dépenses BYOK aux tarifs du marché, et non selon votre remise ; le tableau de bord d'OpenRouter, ses budgets et votre facture fournisseur peuvent donc afficher trois montants différents.
Le BYOK d'OpenRouter est-il plus rapide ?
Sur Anthropic, il l'a été lors de nos tests. Nous avons envoyé les mêmes prompts à Claude Haiku 4.5 directement, via OpenRouter avec des crédits, et via OpenRouter avec notre propre clé Anthropic. Les crédits ont ajouté environ 200 ms au premier jeton, tandis que notre propre clé a ajouté environ 120 ms. Après le premier jeton, notre clé a diffusé les données à la même vitesse qu'une connexion directe, alors que les crédits ont généré les réponses sensiblement plus lentement. Sur une réponse type de 290 jetons, cela a rendu notre propre clé environ 0,6 seconde plus rapide. La mesure complète et ses limites sont disponibles dans notre article sur Latence d'OpenRouter sur Anthropic.
Sur OpenAI, c'est l'inverse qui s'est produit. Les crédits ont atteint le premier jeton 23 à 50 ms plus rapidement que notre propre clé, et les deux ont été diffusés au même débit. La question de savoir si le BYOK est plus rapide dépend du fournisseur. Le compte qui traite votre requête influe sur la vitesse de manière invisible depuis l'extérieur.
Le BYOK modifie également les limites de débit appliquées. Avec les crédits, OpenRouter gère les limites de votre fournisseur ; avec votre propre clé, vous bénéficiez des limites de votre compte fournisseur, qui peuvent être supérieures ou inférieures. Notre article sur les limites de débit d'OpenRouter couvre le reste.
Où vont les requêtes en cas d'échec de votre clé
En cas d'échec de la clé, la requête doit tout de même être traitée.
Par défaut, OpenRouter tente d'utiliser votre clé en priorité. En cas d'échec ou de dépassement de la limite de débit, OpenRouter bascule sur sa propre capacité partagée pour ce fournisseur, facturée sur vos crédits. Chaque clé dispose d'un paramètre de basculement vers la capacité partagée avec trois niveaux : utiliser la capacité partagée (par défaut), ne jamais utiliser la capacité partagée pour les modèles associés à la clé, et ne jamais utiliser la capacité partagée pour aucun modèle de ce fournisseur.
Le niveau le plus strict empêche OpenRouter d'utiliser son propre compte Anthropic. Cela n'empêche pas OpenRouter d'envoyer la requête vers un autre fournisseur. Si votre clé Anthropic échoue et que vous demandez un modèle Claude, OpenRouter peut le servir via Bedrock ou Vertex en utilisant son propre compte et vos crédits. Le guide BYOK d'OpenRouter l'indique explicitement, et la solution proposée consiste à restreindre les fournisseurs pour la requête, par exemple avec provider.only.

Deux règles de routage supplémentaires déterminent la destination de la requête. Les clés sont réparties en deux sections : les clés prioritaires sont testées dans l'ordre avant les points de terminaison d'OpenRouter, et les clés de secours ne sont testées qu'après. Ainsi, une clé de « secours » dans la section de basculement est utilisée après le compte d'OpenRouter, et non avant. De plus, les clés BYOK prévalent sur votre ordre de fournisseur. Si vous envoyez order: ["amazon-bedrock", "google-vertex"] mais que vous ne possédez qu'une clé pour Vertex, Vertex sera testé en premier. Le guide d'OpenRouter précise qu'il n'existe actuellement aucun moyen de modifier ce comportement.
Par conséquent, si vous avez adopté le BYOK pour maintenir l'inférence sur un compte fournisseur sous contrat, définissez le niveau de basculement le plus strict sur la clé et restreignez les fournisseurs sur chaque requête. L'une ou l'autre mesure seule ne suffit pas.
BYOK et politiques de données
Votre propre clé ne modifie pas les points de terminaison autorisés par vos politiques de données. Si vous avez défini data_collection: "deny" ou imposé une rétention de données nulle, ces règles continuent de s'appliquer aux points de terminaison de votre clé.
Le BYOK permet d'informer OpenRouter de vos propres accords. Chaque clé dispose d'une section d'accord fournisseur où vous pouvez déclarer que votre compte n'applique aucune rétention de données et, pour les clés OpenAI et Azure, la région dans laquelle votre compte traite les données. Ces deux options sont utiles si vous avez négocié ces conditions directement. Il s'agit dans les deux cas de votre propre attestation : la documentation d'OpenRouter précise qu'elle ne les vérifie pas, les garde-fous restreignant les régions de données ne reconnaissent pas encore les déclarations de région, et aucun de ces paramètres n'est encore disponible dans l'API de gestion.
Concernant le stockage des clés, OpenRouter indique que les clés des fournisseurs sont « chiffrées de manière sécurisée ». Il ne documente pas le schéma de chiffrement, la prise en charge éventuelle de clés gérées par le client, ni la gestion de la rotation des clés.
Mise en pratique du BYOK
Le BYOK est configuré par espace de travail, sans possibilité de basculement par requête. Toute clé API dans un espace de travail auquel sont associées des clés de fournisseur passera par le BYOK, que ce soit l'intention de l'appelant ou non. Lorsque nous avons comparé les crédits au BYOK, il a fallu utiliser deux espaces de travail distincts.
Lors de nos tests en septembre, le tableau de bord n'indiquait pas quel mode de facturation était utilisé par une clé API donnée. La vérification fiable consiste à effectuer une requête unique demandant les métadonnées de routage :
import os, requests
r = requests.post(
"https://openrouter.ai/api/v1/chat/completions",
headers={"Authorization": f"Bearer {os.environ['OPENROUTER_API_KEY']}",
"X-OpenRouter-Experimental-Metadata": "enabled"},
json={"model": "openai/gpt-4o-mini",
"messages": [{"role": "user", "content": "hi"}],
"max_tokens": 5,
"provider": {"order": ["openai"], "allow_fallbacks": False}},
)
meta = r.json().get("openrouter_metadata") or {}
print("is_byok:", meta.get("is_byok"))Si le résultat affiche False pour une clé que vous pensiez utiliser via le BYOK, c'est que vous payez des crédits. L'en-tête étant marqué comme expérimental, vérifiez qu'il fonctionne toujours avant de baser vos développements dessus. Lorsque les requêtes BYOK échouent, les métadonnées brutes de la page Activité incluent provider_responses, qui affiche le code de statut de chaque fournisseur sollicité ; c'est le moyen le plus rapide de distinguer une clé révoquée d'une limitation de débit ou d'un problème de droits.
Ce qui change
La tarification du BYOK a été modifiée cet été, et OpenRouter a annoncé de nouveaux changements à venir.
- 14 juillet 2026 : la franchise gratuite a été réévaluée, passant d'un nombre de requêtes (1 million par mois en paiement à l'usage) à un montant en dollars basé sur le prix catalogue (25 000 $ par mois). Les frais de 5 % restent inchangés.
- En attente depuis juin 2025 : L'annonce officielle d'OpenRouter concernant sa structure tarifaire actuelle, mise à jour pour la dernière fois en juin 2026, indique que les frais de 5 % du BYOK "seront supprimés à l'avenir et remplacés par un abonnement mensuel fixe", dont le prix reste à définir.
- Septembre 2026 : le forfait Business en libre-service a porté les frais de crédit à 8 % pour les équipes nécessitant un routage régional, tout en conservant la même franchise BYOK, ce qui accroît l'avantage du BYOK pour ce forfait.
- Août 2026 : Stripe a conclu un accord pour acquérir OpenRouter. Début octobre, l'opération n'avait pas encore été annoncée comme finalisée, mais la future tarification sera définie par le nouveau propriétaire.
Modélisez vos coûts selon les conditions actuelles et réévaluez-les chaque trimestre. Si l'abonnement est mis en place, le seuil de rentabilité par rapport aux crédits évoluera, en particulier pour les équipes en dessous de la franchise de 25 000 $ qui ne paient actuellement rien à OpenRouter.
Quand le BYOK est-il avantageux ?
Le BYOK (Bring Your Own Key) est avantageux si vous disposez déjà de comptes auprès des fournisseurs que vous utilisez, ou si vous avez négocié des tarifs ou des engagements de dépenses que vous souhaitez exploiter. C'est également la solution la plus rapide lorsque la latence sur Claude est un facteur critique. Si vos conditions de conformité sont liées à votre contrat fournisseur, cette approche ne fonctionne que si vous restreignez également les fournisseurs pour chaque requête.
Les crédits sont plus adaptés si vous préférez une facture unique sans avoir à gérer de relations avec les fournisseurs — ce que couvrent les frais de crédit — ou si vous expérimentez avec des fournisseurs avec lesquels vous ne comptez pas signer de contrat. Ils sont également recommandés si vous ne souhaitez pas gérer vous-même les clés, leur rotation et les limites par fournisseur.
L'approche de TrueFoundry
La passerelle IA de TrueFoundry appelle les fournisseurs avec vos propres identifiants, car elle s'exécute dans votre VPC ou votre centre de données, sans aucun compte fournisseur partagé sous-jacent. En cas de défaillance d'une clé, le système ne bascule que vers ce que votre propre configuration de routage autorise. La passerelle donne accès à plus de 1 000 LLM via une API compatible OpenAI, ajoute environ 3 à 4 ms de latence et gère plus de 350 requêtes par seconde sur un seul vCPU.
Si vous restez sur OpenRouter, TrueFoundry peut se placer en amont en tant que fournisseur pour centraliser les budgets, les limites de débit et le contrôle d'accès au sein d'une infrastructure que vous gérez. Notre présentation du fonctionnement d'OpenRouter détaille les cas où cette configuration est pertinente.
Lectures complémentaires
- Alternatives à OpenRouter, une comparaison des options pour les équipes en production
- Modèles gratuits sur OpenRouter, sur ce qui est gratuit et ce que cela vous coûte en réalité
- Mise en cache des prompts sur OpenRouter, sur les cas où la mise en cache permet d'économiser de l'argent et ceux où elle coûte plus cher
- Qu'est-ce qu'une passerelle LLM ?, l'architecture générale
Conclusion
Le BYOK d'OpenRouter est le moyen le plus économique d'utiliser OpenRouter quel que soit le volume, et nos tests ont montré qu'il s'agissait de la solution la plus rapide pour Claude. Par défaut, une clé défaillante bascule sur la capacité d'OpenRouter, et la requête peut aboutir chez un autre fournisseur, sauf si vous restreignez les fournisseurs pour cette requête. Définissez le niveau de secours le plus strict, restreignez les fournisseurs sur la requête, activez le BYOK dans vos budgets et vérifiez à nouveau les conditions générales lors de l'arrivée de l'abonnement promis.
Pour appeler des fournisseurs avec vos propres clés sans compte partagé sous-jacent, découvrez comment la passerelle IA de TrueFoundry fonctionne avec vos propres clés fournisseur.
TrueFoundry AI Gateway offre une latence d'environ 3 à 4 ms, gère plus de 350 RPS sur 1 processeur virtuel, évolue horizontalement facilement et est prête pour la production, tandis que LiteLM souffre d'une latence élevée, peine à dépasser un RPS modéré, ne dispose pas d'une mise à l'échelle intégrée et convient parfaitement aux charges de travail légères ou aux prototypes.



Gouvernez, déployez et suivez l'IA dans votre propre infrastructure
Blogs récents
Questions fréquemment posées
Is OpenRouter BYOK free?
OpenRouter charges nothing for BYOK usage up to $25,000 a month at list price on the Standard and Business plans, and a custom amount on Enterprise. Above that it charges 5% of what the same usage would cost on OpenRouter, deducted from your credits. Your provider bills you separately for the inference itself.
Does BYOK make OpenRouter faster?
On Anthropic it did in our tests: our own key added about 120 ms to the first token against about 200 ms on credits, and then streamed at direct speed. On OpenAI, credits was slightly faster. Which route is faster depends on the provider and the account behind it.
What happens when my BYOK key hits a rate limit?
By default OpenRouter falls back to its own shared capacity for that provider, billed to your credits. Setting the key to never use shared capacity blocks that, but OpenRouter can still serve the request from a different provider unless you restrict providers on the request, for example with provider.only.
Puis-je déployer TrueFoundry dans mon propre VPC ou on-premise ?
Oui. TrueFoundry s'exécute dans votre VPC, on-premise, en environnement air-gapped ou en hybride, de sorte que les prompts et les réponses ne quittent jamais votre domaine, même lorsque vous routez vers de nombreux fournisseurs.









.png)
.png)
.png)
.png)
.png)





.png)



.png)





