Tarification d’OpenRouter Fusion : taille du panel et coût des tokens

Sur la page d’un modèle OpenRouter, une requête Fusion peut sembler gratuite, puis coûter plusieurs fois plus cher qu’une complétion classique. La raison est simple : la tarification d’OpenRouter Fusion additionne plusieurs appels aux modèles sous-jacents, au lieu d’appliquer un tarif autonome par token. La taille du panel et le volume de tokens déterminent donc si cette vérification supplémentaire vaut vraiment son prix.

OpenRouter Fusion en une décision

OpenRouter Fusion coûte généralement plus cher qu’un appel unique à un modèle comparable. La documentation du Fusion Router d’OpenRouter décrit un panel par défaut de trois modèles, complété par un appel à un analyste, pour un coût d’environ 4 à 5 fois celui d’une complétion unique avec le même prompt.

Un panel économique peut se montrer plus intéressant qu’un modèle premium si la qualité obtenue réduit le travail de vérification. Mais Fusion reste un arbitrage entre coût et contrôle, pas une solution automatiquement moins chère.

L’unité de facturation est une chaîne d’appels, pas un token Fusion

La page API de Fusion d’OpenRouter présente Fusion comme un routeur et affiche un tarif nul pour les prompts et les complétions de l’alias du routeur. Cela signifie que Fusion n’a pas de tarif autonome distinct ; cela ne veut pas dire que l’inférence sous-jacente est gratuite.

Le fonctionnement documenté est le suivant :

1. Le prompt est envoyé à chacun des modèles sélectionnés dans le panel.
2. Les réponses du panel sont comparées par un modèle analyste ou juge.
3. Le modèle externe produit la réponse finale.

Pour établir votre budget, utilisez cette équation :

Coût Fusion = somme des coûts des modèles du panel
              + coût de l’analyste/juge
              + éventuel coût du modèle externe final indiqué par votre intégration

Le décompte exact dépend de la manière dont Fusion est appelé : via l’alias de modèle openrouter/fusion ou via l’outil serveur openrouter:fusion. Ne déduisez pas le montant final de la ligne $0 affichée par le routeur. Vérifiez la génération réelle ainsi que l’enregistrement correspondant dans OpenRouter Activity.

La documentation d’OpenRouter prend en charge 1 à 8 modèles d’analyse. Le panel par défaut en compte trois. Entre les configurations Quality, Budget et les réglages personnalisés, il n’existe donc pas de prix Fusion universel par million de tokens.

La taille du panel augmente linéairement la facture — jusqu’à ce que le juge s’en mêle

Si chaque modèle du panel reçoit le même prompt et génère un volume de sortie similaire, l’ajout d’un membre entraîne environ un appel supplémentaire. OpenRouter indique explicitement que le coût évolue linéairement avec la taille du panel.

Le simple nombre d’appels sous-estime toutefois le coût du juge, car son entrée grossit avec les réponses produites par le panel :

C(n) = n × Cp + Cj(n) + Co

Ici, n correspond au nombre de modèles du panel, Cp au coût moyen d’une réponse du panel, Cj(n) au coût du juge, entrée croissante comprise, et Co au coût de la réponse externe lorsqu’elle s’applique.

L’estimation de 4 à 5 fois le coût d’une complétion pour le panel par défaut de trois modèles constitue donc un meilleur repère budgétaire que l’affichage $0 du routeur. Le multiplicateur peut grimper si le juge est coûteux, si les sorties sont longues ou si le modèle externe ajoute une complétion payante.

Exemple chiffré avec des tarifs modifiables

Utilisez cette feuille de calcul avec les tarifs actuels des modèles sélectionnés. Les chiffres sont illustratifs et ne correspondent pas aux prix d’OpenRouter : supposons 10 000 tokens en entrée, 2 000 tokens en sortie par réponse du panel, 6 000 tokens d’entrée pour le juge et 1 000 tokens de sortie pour le juge.

