OpenRouter BYOK : frais, basculement et rotation des clés (2026)

Votre clé OpenAI peut être valide, la requête peut aboutir, et pourtant votre solde OpenRouter peut diminuer. Avec BYOK, il n’existe pas un unique interrupteur de facturation : coût du fournisseur, frais de plateforme et capacité de fallback suivent chacun leur propre circuit. La règle actuelle a en outre remplacé l’ancien seuil d’un million de requêtes.

Identifier précisément le débit facturé

OpenRouter BYOK permet d’utiliser, pour une requête, un identifiant de fournisseur enregistré dans votre workspace, tout en conservant OpenRouter comme couche d’API et de routage. Cela sépare les flux financiers en trois catégories :

La première question à se poser n’est donc pas « Ai-je bien ajouté ma clé ? », mais « Quel fournisseur a réellement traité cette requête ? ». Une clé configurée peut échouer à cause de limites de débit, de fonds insuffisants chez le fournisseur, de permissions inadéquates ou d’une panne temporaire. Si le fallback est activé, OpenRouter peut faire aboutir la requête via un autre fournisseur et débiter votre solde OpenRouter pour ce parcours, comme l’explique son article d’assistance sur les frais BYOK.

Ce que BYOK change réellement dans OpenRouter

BYOK achemine le trafic éligible via l’identifiant de votre fournisseur, tout en laissant à OpenRouter le rôle de couche API et de routage. Dans sa documentation BYOK, OpenRouter indique que les identifiants sont chiffrés et utilisés pour les requêtes routées vers le fournisseur concerné.

BYOK ne rend pas l’inférence gratuite : le fournisseur continue de comptabiliser l’usage des modèles, et OpenRouter peut appliquer des frais de plateforme distincts après l’allocation applicable. Fournir votre propre clé ne contourne pas non plus les règles de confidentialité au niveau du workspace, du compte ou de la requête. S’il ne reste aucun endpoint éligible, la requête échoue même si l’identifiant est valide.

Les frais BYOK dépendent désormais de la valeur d’inférence, pas du nombre de requêtes

La page de tarification OpenRouter actuelle exprime l’allocation BYOK sans frais selon la valeur d’inférence au tarif catalogue, et non selon le volume de requêtes :

L’allocation est calculée sur ce que le même modèle chez le même fournisseur coûterait normalement sur OpenRouter, et pas nécessairement sur le montant négocié figurant sur votre facture fournisseur. Au-delà de ce seuil, les frais BYOK de 5% sont déduits des crédits OpenRouter ; le débit du fournisseur reste indépendant.

Trois lignes de coûts à ne pas mélanger

1. Coût d’inférence fournisseur : le fournisseur facture le compte associé à l’identifiant BYOK.
2. Frais de plateforme BYOK : après l’allocation du plan en cours, OpenRouter facture 5% en crédits OpenRouter.
3. Coût d’inférence du fallback : les crédits OpenRouter règlent un routage ayant utilisé une capacité fournisseur financée par OpenRouter au lieu du chemin BYOK prévu.

Les frais liés à l’achat de crédits constituent encore une catégorie distincte : la tarification OpenRouter mentionne des frais de plateforme Pay-as-you-go de 5.5%. Un débit lors d’une recharge ne prouve pas qu’une requête particulière est passée en fallback.

Pourquoi la réponse « 1M de requêtes » ressort encore dans les recherches

L’annonce d’OpenRouter d’octobre 2025 indiquait un million de requêtes BYOK mensuelles sans frais de plateforme, puis des frais de 5%. C’était la politique historique décrite dans l’annonce datée ; la page précise désormais que la tarification BYOK a changé en août 2026. Pour vos estimations, utilisez l’allocation fondée sur l’inférence au tarif catalogue de la page tarifaire actuelle, et notez la date de vérification.

Le fallback détermine si BYOK constitue une frontière stricte

Par défaut, OpenRouter cherche avant tout à faire réussir la requête. Le guide BYOK distingue les clés prioritaires, les endpoints partagés OpenRouter et les clés de fallback, qui interviennent à différents moments du routage :

• Les clés BYOK prioritaires sont essayées dans l’ordre configuré.
• En cas d’échec, la capacité partagée d’OpenRouter peut être tentée.
• Les clés BYOK marquées comme fallback sont essayées après les endpoints partagés.
• Plusieurs clés correspondant au même fournisseur peuvent être essayées successivement.

