Tarifs OpenRouter : coûts des requêtes, frais de dépôt et BYOK

Pour établir un budget précis avec OpenRouter, vous devez distinguer le coût des requêtes traitées des fonds que vous déposez sur le solde de votre compte. De plus, vous devez évaluer séparément les règles du BYOK (Bring Your Own Key) si vous connectez vos propres clés d’API de fournisseurs. Un simple tarif affiché « par million de tokens » ne reflète pas l’ensemble de ces composantes financières.

Tarification des modèles et recharge de crédits : deux lignes distinctes

Selon la FAQ officielle, les coûts des requêtes sont déduits de votre solde de crédits prépayés, avec des tarifs déterminés par le modèle sous-jacent et le fournisseur. OpenRouter indique répercuter les tarifs des fournisseurs sans marge sur l’inférence ; la commission de la plateforme s’applique lors de l’achat de crédits. Sur la page des tarifs au 14 septembre 2026, les frais indiqués pour l’offre Pay-as-you-go s’élèvent à 5.5%.

Avant d’effectuer tout paiement, comparez trois valeurs distinctes : le montant de crédits que vous allez recevoir, les frais affichés et le montant final débité sur votre moyen de paiement. Vérifiez dans le calcul du paiement en direct les éventuels frais minimaux par transaction, les taxes applicables ou les suppléments liés au mode de paiement. Le pourcentage affiché dans un tableau tarifaire ne remplace pas le montant total final lors du paiement.

Prenons un exemple théorique : si l’achat de 100 $ de crédits entraîne des frais de plateforme supplémentaires de 5.5%, votre paiement total s’élèvera à 105.50 $. Il s’agit d’une illustration arithmétique hors taxes, frais de conversion de devise et frais de traitement, et non d’une capture exacte du récapitulatif de commande. Après avoir consommé 20 $ de crédits, votre solde restant sera de 80 $ ; il ne faut pas imputer l’intégralité du paiement initial au coût de ces premières requêtes.

Comment estimer votre charge de travail réelle

Pour un scénario textuel classique sans mise en cache de prompts ni fonctionnalités payantes supplémentaires :

request_cost = input_tokens / 1000000 * input_price
             + output_tokens / 1000000 * output_price

Prenons un tarif réel de BetterToken pour glm-5.3 au sein du groupe GLM, vérifié le 14 septembre 2026 dans le catalogue des prix actuel. En dollars américains par million de tokens, le prix d’entrée est de 1.232 $ et le prix de sortie de 3.872 $. Pour 8 000 tokens d’entrée non mis en cache et 2 000 tokens de sortie, le calcul est le suivant :

input_cost = 8000 / 1000000 * 1.232 = $0.009856
output_cost = 2000 / 1000000 * 3.872 = $0.007744
total_cost = $0.0176
1000_requests = $17.60

BetterToken n’ajoute pas de commission de transaction distincte à ce total : pour ce volume, le coût reste de 0.0176 $ par requête, soit 17.60 $ pour mille requêtes identiques. Il n’est pas nécessaire de multiplier ce montant par 1.055 — les frais de dépôt d’OpenRouter ne s’appliquent pas à BetterToken. Les volumes de tokens de cet exemple sont indicatifs ; le tarif provient directement du catalogue actif et non d’un modèle hypothétique. Les tokens mis en cache et les appels d’outils supplémentaires ne sont pas inclus dans ce calcul. Il s’agit d’un exemple de calcul pour BetterToken, et non d’une comparaison directe avec le prix de GLM-5.3 sur OpenRouter.

Pour transformer ce calcul en un budget d’exploitation réaliste, mesurez la taille réelle de vos requêtes, y compris l’historique complet des conversations et les instructions système. Évaluez séparément les requêtes courtes et les traitements à contexte long. Pour les agents autonomes, comptabilisez chaque appel intermédiaire nécessaire avant l’acceptation du résultat final, au lieu de ne budgétiser que la réponse finale. Toute nouvelle tentative déclenchée par une réponse insatisfaisante doit également être enregistrée dans votre suivi des dépenses si elle a donné lieu à un appel d’API facturable.

La mise en cache de prompts, les entrées d’images, les tokens de raisonnement (reasoning) et les frais par requête peuvent modifier le calcul des coûts : vérifiez les unités de facturation précises sur la fiche du modèle. La consommation se vérifie via les journaux Activity. Pour comparer avec BetterToken, consultez sa page des tarifs ainsi que vos propres données d’utilisation dans Workspace, où le modèle, le nombre de tokens et les dépenses sont détaillés. Comparez toujours des charges de travail identiques et des unités de facturation identiques ; la seule présence de deux grilles tarifaires ne prouve pas à elle seule quelle option sera la plus avantageuse.