Entrée du panel   = 10 000 × somme des tarifs d’entrée du panel
Sortie du panel   = 2 000 × somme des tarifs de sortie du panel
Entrée du juge    = 6 000 × tarif d’entrée du juge
Sortie du juge    = 1 000 × tarif de sortie du juge
Total Fusion      = entrée du panel + sortie du panel + entrée du juge + sortie du juge

Si la référence avec un seul modèle traite les mêmes 10 000 tokens en entrée et 2 000 tokens en sortie, comparez directement son coût total à celui de cette feuille de calcul. Avec un panel de trois modèles, le prompt est facturé trois fois et le juge lit ici un contexte distinct de 6 000 tokens. Adaptez ces hypothèses lorsque vos prompts ou vos réponses sont plus longs.

Avec une hypothèse simplifiée de coûts identiques, la progression liée au nombre d’appels est la suivante :

Il ne s’agit pas des tarifs d’OpenRouter, mais d’une illustration de l’impact du nombre de modèles avant même de tenir compte des différences de prix. Un juge coûteux peut dominer un panel économique ; à l’inverse, des modèles de pointe dans le panel peuvent coûter davantage que le juge.

L’usage des tokens modifie la comparaison de deux façons

L’usage des tokens pèse davantage sur Fusion que sur un appel simple : le prompt est traité plusieurs fois et le juge reçoit les réponses générées par le panel.

1. Les tokens d’entrée sont dupliqués dans le panel

Soit I le nombre de tokens du prompt et Pi le tarif d’entrée du modèle de panel i :

Coût d’entrée du panel = I × (P1 + P2 + ... + Pn)

Un prompt de 10 000 tokens envoyé à trois modèles du panel génère donc trois facturations d’entrée distinctes, potentiellement à trois tarifs différents.

2. Les tokens de sortie sont eux aussi multipliés

Si chaque modèle du panel produit O tokens en sortie, le panel génère environ n × O tokens. Les tokens de raisonnement facturés peuvent encore creuser l’écart par rapport à la longueur visible de la réponse.

Le juge doit ensuite lire ces sorties :

Entrée du juge ≈ prompt d’origine + n × sortie du panel + surcharge d’orchestration

Une réponse plus longue peut donc augmenter le coût de chaque réponse du panel, mais aussi celui du contexte transmis au juge.

Pour obtenir une estimation mensuelle utile :

Coût mensuel total ≈ requêtes × (entrée du panel + sortie du panel
                                      + entrée du juge + sortie du juge
                                      + réponse externe)

Utilisez les tarifs actuels correspondant aux identifiants précis des modèles de votre panel. « Budget » est le nom d’un preset, pas la garantie que son coût total sera inférieur à celui de tous les modèles individuels.

Budget, Quality ou modèle unique ?

Choisissez un seul modèle lorsque la rapidité, la reproductibilité et une facturation prévisible comptent davantage qu’une vérification indépendante. C’est généralement le bon choix pour le formatage, l’extraction, l’autocomplétion, la réécriture courante et de nombreuses requêtes de programmation ordinaires.

Choisissez Fusion lorsqu’une erreur peut coûter cher : recherche riche en sources, critique experte, due diligence ou décision reposant sur des éléments contradictoires. Commencez par le plus petit panel capable de répondre à la question. Trois modèles constituent le réglage par défaut documenté ; huit est un maximum, pas une recommandation.

La bonne comparaison est la suivante :

coût supplémentaire de Fusion
par rapport à
coût des corrections évitées + temps de vérification humaine économisé + exposition réduite aux erreurs

Dans une annonce distincte consacrée à un benchmark, OpenRouter rapporte une évaluation DRACO sur 100 tâches, avec notamment un résultat de 69,0 % pour une configuration Fusion de pointe et de 64,7 % pour un panel économique. Ces chiffres plaident en faveur d’un usage en recherche approfondie ; ils ne constituent ni un taux de conversion valable pour tous les prompts ni la preuve qu’un panel plus large est plus rentable.