L’ordre des fournisseurs ajoute une subtilité : les endpoints BYOK correspondants sont tentés avant les endpoints partagés, même si ce fournisseur apparaît plus loin dans votre tableau order. Une requête peut donc employer une clé BYOK plus tôt que ne le laisserait penser votre règle générale d’ordre des fournisseurs.

Arbitrer entre fiabilité et certitude de facturation

L’option du tableau de bord Always use for this provider empêche OpenRouter d’utiliser son identifiant partagé pour ce même fournisseur. Ce n’est pas un commutateur global du type « ne jamais utiliser de crédits OpenRouter ». L’article d’assistance d’OpenRouter précise qu’une requête peut encore passer d’une clé BYOK Anthropic vers un autre fournisseur compatible, tel que Google Vertex, si le fallback inter-fournisseurs reste disponible.

Pour maîtriser strictement la facturation, limitez la requête elle-même :

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [
    { "role": "user", "content": "Summarize this document." }
  ],
  "provider": {
    "only": ["anthropic"]
  }
}

Avec provider.only, un échec chez Anthropic devient une erreur API au lieu d’un routage silencieux vers un autre fournisseur. C’est le bon choix pour les charges de travail réglementées, les accords de données propres à un fournisseur ou un reporting de coûts devant rattacher chaque requête à un compte amont précis. En revanche, ce n’est pas le meilleur défaut pour un produit interactif où la disponibilité importe davantage que l’identité stricte du fournisseur.

Un utilisateur de r/openrouter décrivait le même mécanisme :

« you can specify order/only providers in the request itself to force it to only use your BYOK ones. » — u/Randomdotmath, Reddit thread

Si le fallback fait partie de votre stratégie de fiabilité, prévoyez son coût. Dans le cas contraire, désactivez-le au niveau de la requête.

Avant d’incriminer les frais, vérifiez le routage dans Activity

La FAQ d’OpenRouter indique qu’Activity affiche l’historique d’usage et permet de le filtrer par modèle, fournisseur et clé API. Vérifiez notamment :

1. Fournisseur de service : correspond-il au fournisseur associé à votre identifiant BYOK ?
2. Modèle et endpoint : le routeur a-t-il choisi un autre endpoint compatible ?
3. Clé API applicative : quelle clé d’environnement ou de workspace a émis la requête ?
4. Déduction de crédits : s’agit-il de dépenses d’inférence, de frais BYOK ou d’une évolution de solde liée à une recharge ?

Si le fournisseur affiché dans Activity diffère de celui de votre BYOK, examinez d’abord le fallback avant de modifier l’identifiant. S’il correspond et que le volume approche l’allocation du plan, examinez les frais de plateforme BYOK. Vous éviterez ainsi de faire tourner une clé valide pour résoudre un problème de politique de routage.

Une architecture de clés adaptée à la production et à la rotation

Considérez la clé applicative OpenRouter et l’identifiant BYOK amont comme deux secrets distincts, avec des propriétaires différents :

Configurer et tester un identifiant BYOK

Suivez ce parcours rapide avant de diagnostiquer le trafic de production :

1. Ajoutez l’identifiant du fournisseur dans les paramètres BYOK du workspace, ou créez-le via l’API de gestion BYOK.
2. Donnez-lui un nom qui identifie le fournisseur, l’environnement et son usage.
3. Appliquez des filtres par modèle, clé API OpenRouter ou membre avant de partager l’identifiant du workspace.
4. Placez la clé dans la section prioritaire et n’ajoutez une clé de fallback que si son rôle de facturation et de continuité est explicite.
5. Envoyez une requête de test, vérifiez le fournisseur de service dans Activity, puis décidez si le fallback partagé doit rester actif.

Pour les fournisseurs cloud, les identifiants ne sont pas interchangeables :

Ces contraintes sont issues de la documentation BYOK spécifique aux fournisseurs d’OpenRouter. Un secret valide associé au mauvais type de ressource, à la mauvaise région, au mauvais déploiement ou à des permissions insuffisantes révèle un échec de configuration, pas une absence de prise en charge de BYOK.

Les paramètres BYOK d’OpenRouter prennent en charge des filtres sur les slugs de modèles, les hashes de clés API OpenRouter et les membres du workspace. Tous les filtres actifs doivent correspondre pour qu’un identifiant soit éligible, et la documentation autorise jusqu’à 100 entrées par filtre. Préférez des listes d’autorisation explicites ; pour les grandes équipes, répartissez les accès entre plusieurs workspaces plutôt que d’élargir sans cesse un même identifiant.

