OpenRouter pricing : Jev Router est-il vraiment gratuit ?
OpenRouter pricing affiche Jev Router à $0. Voici ce que ce tarif couvre, quels coûts restent à vérifier et comment auditer chaque requête routée.

OpenRouter pricing : Jev Router est-il gratuit ? La page en ligne d’OpenRouter affiche $0 pour les tokens de prompt et de complétion. Cela ne prouve pas pour autant qu’une session d’agent routée coûte $0 au total. L’endpoint managé choisit un autre modèle ainsi qu’un niveau de raisonnement : pour trancher côté budget, il faut donc rapprocher le usage.cost de la réponse de la fiche de génération correspondante.
Jev Router, l’endpoint typesafe/jev-router managé par OpenRouter, a été lancé le 25 septembre 2026. Il s’agit d’un endpoint de chat qui choisit le modèle chargé de répondre à chaque tour. Ce produit ne doit être confondu ni avec le modèle de décision Jev d’origine, ni avec le wrapper CLI open source au nom très proche.

OpenRouter pricing : Jev Router est-il vraiment gratuit ?
La réponse vérifiée est plus nuancée que ne le laisse penser le badge vert « free » : Jev Router est annoncé à $0 pour les tokens de prompt comme de complétion, mais le coût total du modèle sélectionné n’est pas documenté assez clairement pour affirmer que chaque session routée est gratuite.
La page en ligne de Jev Router a été vérifiée le 26 septembre 2026. Sa FAQ indique bien que le routeur est gratuit et que les tokens de prompt et de complétion ne sont pas facturés. La page mentionne aussi une fenêtre de contexte de 1,000,000 tokens et un endpoint unique qui adapte le modèle et le niveau de raisonnement à mesure que la conversation évolue.
Deux éléments du catalogue empêchent toutefois d’aller plus loin. À la même date, l’API Models publique d’OpenRouter renvoyait -1, et non un montant fixe ordinaire, pour le tarif des prompts et des complétions du routeur. Sa fiche d’endpoint ne renvoyait aucun endpoint fournisseur. Ces champs techniques ne prouvent pas qu’un montant est facturé, mais ils ne transforment pas non plus le $0 affiché sur la page en relevé détaillé d’une session.
L’environnement de publication utilisé pour cette vérification ne donnait accès ni à une clé API OpenRouter autorisée, ni à une session OpenRouter connectée. Aucune requête facturable n’a donc été envoyée, et aucun usage.cost ni relevé Activity observé ne vient étayer cette réponse. Pour établir un budget défendable, il faut considérer $0 comme le prix annoncé de l’endpoint, puis vérifier l’appel complet avant de promettre une inférence gratuite à un client ou à l’équipe finance.
Ce qui a réellement changé le 25 septembre
La nouveauté tient au rôle de Jev : auparavant composant permettant de construire un routeur, il devient la couche de décision d’un endpoint de chat managé.
Jev 1.13 est un modèle System One : il renvoie des décisions contraintes, pas du texte libre. L’application lui transmet un état et formule une demande typée de type Choice, Score ou question Noul oui/non. Le modèle peut décider « utiliser le niveau puissant », mais le code doit encore appeler ce niveau, conserver la conversation et comptabiliser les deux requêtes.
Le routeur managé réunit ce travail derrière typesafe/jev-router. D’après le thread de lancement d’OpenRouter, Jev évalue avant chaque tour la difficulté et le degré de précision du prompt. Il détermine si un modèle plus puissant ou davantage de raisonnement apporterait quelque chose, et vérifie si la tâche a changé. OpenRouter transmet ensuite le tour au modèle retenu et renvoie son texte.
Le projet open source gargpratyush/jev-router se confond particulièrement facilement avec le nouvel endpoint. Il lance le véritable CLI Claude Code ou Codex, demande une décision à Jev pour chaque nouveau tour, associe le résultat à des niveaux propres au compte et transmet l’authentification existante du CLI. Ce n’est pas le slug du modèle managé d’OpenRouter, et sa facturation suit un autre circuit.
Cette distinction change l’architecture. Le workflow Jev d’origine fournit une primitive de décision. Le routeur DIY ajoute une politique locale aux abonnements de coding. L’endpoint managé, lui, expose un seul appel API dont le texte est produit par un modèle qu’il a lui-même sélectionné.
Comment Jev Router gère-t-il une conversation ?
Jev Router cherche à éviter les changements de modèle motivés uniquement par l’apparence différente du message suivant. C’est important, car un basculement peut faire perdre le cache de conversation du fournisseur et obliger le nouveau modèle à relire tout l’historique.
D’après OpenRouter, le routeur conserve un modèle adapté pour le reste de la session, peut augmenter ou réduire l’effort de raisonnement sans changer de modèle, et ne bascule que lorsque le gain attendu justifie le coût du cache perdu. Il lit le texte de la conversation pour prendre cette décision. Le thread de lancement précise que les pièces jointes ne sont pas envoyées à Jev et que les requêtes utilisant zdr: true sont prises en charge.