Vérifiez le coût avant de passer à l’échelle

Considérez le premier déploiement de Fusion comme une phase de mesure. Suivez les éléments suivants :

1. Les identifiants des modèles du panel et du modèle juge.
2. L’utilisation des tokens d’entrée, de sortie et de raisonnement lorsqu’elle est exposée.
3. Les métadonnées du routeur confirmant que Fusion a bien été exécuté.
4. Le coût total et la latence.
5. La réduction éventuelle des corrections humaines sur la réponse finale.

La documentation de Fusion indique que les métadonnées de génération peuvent inclure "router": "openrouter/fusion". Le champ model standard identifie le modèle concret qui traite la requête ; il ne suffit pas à prouver que Fusion a été utilisé.

Un témoignage d’utilisateur illustre le risque lié à la configuration :

« this \"Fusion\" still calls Opus 4.8 as a judge. I see no way to disable it. » — @teortaxesTex on X

Il s’agit d’un témoignage utilisateur, pas d’une règle de tarification d’OpenRouter. Il montre pourquoi un panel peu coûteux ne garantit pas une exécution bon marché si le juge est cher ou si la configuration ne correspond pas à vos attentes.

En production, verrouillez les modèles du panel et le juge lorsque l’API le permet, définissez des limites budgétaires et faites de Fusion une voie d’escalade explicite plutôt qu’un choix appliqué à toutes les requêtes autonomes.

FAQ sur la tarification d’OpenRouter Fusion

Fusion coûte-t-il moins cher qu’un modèle unique ?

Généralement non, si on le compare à un modèle individuel de prix similaire. Il peut être plus économique qu’un modèle premium lorsqu’un panel économique offre une qualité suffisante, mais le résultat dépend des tarifs du panel, du coût du juge et du volume de tokens.

OpenRouter Fusion est-il gratuit ?

L’alias du routeur peut afficher $0 dans ses propres champs de prompt et de complétion. OpenRouter précise séparément que les complétions sous-jacentes du panel et du juge sont facturées. Une requête Fusion classique ne doit donc pas être considérée comme gratuite.

Combien d’appels effectue une requête Fusion ?

Le processus documenté utilise N appels aux modèles du panel, plus un appel à l’analyste. La réponse externe finale dépend de l’intégration. La configuration par défaut de trois modèles est décrite comme coûtant environ 4 à 5 fois une complétion comparable.

Un panel plus large offre-t-il toujours un meilleur rapport qualité-prix ?

Non. Ajouter des modèles peut améliorer la couverture, mais augmente aussi les coûts du panel, le volume d’entrée du juge, la latence et les erreurs corrélées. N’augmentez la taille du panel que si des tests sur un jeu de contrôle montrent que le gain de qualité compense réellement son coût.

Comment estimer le coût d’OpenRouter Fusion ?

Listez chaque appel aux modèles sous-jacents, multipliez les tarifs actuels d’entrée et de sortie par les volumes de tokens prévus, ajoutez l’entrée du juge qui contient les réponses du panel, puis vérifiez le résultat dans Activity après une requête réelle. Un calculateur tiers peut aider à explorer différents scénarios, mais les tarifs en direct d’OpenRouter et votre relevé Activity restent les références.

La recommandation pratique

Prenez un modèle unique comme référence. Faites passer un jeu de contrôle de 20 à 50 prompts dans cette configuration, puis dans un petit panel Fusion. Ne conservez Fusion que si la réduction des corrections factuelles, des éléments manqués ou des heures de vérification compense le coût supplémentaire des tokens du panel et du juge.

Pour la plupart des équipes, le déploiement le plus raisonnable est le suivant : un seul modèle pour le trafic courant, Fusion avec un petit panel pour les décisions incertaines ou coûteuses, et des panels plus larges uniquement lorsque le gain mesuré résiste à l’examen de la facture.