L’accès gratuit ne garantit pas un débit illimité

La page des tarifs indique une limite de 50 requêtes par jour pour le plan gratuit. Ce quota ne constitue pas une garantie de service uniforme pour tous les types de comptes ou pour les routes de secours payantes. La documentation sur les limites distingue les limites de dépenses des limites de fréquence de requêtes : une erreur HTTP 402 impose de vérifier le solde du compte et le plafond de la clé d’API, tandis qu’un code d’état HTTP 429 peut provenir soit de la plateforme OpenRouter, soit du fournisseur en amont.

Face à une erreur HTTP 429, examinez le corps de la réponse et l’en-tête Retry-After s’il est présent, puis appliquez un délai d’attente exponentiel entre les tentatives. N’écrivez pas de boucles de relance infinies. Si vos règles de routage basculent vers un modèle payant, intégrez le coût de ce modèle dans votre budget avant le déploiement. Si une route gratuite est utile pour tester la compatibilité, les flux en production nécessitent une stratégie opérationnelle claire en cas d’épuisement des limites ou d’erreurs de service.

BYOK : vérifiez les deux factures

Le BYOK (Bring Your Own Key) permet d’acheminer des requêtes via OpenRouter en utilisant votre propre clé d’API de fournisseur. Selon la page des tarifs au 14 septembre 2026, l’offre Pay-as-you-go comprend jusqu’à 25 000 $ d’inférence mensuelle au tarif catalogue sans frais de BYOK, après quoi une commission de plateforme de 5% s’applique. Ce montant représente un seuil financier d’exonération : il ne s’agit ni d’un quota de requêtes gratuites, ni de la prise en charge de la facture de votre fournisseur par OpenRouter.

La gestion des clés s’effectue dans l’interface BYOK de l’espace de travail. D’après la documentation BYOK, la distribution des requêtes suit une hiérarchie stricte : le trafic utilise en priorité les clés prioritaires (Prioritized keys), bascule vers les points de terminaison partagés d’OpenRouter (shared OpenRouter endpoints) si nécessaire, puis s’oriente vers les clés de secours (Fallback keys), sous réserve des filtres de modèles et des contraintes de routage configurés. Le basculement vers la capacité partagée consomme les crédits de votre solde OpenRouter. Par ailleurs, les budgets d’espace de travail et les limites de garde-fou (guardrail budgets) excluent par défaut les dépenses BYOK ; il est nécessaire d’activer explicitement le paramètre « Include BYOK spend » si vous souhaitez les intégrer.

Pour configurer et valider votre chaîne BYOK, suivez ces étapes :

1. Vérifiez les autorisations et les filtres : assurez-vous que la clé d’API du fournisseur dispose des autorisations requises sur les modèles et configurez les filtres de modèles correspondants dans OpenRouter.
2. Définissez la politique de priorité des clés : déterminez l’ordre de priorité d’utilisation des clés et autorisez ou non le basculement vers les points de terminaison partagés d’OpenRouter ou les Fallback keys.
3. Séparez l’allocation de vos budgets : fixez des limites de dépenses distinctes — directement auprès du fournisseur en amont (upstream) d’une part, et sur votre solde OpenRouter d’autre part pour couvrir la capacité de secours ou la commission de BYOK une fois le seuil de franchise dépassé.
4. Exécutez une requête de test isolée : envoyez un appel unique et délimité, ouvrez dans le journal Activity l’affichage des métadonnées brutes (View Raw Metadata), examinez le bloc provider_responses et vérifiez la concordance entre les données enregistrées et vos factures réelles. Ne présumez jamais que l’attribution automatisée des coûts correspond parfaitement aux factures réelles sans vérification directe.

Si une seule API directe répond à vos besoins opérationnels, comparez sa facture mensuelle au coût d’acheminement de la même charge de travail via OpenRouter. Si vous avez besoin de redondance multimodèle ou de routage dynamique, prenez en compte le confort architectural d’une facturation unifiée et de points de terminaison standardisés. Pour une première évaluation, un petit lot d’essais délimité suffit : le coût total par résultat accepté s’avère bien plus instructif que la simple comparaison de tarifs d’entrée bruts.