[!NOTE] TL;DR Le benchmark agents IA d'OpenRouter classe des exécutions sous contraintes, pas une intelligence universelle. Au 30 septembre 2026, les écarts de coût par tâche changent la lecture du podium. Je propose un filtre de fiabilité avant tout arbitrage économique sur tes propres traces.
La facture sous le podium
Le podium avait oublié sa facture, comme un prince au restaurant. Au 30 septembre 2026 à 11 h 25 UTC, le benchmark agents IA d'OpenRouter place Gemini 3.7 Flash à 80,6 % de réussite pour 0.077 USD par tâche. GLM 5 atteint 78,0 % pour 0.046 USD, avec une dispersion affichée de ±3,4 points. Le rang seul ne paie rien.
Voici ma transcription de six lignes du classement τ²-Bench Airline d'OpenRouter, relevées sur son dernier run daté du 30 septembre 2026 à 11 h 25 UTC. Chaque coût, durée et volume de sortie est une moyenne par tâche évaluée, non le tarif de l'API par token.
| Modèle | Réussite et écart-type | Coût/tâche | Temps/tâche | Tokens sortants/tâche | Run UTC |
|---|---|---|---|---|---|
| Gemini 3.7 Flash | 80,6 % ; non affiché | 0.077 USD | 2,0 min | 14,7k | 30/09/2026 11:25 |
| Nova Micro 1.0 | 78,7 % ±2,0 points | 1.28 USD | 1,7 min | 5,69k | 30/09/2026 11:25 |
| GLM 5 | 78,0 % ±3,4 points | 0.046 USD | 3,4 min | 9,39k | 30/09/2026 11:25 |
| Step 3.7 Flash | 77,3 % ; non affiché | 0.020 USD | 3,8 min | 10,9k | 30/09/2026 11:25 |
| DeepSeek V4.1 Flash | 75,7 % ±1,0 point | 0.018 USD | 4,0 min | 15,1k | 30/09/2026 11:25 |
| GLM 5.3 Flash | 75,0 % ±2,0 points | 0.006 USD | 2,4 min | 4,22k | 30/09/2026 11:25 |
Cette photographie ne choisit pas ton fournisseur. Elle élimine surtout la tentation de confondre un score affiché et une facture prévisible.
La question économique
Ma question principale était la suivante : quel agent conserve une réussite acceptable quand je mesure le coût d'une tâche entière, plutôt que son seul prix au token ? Le client achète une réservation correctement modifiée, pas un million de tokens élégants. Et une tâche refusée à tort coûte aussi du temps humain.
J'appelle FARE mon filtre de décision : fiabilité admissible, puis arbitrage du rendement économique. Ce n'est pas un score public supplémentaire. C'est une règle de sélection à éprouver sur ton trafic, avec un seuil de réussite métier défini avant la comparaison. L'article existant sur les budgets de tool calls et la latence des agents traite la borne d'exécution ; ici, je traite le choix économique entre candidats évalués.
La frontière et ses angles morts
Une frontière de Pareto ressemble à une carte avec deux coordonnées : coût d'une tâche en abscisse, réussite en ordonnée. Tu peux déplacer ton choix le long de son bord, mais aucun point extérieur ne doit coûter davantage tout en réussissant moins. OpenRouter trace cette frontière sur les résultats en routage par défaut lorsqu'il existe, sinon sur un fournisseur médian. Cette dernière nuance change l'objet comparé.
Sur les valeurs affichées le 30 septembre, Gemini 3.7 Flash associe 80,6 % à 0.077 USD, tandis que DeepSeek V4.1 Flash associe 75,7 % à 0.018 USD. Tu ne peux déduire le meilleur choix sans connaître le coût métier d'un échec. Je propose donc de fixer d'abord une réussite plancher sur tes cas de référence, puis de comparer les coûts des candidats qui la franchissent. Pas l'inverse.
Attention à la précision. Le ±3,4 points de GLM 5 décrit la dispersion entre runs représentatifs, pas un intervalle de confiance universel. Sa plage recouvre le 80,6 % nominal de Gemini 3.7 Flash, dont l'écart-type n'est pas affiché. Ces chiffres ne démontrent donc pas une supériorité statistique de Gemini sur GLM 5. Ils permettent de sélectionner des candidats à tester, non de proclamer un vainqueur.
Le cas Nova Micro 1.0 mérite un arrêt. OpenRouter affiche 78,7 % pour 1.28 USD par tâche, contre 80,6 % pour 0.077 USD chez Gemini 3.7 Flash. Ce point paraît dominé sur les moyennes publiées ; son coût élevé est une anomalie à vérifier côté fournisseur ou configuration. Je n'en invente pas la cause, et sa dispersion interdit de transformer la comparaison en certitude statistique.
Le mauvais compteur
Le tableau d'usage OpenRouter est arrêté au 29 septembre 2026. Sa série hebdomadaire attribue 23,4 mille milliards de tokens à Space Bunny Alpha, un modèle « stealth » non vérifiable par son seul nom, puis 22 mille milliards à DeepSeek V4.1 Flash. Le premier n'est pas mon candidat technique : je ne peux pas identifier de façon fiable ce qu'il désigne. Le second n'est pas automatiquement le meilleur agent.
OpenRouter compte prompts et sorties, agrégés par variante ; une variante gratuite figure séparément. Le classement exclut aussi les requêtes privées. Les différences de tokenisation et de verbosité faussent toute lecture en « qualité », comme le précise sa méthodologie. Un prix attractif, un lancement ou une boucle agentique bavarde peuvent expliquer du volume. Ce sont des mécanismes plausibles, pas des causes mesurées ici. Le panneau « trending » exige au moins un million de tokens sur la fenêtre courante et place d'abord les nouveaux modèles sans semaine précédente.
La section « Top Apps » donne une prise plus concrète, sans prouver une part de marché. Sur cette page arrêtée au 29 septembre, Hermes Agent totalise 2,03 mille milliards de tokens, Cline 1,04 mille milliard et Claude Code 1,03 mille milliard. Hermes est décrit comme un agent persistant ; les deux autres sont décrits comme des agents de code. Leurs volumes attestent du trafic de ces produits sur OpenRouter, pas du nombre de clients ni du coût de leurs sessions. La carte n'explicite pas sa fenêtre temporelle. Je refuse de lui en attribuer une.
Le modèle avec son fournisseur
Le benchmark Airline exécute des conversations simulées et note la concordance de l'état final de la base avec la référence, ainsi que les messages exigés. Un échec vaut zéro, même si l'agent a bien conversé. OpenRouter indique un minimum de 45 tâches notées par couple modèle-fournisseur et agrège les runs admissibles des 90 derniers jours. Il sert donc surtout à sonder l'exécution des appels d'outils sous politique métier, modèle plus fournisseur, pas une intelligence générale.
Je séparerais deux alertes dans FARE : la tâche incorrecte et l'appel d'outil mal formé. Sur ce même relevé du 30 septembre, OpenRouter affiche un taux d'erreur structurelle des appels d'outils de 3,9 % avant Auto Exacto et 3,3 % après, pour les modèles inscrits à ce routage. La mesure porte sur des requêtes contenant des appels invalides, pas sur les réservations réussies. Sans échantillons comparables publiés dans ce panneau, ce « avant/après » ne démontre pas à lui seul un effet causal pour ton application.
Dans un pipeline d'analyse documentaire que j'ai architecturé, j'ai séparé les sorties structurées des champs à comparer sur un corpus de référence. J'ai aussi instrumenté les étapes et les tentatives avec OpenTelemetry. Cette expérience m'a appris à conserver le fournisseur dans chaque trace : changer de modèle et changer d'endpoint dans la même expérience rend la régression illisible. Mais je n'ai pas mesuré les six modèles du tableau sur ce pipeline.
Le radar de recherche
Un autre indicateur interdit d'extrapoler. L'index des benchmarks OpenRouter date son dernier run Airline du 30 septembre 2026 et dénombre 135 modèles. Pour BrowseComp et DeepSearchQA, il ne montre que quatre modèles par test, avec un dernier run au 18 août 2026. Quatre modèles testés en recherche ne décrivent pas tout le marché des agents de recherche. Les scores de recherche évaluent en outre une configuration de moteur et de budget, pas le même travail qu'une réservation aérienne.
Le papier fondateur τ²-Bench distingue justement le domaine Airline des scénarios où l'utilisateur agit aussi avec ses propres outils. Cette différence de protocole empêche de transférer sans preuve un score Airline vers un service client réel, et encore moins vers ton agent de recherche. Le banc de test est un instrument. Ce n'est pas le terrain.
La nouveauté vérifiable n'est pas un nouveau champion universel. Dans son annonce du 10 septembre 2026, DeepSeek revendique pour V4.1 Flash une architecture plus économe en cache. C'est une affirmation du fournisseur ; le 0.018 USD par tâche du tableau est, lui, une mesure OpenRouter sur un protocole distinct. Je ne déduis pas de causalité entre les deux. Voilà le signal utile pour un CTO : il faut tester l'économie au niveau du workflow, pas valider un argument d'architecture à la lecture d'une annonce.
Limites et objections
Bien que le tableau rende visibles des écarts de coût, il reste une photo qui vieillit vite. L'agrégation des runs sur 90 jours mêle différentes dates d'exécution, et le dernier run n'est pas la date individuelle de chaque mesure. Le simulateur de client est lui-même un modèle ; OpenRouter reconnaît qu'il peut interrompre une conversation ou laisser tourner l'agent jusqu'à sa limite. Les refus correctement exécutés créent aussi un plancher de réussite. Tu ne dois donc ni comparer ces pourcentages directement à ceux d'un autre harness, ni les vendre comme une probabilité de succès en production.
Les panneaux « Top models by task » et « Cost per session » du classement ne livraient aucun chiffre exploitable dans ma lecture, même après un second chargement. Je n'en tire aucun coût de session. Les erreurs d'appel d'outil par modèle n'étaient pas exposées sous forme de lignes chiffrées dans ce relevé. Cette absence empêche une sélection finale fondée sur la seule page publique.
La décision observable
Voici le flux que je mettrais en place pour FARE. Il décrit une politique à tester, pas un produit dont je prétends publier aujourd'hui les résultats.
flowchart TD
A[Cas métier rejoués en CI] --> B{Réussite admissible ?}
B -- Non --> X[Écarter le candidat]
B -- Oui --> C{Coût par tâche sous plafond ?}
C -- Non --> Y[Comparer un autre candidat]
C -- Oui --> D[Tester le fournisseur et le fallback]
D --> E[Tracer réussite coût et latence en production]
E --> A
Je commencerais par des evals continues en CI sur des cas métier de référence, avec comparaison de l'état final et vérification des politiques. Puis je conserverais dans chaque trace le modèle, l'endpoint et le coût de la tâche. Un plafond par run et un fallback explicite protègent la dépense ; OpenTelemetry et Logfire rendent la décision auditable. Ce programme complète, sans le répéter, le travail de bornage des tool calls.
Si tu veux transformer ce radar en protocole de sélection sur tes propres tâches, examine mes offres d'architecture agentique ou contacte-moi pour définir l'évaluation. Je préfère un échec mesuré sur tes cas à une médaille de benchmark encadrée au mur.
Données de classement et de benchmark : OpenRouter, licence CC BY 4.0. Relevés d'usage au 29 septembre 2026 et de τ²-Bench Airline au 30 septembre 2026 à 11 h 25 UTC.
Le déplacement du critère
Plus généralement, le modèle gagnant n'est pas celui qui parle le plus ou occupe la première ligne. C'est celui dont tu peux défendre le taux de réussite et le coût sur ton propre terrain. Le podium peut garder sa médaille en carton.