Il ne s’agit donc pas d’un simple classement prompt par prompt. Un modèle peu coûteux peut rester en place pour une relance facile si préserver son cache vaut mieux que basculer. Un tour difficile peut recevoir davantage de raisonnement sans payer le coût de réinitialisation du contexte qu’imposerait le déplacement de toute la conversation. Et lorsque la tâche change réellement, le routeur peut changer de modèle.
Cette architecture introduit aussi une limite en production. Si la décision Jev expire ou renvoie une sortie invalide, OpenRouter indique que la requête échoue au lieu de se rabattre sur un autre routeur. Le projet DIY distinct adopte au contraire une stratégie fail-open et conserve le modèle actuel ou un modèle de secours. Choisir l’endpoint managé revient donc à ajouter une dépendance au chemin critique, pas simplement un optimiseur de prix.
Ce que couvre le tarif $0 — et ce qu’il ne prouve pas
Le tarif $0 couvre exactement ce qu’OpenRouter publie : le prix des prompts et des complétions sur la page Jev Router. Il n’explique pas ligne par ligne comment s’intègrent à ce montant un modèle payant sélectionné, les tokens de raisonnement, les lectures de cache, les outils et le financement des crédits.
Les règles générales de facturation d’OpenRouter indiquent qu’une requête ordinaire est facturée au tarif du modèle et du fournisseur sélectionnés. La nouvelle page Jev affirme que le routeur est gratuit. Aucune des deux sources ne précise explicitement si l’endpoint managé subventionne temporairement le modèle choisi, répercute cette inférence sur une ligne distincte ou applique une autre formule propre au lancement. Étendre ici la règle habituelle d’Auto Router serait une supposition ; déclarer gratuite toute inférence d’un modèle payant le serait tout autant.
La première source de vérité est la réponse. La documentation sur la comptabilisation de l’usage d’OpenRouter indique que chaque réponse inclut les informations relatives au prompt, à la complétion, au raisonnement, aux tokens en cache et au coût. usage.cost correspond au montant total débité du compte. Le champ model de la réponse identifie le modèle qui a répondu.
La fiche de génération constitue la deuxième source. Les Logs d’OpenRouter exposent le modèle, le fournisseur, le coût, le nombre de tokens, la latence, les remises liées au cache, le coût BYOK et les montants facturés pour la recherche web, la récupération de pages ou le traitement de fichiers. Le tableau de bord Activity agrège ensuite les dépenses, les requêtes, les types de tokens et le taux de réussite du cache, avec des filtres par modèle, fournisseur, clé, application ou utilisateur.
Chaque ligne contestée trouve ainsi sa preuve :
- Modèle sélectionné : comparer le
modelrenvoyé àusage.costet autotal_costde la génération. - Raisonnement : conserver
completion_tokens_details.reasoning_tokensainsi que l’explication du routage pour le tour concerné. - Réutilisation du cache : conserver
prompt_tokens_details.cached_tokens, puis rechercher dans le détail de la génération une éventuelle remise liée au cache. - Outils : les exclure du test de référence, puis consulter leurs lignes de génération distinctes avant toute activation en production.
- Frais sur les crédits : affecter séparément les frais d’achat. La FAQ actuelle d’OpenRouter indique 5.5%, avec un minimum de $0.80, pour les crédits financés par carte et 5% pour les cryptomonnaies. Il s’agit de frais de financement, pas de la preuve d’un supplément Jev Router.