Faire tourner la clé applicative OpenRouter sans toucher aux clés fournisseur

Le cookbook de rotation des clés API d’OpenRouter explique que les identifiants fournisseurs BYOK sont associés au compte OpenRouter, et non à une clé applicative particulière. Sa séquence sans interruption est la suivante :

1. Créez une clé applicative OpenRouter de remplacement, avec un nom explicite et une limite adaptée.
2. Enregistrez-la dans votre gestionnaire de secrets et déployez-la dans chaque service, tâche et environnement utilisant l’ancienne clé.
3. Confirmez dans Activity que le trafic de production utilise la clé de remplacement.
4. Ne supprimez l’ancienne clé qu’une fois la migration terminée.

La documentation de l’API de gestion précise que les clés Management API sont des identifiants administratifs et ne peuvent pas appeler les endpoints de completion. La clé de remplacement doit être disponible avant la révocation de l’ancienne clé applicative.

Faire tourner séparément l’identifiant fournisseur

La rotation d’une clé fournisseur est une opération distincte. Respectez la politique d’identifiants du fournisseur et testez précisément le modèle, la région, les permissions et le quota utilisés par la charge de travail.

1. Créez chez le fournisseur l’identifiant de remplacement avec les permissions minimales nécessaires.
2. Ajoutez-le à la connexion BYOK OpenRouter sous un nom distinct et avec une priorité contrôlée.
3. Envoyez une requête de test et examinez Activity.
4. Passez l’identifiant de remplacement en position primaire, puis surveillez les erreurs et l’usage fournisseur.
5. Révoquez l’ancien identifiant chez le fournisseur après la période de chevauchement.

Cette séquence est une recommandation opérationnelle fondée sur le comportement de priorité documenté par OpenRouter ; les règles de révocation du fournisseur restent l’autorité de référence. L’API de création BYOK d’OpenRouter accepte un identifiant brut, mais précise qu’il est chiffré au repos et n’est pas renvoyé dans les réponses API ultérieures. Conservez l’identifiant source dans votre propre gestionnaire de secrets : OpenRouter n’est pas une copie de récupération.

Les cas où OpenRouter BYOK n’est pas le bon choix par défaut

L’accès direct au fournisseur est préférable lorsque les logs natifs d’un seul fournisseur, le comportement exact de ses endpoints ou ses outils comptent davantage qu’un routage unifié. BYOK convient mieux aux équipes utilisant plusieurs comptes fournisseurs, disposant déjà de crédits fournisseur ou de capacité engagée, et ayant besoin de contrôles au niveau du workspace.

FAQ OpenRouter BYOK

OpenRouter facture-t-il encore lorsque j’utilise ma propre clé ?

Oui. Le fournisseur peut facturer l’inférence via l’identifiant BYOK ; OpenRouter peut déduire des crédits des frais de plateforme BYOK de 5% après l’allocation du plan actuel ; et le fallback peut faire payer à vos crédits OpenRouter un routage chez un autre fournisseur.

« Always use for this provider » bloque-t-il tous les fallbacks ?

Non. Cette option empêche OpenRouter d’utiliser son propre identifiant partagé pour le fournisseur concerné, mais elle n’empêche pas une requête de basculer vers un autre fournisseur compatible. Utilisez provider.only lorsqu’un chemin inter-fournisseurs doit être impossible.

Comment une entreprise doit-elle gérer la sécurité et les budgets BYOK ?

OpenRouter indique que les identifiants sont chiffrés, que les clés fournisseur brutes ne sont pas renvoyées par l’API de gestion, et que les dépenses BYOK sont exclues par défaut des guardrails et budgets de workspace. La documentation BYOK indique d’activer Include BYOK spend ou include_byok_in_budgets lorsqu’un budget combiné est nécessaire. Les équipes enterprise doivent également appliquer le moindre privilège, séparer les workspaces, utiliser des filtres, conserver les secrets dans un gestionnaire dédié, faire tourner les clés et examiner Activity.

Le bon réglage dépend de l’échec que vous acceptez

Choisissez vos contrôles de routage et de budget selon l’exigence sur laquelle vous ne pouvez pas transiger : aboutissement de la requête, maîtrise du fournisseur ou visibilité des coûts.