Les chiffres : un routage gratuit ne rend pas la session gratuite
La ligne correspondant à la décision du routeur est déjà minuscule. L’enjeu économique réel consiste à savoir si Jev choisit un modèle adapté, préserve le cache utile et produit un résultat accepté.
Commençons par l’ancien parcours avec décision explicite. Jev 1.13 coûte $0.042 par million de tokens en entrée et $0 par million en sortie. En supposant 500 tokens d’entrée par décision de routage sur 100,000 tours, on obtient 50 millions de tokens d’entrée Jev, soit $2.10 pour la couche de décision. Le modèle génératif chargé de répondre à chaque tour reste facturé en plus.
Au tarif annoncé sur la page de l’endpoint managé, cette même ligne de routage tombe à $0. L’économie apparente atteint donc $2.10 pour 100,000 décisions dans ce scénario. C’est appréciable, mais insuffisant pour choisir le produit : un seul changement de modèle malvenu peut peser davantage que des milliers de décisions Jev.
Prenons une conversation qui compte déjà 20,000 tokens de prompt. Avec un tarif d’entrée illustratif de $2 par million de tokens pour le modèle sélectionné, faire relire cet historique par un nouveau modèle coûte $0.04 avant toute remise de cache et toute nouvelle sortie. Cinquante-trois basculements inutiles reviennent à $2.12, soit un peu plus que toute la couche de décision Jev 1.13 de l’exemple à 100,000 tours.
Voilà l’argument économique durable en faveur d’un routeur conscient de la session : préserver le bon cache peut compter davantage que rendre gratuit le classificateur de routage. Ce calcul décrit explicitement un scénario ; il n’affirme ni que Jev Router choisira un modèle à $2, ni qu’il évitera 53 basculements.
Les performances annoncées sont encourageantes, mais incomplètes. OpenRouter rapporte que Jev Router a résolu 237 tâches contre 130 sur 423, soit 82% de plus que son Auto Router, sur quatre benchmarks d’agents. L’entreprise annonce également un temps médian jusqu’au premier token inférieur à celui de tous les autres routeurs testés sur cinq benchmarks d’agents. Ce sont des résultats fournisseur, pas une reproduction indépendante.
Theo Browne a apporté un contrepoint utile dans un compte rendu de benchmark publié le 26 septembre. Il explique avoir dépensé $1,000, obtenu avec DeepSWE des performances à peu près équivalentes à celles de GPT-6 Astra en faible effort, payé légèrement plus et attendu presque cinq fois plus longtemps. Il s’agit d’un résultat de benchmark attribué, pas de la preuve de $1,000 de frais de routage ; la publication ne livre pas non plus assez de données de facturation par requête pour répondre à la question de coût posée ici.
Pour un acheteur, le coût par tâche acceptée reste l’indicateur décisif :
(selected-model cost + tools + allocated funding fee + retries + review time) / accepted tasks
Une ligne de routage à $0 peut améliorer ce numérateur. Elle ne fait pas disparaître le reste de l’équation.
Conséquences pour les développeurs, les opérations et les acheteurs
Les développeurs gagnent en simplicité d’intégration, mais ajoutent une dépendance exigeante. Un seul slug de modèle compatible OpenAI peut remplacer un classificateur maison, une table de règles, un appel de modèle et une partie de la logique de session. En contrepartie, le routeur précède chaque réponse. Son comportement fail-closed documenté impose de prévoir une réponse côté application en cas d’échec de Jev : retenter une fois, demander à l’utilisateur de réessayer ou appeler délibérément un modèle fixe selon sa propre politique.
Le journal minimal utile doit inclure l’ID de réponse, le slug demandé, le modèle sélectionné, le motif de routage, le niveau de raisonnement, les tokens de prompt, les tokens en cache, les tokens de complétion, les tokens de raisonnement, usage.cost, la latence et le résultat. Sans ces champs, un changement de modèle ressemble à une variation de prix aléatoire et une baisse de qualité à un bug de l’agent.
Les équipes d’exploitation doivent le piloter par session, pas à partir du prix affiché par token. Un copilote de support, un agent de recherche ou un workflow de coding peut réunir dans la même conversation des tours faciles, des tours difficiles et un changement de tâche. La valeur vient de la capacité à dépenser davantage uniquement lorsque le tour complexe le justifie, tout en conservant le cache dans le cas contraire. Il faut mesurer ensemble les tâches acceptées, les nouvelles tentatives, les corrections humaines et le total de la session.
Les acheteurs doivent séparer l’inférence, le routage et le financement dans leur budget. Le $0 annoncé pour l’endpoint appartient à la ligne de routage. Le total du modèle sélectionné rejoint la ligne d’usage une fois observé. La recherche, la récupération de pages, le traitement de fichiers et les autres outils gardent leurs propres lignes. Les 5.5% de frais de carte relèvent de l’achat de crédits, et non d’une majoration fictive par requête.
Pour comprendre la facture globale de la plateforme, l’analyse des prix d’OpenRouter détaille les crédits partagés, le BYOK et les frais de financement. Pour le workflow fondé sur le modèle de décision d’origine, le guide d’utilisation de Jev explique le routage typé des tickets et le tarif de $0.042/M de Jev 1.13.
Qui devrait tester maintenant, attendre ou ne rien changer ?
Il est pertinent d’agir dès maintenant si le workflow d’agent est délimité, réversible, si le budget d’évaluation peut rester sous $1 et si chaque génération est déjà journalisée. Une tâche de coding non critique, une boucle de recherche interne ou un assistant de support en shadow mode constitue un bon terrain d’évaluation. Le but n’est pas de démontrer que le routage paraît intelligent, mais de comparer son coût par tâche acceptée et sa latence à ceux d’un modèle fixe sur les mêmes prompts.
Mieux vaut attendre si une requête destinée aux clients ne peut tolérer une dépendance fail-closed supplémentaire, si l’équipe finance exige une règle de facturation signée avant toute mise en production d’un routage variable, ou si les prompts contiennent des données réglementées qui n’ont pas encore passé la revue de confidentialité. La prise en charge de la conservation nulle des données est utile, mais ne remplace pas la validation interne des flux de données.
Le changement vous concerne peu si un modèle fixe atteint déjà les objectifs de qualité et de latence, si la charge de travail est une décision typée étroite qui relève de Jev 1.13, ou si le choix consiste délibérément à router les abonnements Claude Code et Codex via le projet DIY local. Un routeur managé n’est pas automatiquement supérieur à un appel direct stable.
Si le contrôle déterministe du fournisseur compte davantage que la sélection adaptative, comparez les alternatives à OpenRouter pour le routage multimodèle avant de modifier le chemin critique.
Ce qui est exagéré dans la gratuité de Jev Router
L’exagération la plus manifeste consiste à croire qu’une fiche modèle à $0 rend gratuit tout l’écosystème de modèles. OpenRouter n’a pas publié assez de détails propres à la facturation de Jev pour étayer cette affirmation, et le catalogue technique public n’expose pas de route fixe conventionnelle.
L’excès inverse serait d’affirmer qu’un supplément caché de routage existe forcément. Aucun supplément n’a été documenté ni observé lors de cette vérification. En ajouter un aux prévisions reviendrait à inventer.
Les benchmarks doivent eux aussi être remis en perspective. Le gain de 82% de tâches revendiqué par OpenRouter est une comparaison du fournisseur avec son propre Auto Router. Le test DeepSWE à $1,000 de Theo porte sur l’expérience d’un seul praticien face à un seul réglage de modèle fixe. Aucun de ces résultats ne donne le coût par tâche acceptée pour votre agent, et aucun ne remplace un rapprochement rapide au niveau du compte.
Enfin, une fenêtre de contexte de 1,000,000 tokens ne rend pas économique une conversation d’un million de tokens. C’est le modèle choisi, le comportement du cache, le niveau de raisonnement et les changements de tâche qui déterminent l’efficacité d’une longue session. La limite de contexte mesure une capacité, pas un budget.
Le contrôle des coûts en quatre requêtes à lancer lundi
Quatre petites requêtes synthétiques en diront plus qu’une semaine supplémentaire à interpréter une page tarifaire. Désactivez les outils, n’utilisez aucune donnée privée, demandez des réponses courtes et arrêtez-vous si le cumul de usage.cost approche $1.
Envoyer une requête de référence en un tour
Appelez
typesafe/jev-routeravec « Return only the word READY. ». AjoutezX-OpenRouter-Metadata: enabled. Enregistrez le JSON complet, en particulierid,model,usageetopenrouter_metadata.Ouvrir une courte session de travail
Demandez : « In one sentence, explain why an idempotency key prevents duplicate charges. ». Enregistrez les mêmes champs. Vous créez ainsi un tour technique simple, sans outil ni donnée externe.
Poursuivre avec tout l’historique
Renvoyez le message précédent de l’utilisateur et la réponse de l’assistant, puis ajoutez : « Give one counterexample in one sentence. ». Notez si le modèle sélectionné reste le même, si le niveau de raisonnement change et si
cached_tokensapparaît.Changer de tâche et rapprocher la facture
Conservez l’historique de la conversation, puis demandez une fonction shell de quatre lignes qui vérifie si une URL renvoie HTTP 200. Additionnez les quatre valeurs
usage.cost. Récupérez chaque génération par son ID, puis comparez le modèle sélectionné, le nombre de tokens, les tokens de raisonnement, les champs de cache ettotal_costavec Logs ou Activity.
La première requête peut reprendre exactement cette structure :
curl https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-H "X-OpenRouter-Metadata: enabled" \
-d '{
"model": "typesafe/jev-router",
"messages": [
{"role": "user", "content": "Return only the word READY."}
]
}' | tee jev-router-response.jsonRécupérez ensuite les métadonnées de la génération correspondante à partir de l’ID de réponse :
GENERATION_ID=$(jq -r '.id' jev-router-response.json)
curl --get https://openrouter.ai/api/v1/generation \
--data-urlencode "id=$GENERATION_ID" \
-H "Authorization: Bearer $OPENROUTER_API_KEY"La règle de décision est mécanique :
- Si les quatre réponses indiquent
usage.cost: 0, si les quatre fiches de génération présentent un coût total nul et si la vue Activity de la même clé n’ajoute aucune dépense, vous avez observé une session synthétique sans coût sur ce compte et à cette date. - Si un relevé est non nul, utilisez son modèle sélectionné et la ventilation de son coût. Pour cette requête, l’endpoint n’est pas gratuit de bout en bout, quoi qu’indique le badge du catalogue.
- Si la réponse, la génération et Activity divergent, n’extrapolez pas. Conservez les ID et demandez au support OpenRouter quel relevé fait foi pour la facturation.
N’ajoutez aucun outil avant d’avoir rapproché le test de référence. Dès que la recherche, la récupération de pages ou le traitement de fichiers entre dans l’agent, répétez une requête contrôlée et traitez les lignes de génération correspondantes comme des coûts distincts. Ne les déduisez pas de la fiche modèle de Jev Router.
L’action à mener lundi consiste à exécuter ces quatre requêtes en parallèle de quatre appels de contrôle sur un modèle fixe, puis à comparer le coût de la session, la latence, les sorties acceptées et le taux d’échec. N’adoptez Jev Router que si la décision de routage améliore ce résultat global, et non parce qu’une ligne du catalogue contient deux zéros.
Recevez la prochaine évolution vérifiée du routage de modèles et ses conséquences budgétaires dans la newsletter.
- Dernière mise à jour
- 26 sept. 2026
- Catégorie
- Build







