Le cadre de sélection des modèles d’agents d’OpenRouter rejette le réflexe du score le plus élevé

OpenRouter a publié un cadre de sélection des modèles d’agents qui remet en cause une hypothèse familière en trois étapes : le modèle obtenant le meilleur score est rarement le gagnant par défaut. Son approche alternative commence par un seuil de qualité adapté à la tâche, teste trois niveaux de modèles sur 20 à 50 exemples représentatifs, puis sélectionne l’option la moins coûteuse qui franchit ce seuil de manière fiable.

Cela ressemble à une formule d’achat, mais cela modifie une décision produit plus profonde. Les équipes considèrent souvent le choix d’un modèle comme un problème de classement. OpenRouter souhaite qu’elles le traitent comme un problème de tests d’acceptation, où les exigences métier déterminent le score minimal avant qu’un modèle ne puisse concourir.

L’adversaire principal est la sélection guidée d’abord par les classements. Les benchmarks publics restent utiles pour établir une liste restreinte, mais ils ne peuvent pas représenter les prompts, outils, coûts d’échec, limites de latence et trafic de production propres à une entreprise. Le nouveau cadre de sélection pose donc une question plus ciblée : quel modèle répond aux exigences de cette tâche au coût mesuré le plus bas ?

Le cadre de sélection des modèles d’agents d’OpenRouter commence par un seuil de qualité

L’instruction la plus déterminante d’OpenRouter est de définir ce qui est « suffisamment bon » avant de comparer les modèles.

Le cadre traite le seuil de qualité comme une barrière, et non comme une préférence. Un modèle bon marché qui reste sous le seuil est disqualifié. Un modèle de pointe qui le dépasse largement reste éligible, mais son surplus de qualité ne justifie pas automatiquement son coût d’exploitation supérieur.

Cet ordre compte, car les équipes l’inversent fréquemment. Elles comparent les scores des benchmarks, sélectionnent un modèle impressionnant, puis se demandent seulement ensuite ce que leur application exige réellement. À ce stade, le choix du modèle a déjà influencé les prompts, l’infrastructure, les tests et les attentes des clients.

OpenRouter propose trois étapes. D’abord, l’équipe fixe un seuil de qualité pour une tâche définie. Ensuite, elle mesure le coût par point de qualité à l’aide d’exemples représentatifs et d’une même grille de notation. Enfin, elle choisit le modèle le moins cher qui dépasse le seuil avec une marge supérieure à la variation de score observée entre les exécutions.

Le seuil évolue selon les conséquences d’un échec. Un classificateur de demandes au support client peut transmettre les tickets incertains à une personne. Un agent de conformité peut créer une exposition juridique s’il manque une clause critique. Ces systèmes ne devraient pas hériter du même taux d’erreur acceptable.

La latence ajoute une autre barrière. Un modèle peut être abordable et précis, tout en échouant dans un flux de travail en direct parce qu’il répond trop lentement. OpenRouter présente donc la sélection des modèles comme une contrainte à trois dimensions : qualité, coût et vitesse.

Cette approche évite une comparaison trompeuse. Un modèle lent ne devient pas adapté simplement parce qu’il obtient un bon score. De même, un modèle peu coûteux ne devient pas économique lorsque ses erreurs entraînent des tentatives supplémentaires, des escalades ou des tâches inachevées.

Le cadre recommande aussi de commencer avec un modèle de niveau intermédiaire lorsque les exigences restent floues. Les équipes peuvent ensuite orienter les tâches simples vers le bas et les tâches difficiles vers le haut, selon les échecs mesurés. Cela crée un portefeuille de choix au niveau des tâches plutôt qu’une directive imposant un seul modèle.

L’événement n’est ni le lancement d’un nouveau modèle ni une victoire dans un benchmark. Il s’agit d’une tentative de normaliser la manière dont les acheteurs interprètent un marché des modèles de plus en plus encombré. OpenRouter soutient en pratique que l’unité de sélection devrait être une tâche de production, et non une famille de modèles.

Cette distinction devient plus importante pour les agents. Une réponse de chat implique souvent un seul appel de modèle. Un agent peut effectuer plusieurs appels, utiliser des outils, réviser son plan et réessayer des actions ayant échoué avant de renvoyer un résultat.

Chaque étape supplémentaire multiplie l’effet d’un choix par défaut coûteux. Elle peut aussi amplifier de petites différences de fiabilité. La comparaison correcte doit donc couvrir l’exécution complète de l’agent, et non une seule génération isolée.

La sélection guidée par les classements se heurte à la réalité de la production

Un classement public décrit une performance moyenne sur des benchmarks, tandis qu’un agent réussit ou échoue au sein d’un flux de travail spécifique.

Les classements condensent de nombreuses capacités en scores comparables. Cela les rend utiles pour la découverte, mais dangereux comme règles d’achat finales. Le modèle en tête d’un benchmark général de raisonnement pourrait ne pas surpasser une alternative moins chère pour le routage de tickets, l’extraction de champs ou la résolution de FAQ.

L’argument d’OpenRouter met sous pression les équipes qui utilisent un seul modèle de pointe à chaque étape. Il met également sous pression les fournisseurs de modèles dont le positionnement premium dépend d’un leadership général en matière de capacités. Dans le cadre d’un test spécifique à une tâche, l’excellence générale doit se traduire par une amélioration significative sur la charge de travail réelle de l’acheteur.

La pression est immédiate pour les agents à fort volume. Un flux de support peut classifier une demande, récupérer l’historique client, appeler un outil interne, générer une réponse et examiner sa propre réponse. Envoyer chaque étape au modèle le plus puissant disponible transforme une décision coûteuse en plusieurs décisions coûteuses.

L’économie de production dépend également des échecs. Le tarif par token le plus bas peut produire une tâche achevée coûteuse lorsqu’un modèle recommence fréquemment ou transmet trop de cas à une solution de repli plus puissante. Un modèle apparemment coûteux peut être économique lorsqu’il aboutit de manière fiable avec moins d’étapes.

C’est pourquoi OpenRouter mesure le coût par rapport au résultat noté. Le dénominateur pertinent n’est pas seulement le nombre de tokens ou de requêtes. C’est une performance acceptable sur la tâche que l’entreprise doit achever.

L’approche s’inscrit dans une évolution plus large de l’évaluation des agents. Les conseils d’Anthropic sur l’évaluation des agents distinguent une tâche d’un essai et recommandent des essais répétés, car les sorties des modèles varient. Ils séparent également la transcription du résultat final.

Cette séparation est importante dans les déploiements réels. Un agent peut affirmer avoir réservé un vol, mis à jour un dossier ou émis un remboursement. Le résultat significatif est de savoir si l’état correspondant du système a effectivement été modifié correctement.

Le cadre plus restreint d’OpenRouter ne remplace pas un dispositif d’évaluation complet. Il place plutôt une décision économique au-dessus de celui-ci. La grille de notation détermine si le modèle réussit, tandis que l’utilisation observée détermine le coût de ce résultat.

La méthode révèle également un enjeu organisationnel. La sélection des modèles relève souvent d’un responsable de l’ingénierie, tandis que la tolérance aux échecs relève du produit, du juridique, des opérations ou du support client. Un seuil de qualité contraint ces groupes à expliciter le compromis implicite.

Par exemple, « utiliser le meilleur modèle » semble prudent, mais laisse « meilleur » indéfini. Le meilleur peut signifier une précision maximale sur les benchmarks, le temps de réponse le plus court, le coût d’échec le plus faible ou l’examen de conformité le plus simple. Ces objectifs orientent souvent vers des modèles différents.

Un seuil défini transforme cette ambiguïté en dossier de décision. Les équipes peuvent indiquer ce qu’elles ont testé, ce qui comptait comme une réussite, quel modèle a réussi et quelle marge restait. Ce dossier devient utile lorsqu’un fournisseur publie une mise à jour.

Il rend également les désaccords plus productifs. Une partie prenante peut remettre en question les cas de test, la grille ou le seuil au lieu d’argumenter sur la réputation d’une marque. Le choix du modèle devient réfutable.

Cette méthode d’évaluation des modèles est particulièrement pertinente pour les équipes qui développent des flux de travail d’IA internes. Les ingénieurs ont besoin de preuves reproductibles lorsqu’un agent traite des documents d’entreprise, des tickets de support ou des dossiers opérationnels. Une base de connaissances d’ingénierie interrogeable peut aider à préserver les cas de test, les décisions et les schémas d’échec connus.

Le coût par point de qualité change ce qui définit un gagnant

Le cadre récompense le modèle le moins coûteux qui dépasse l’exigence, et non celui qui obtient le score absolu le plus élevé.

OpenRouter recommande de tester trois candidats : un modèle peu coûteux, un modèle de niveau intermédiaire et un modèle de pointe. Chaque candidat reçoit les mêmes 20 à 50 exemples et la même grille de notation.

Les exemples doivent provenir de la charge de travail que l’agent rencontrera réellement. Les équipes de support doivent utiliser des tickets représentatifs. Les agents documentaires doivent utiliser les fichiers, mises en page et cibles d’extraction présents en production. Les agents utilisant des outils doivent rencontrer des réponses d’outils réalistes et des conditions d’échec.

Les jeux de données publics ne suffisent pas à eux seuls à satisfaire cette exigence. Ils omettent souvent le vocabulaire spécifique à l’entreprise, les entrées mal formées, les exceptions de politique et les comportements clients inhabituels. Ils peuvent également encourager l’optimisation pour des questions qui n’apparaissent jamais dans le produit déployé.

Les tâches déterministes peuvent utiliser une évaluation par correspondance exacte. Un agent de routage, par exemple, peut devoir renvoyer un libellé de catégorie approuvé. Les tâches ouvertes exigent une grille distinguant les réponses acceptables, incomplètes, non étayées et dangereuses.

Un juge LLM peut mettre cette notation à l’échelle, mais il introduit un autre modèle dans la chaîne d’évaluation. Les évaluateurs en ligne de LangSmith montrent comment les équipes peuvent noter des traces de production et n’échantillonner que certaines exécutions. La revue humaine reste importante lorsque la grille dépend d’un jugement ou entraîne des conséquences sérieuses.

La cohérence des sorties aide à éviter des différences accidentelles de notation. OpenRouter renvoie aux sorties structurées afin que chaque candidat retourne le même schéma. Cela évite que des variations de formatage se fassent passer pour des différences de capacité.

Le cadre divise ensuite le coût normalisé de la charge de travail par le score de qualité. Cela produit un coût par point de qualité, une comparaison conçue pour fonctionner entre les candidats et les tailles de jeux de test.

Toutefois, le seuil de qualité vient d’abord. Supposons que le candidat le moins cher obtienne un résultat impressionnant en coût par point, mais n’atteigne pas le seuil requis. Il perd malgré tout. L’efficacité ne peut pas sauver un résultat inacceptable.

Parmi les candidats qui réussissent, le modèle le moins cher l’emporte. Un modèle de pointe peut fournir un score plus élevé tout en perdant, car les points supplémentaires ne répondent à aucune exigence définie. C’est le renversement central du cadre.

OpenRouter l’illustre avec un scénario de routage de support impliquant des options bon marché, intermédiaires et de pointe. Le niveau le plus bas manque le seuil établi sur les exemples, tandis que les deux candidats plus puissants réussissent. Le modèle intermédiaire l’emporte parce qu’il satisfait la tâche sans acheter une marge inutile.

Relever le seuil change la réponse. Une charge de travail plus exigeante peut éliminer le candidat de niveau intermédiaire et justifier le modèle de pointe. Le cadre ne prétend pas que les modèles bon marché sont universellement suffisants.

Il affirme que la valeur d’un modèle dépend de l’écart entre la performance mesurée et la performance requise par une tâche. Cela fait du seuil une donnée métier plutôt qu’une réflexion secondaire d’ingénierie.

La mesure des coûts évite également les estimations manuelles lorsque cela est possible. OpenRouter conseille de lire le montant facturé dans le champ usage.cost de la réponse. Son suivi de l’utilisation enregistre le montant associé à chaque requête.

Cela importe parce que les agents ne consomment pas toujours un contexte prévisible. La taille des résultats d’outils varie. Les nouvelles tentatives ajoutent des appels. Les longues conversations renvoient l’historique. Les paramètres de raisonnement, les itinéraires des fournisseurs, la mise en cache et les options de service peuvent également affecter la facture finale.

Mesurer l’exécution complète capture ces effets. Les équipes doivent agréger chaque appel nécessaire pour atteindre le résultat évalué, y compris les nouvelles tentatives et les requêtes de repli. Sinon, elles comparent les prix des modèles tout en ignorant le comportement de l’agent.

Le coût par point de qualité ne constitue toujours pas une unité scientifique universelle. Une amélioration d’un point près d’un seuil critique peut compter davantage que plusieurs points bien au-dessus de ce seuil. Le cadre traite ce problème en appliquant d’abord un filtre, puis en optimisant.

Ce processus en deux étapes est plus défendable que de regrouper toutes les préoccupations dans un unique score pondéré. Un score combiné peut masquer une grave défaillance de qualité derrière un faible coût. Le seuil rend visible le niveau minimal d’acceptabilité.

Les petits jeux de test rendent la marge de sécurité indispensable

Le point le plus faible de la proposition n’est pas sa logique, mais l’incertitude créée par un nombre limité d’exemples et la variabilité du comportement des modèles.

Un ensemble de 20 à 50 exemples est pratique pour une première comparaison. Il reste toutefois trop réduit pour représenter toutes les conditions de production. Les échecs rares, les entrées adversariales, le comportement en contexte long et les états inhabituels des outils peuvent demeurer invisibles.

OpenRouter répond en partie à ce problème par une marge. Les équipes devraient exécuter les candidats plusieurs fois, ou les tester sur un nouvel échantillon de trafic, puis consigner l’ampleur des variations de score. Le modèle sélectionné devrait dépasser le seuil de qualité d’une marge supérieure à cette variation observée.

Il s’agit d’une protection importante. Un modèle qui atteint le seuil une fois peut passer en dessous lors de l’exécution suivante. La seule variation d’échantillonnage peut modifier sensiblement un score lorsque chaque erreur représente une part importante d’un petit jeu de test.

Les essais répétés comptent également parce que la génération est non déterministe. Anthropic souligne que chaque tentative lors d’une tâche d’évaluation constitue un essai distinct. Plusieurs essais offrent une vision plus stable des performances d’un agent.

Cette exigence devient plus stricte pour les agents à plusieurs étapes. Une réponse de modèle peut varier, et cette variation peut modifier chaque appel d’outil ultérieur. Un plan légèrement différent peut produire une trajectoire, un coût, une latence et un état final différents.

Les équipes devraient donc éviter d’interpréter ce cadre comme une compétition ponctuelle. La première évaluation identifie un candidat prometteur. Le suivi en production détermine si ce candidat reste au-dessus du seuil.

La méthode de notation crée une autre incertitude. La correspondance exacte fonctionne bien lorsqu’il n’existe qu’une seule étiquette correcte. Elle fonctionne mal lorsque plusieurs réponses ou séquences d’actions peuvent mener au même résultat valide.

Un agent utilisant des outils peut emprunter un chemin inattendu tout en accomplissant correctement la tâche. À l’inverse, il peut produire une transcription convaincante tout en échouant à modifier le système externe. Les évaluateurs de résultat devraient primer lorsque l’environnement fournit un état vérifiable.

Les juges LLM nécessitent également un étalonnage. Ils peuvent préférer les réponses plus longues, les formulations familières ou les sorties qui ressemblent à leur propre style. Les équipes devraient comparer les scores des juges aux décisions humaines avant de laisser un évaluateur automatisé déterminer l’approvisionnement en modèles.

Le seuil de qualité lui-même peut être erroné. Une équipe produit peut choisir un seuil qui paraît raisonnable mais ne correspond ni au préjudice client ni à la charge opérationnelle. Les taux d’escalade, de plaintes, le temps de revue manuelle et les coûts de correction en aval offrent un ancrage plus solide.

La dérive du trafic ajoute un risque supplémentaire. Les exemples utilisés lors de la sélection peuvent représenter les clients, formats de documents ou politiques du mois dernier. Un nouveau segment de clientèle peut introduire des entrées qui mettent en échec le modèle choisi.

OpenRouter recommande explicitement de relancer la comparaison lorsque les modèles ou les prix évoluent. Le même principe devrait s’appliquer lorsque la charge de travail change. De nouveaux outils, prompts, schémas, langues et politiques peuvent invalider un résultat antérieur.

Le fournisseur du modèle peut aussi modifier son comportement sans changer le code de l’application. Les scores peuvent évoluer même lorsque l’équipe conserve le même identifiant de modèle. Une marge réduit cette exposition sans toutefois l’éliminer.

La latence mérite également des mesures répétées. Un temps de réponse moyen peut masquer un comportement lent dans la queue de distribution. Les agents au service de clients en direct devraient suivre la latence aux percentiles élevés et la durée complète des tâches, et pas seulement la moyenne des appels individuels.

La sécurité et la conformité imposent des contraintes que le coût par point ne peut pas pleinement représenter. Un modèle peut franchir un seuil de qualité moyen tout en produisant une divulgation inacceptable ou une action non autorisée. Certains échecs nécessitent des contrôles stricts plutôt qu’un score agrégé.

Les équipes devraient donc considérer le cadre de modèles d’agents d’OpenRouter comme une couche de décision au sein d’un système d’évaluation plus large. Il ne prouve pas qu’un modèle est sûr, conforme ou fiable pour chaque entrée. Il organise le choix économique une fois que ces exigences sont devenues mesurables.

Le choix statique de modèle et le routage dynamique convergent

Le cadre privilégie un gagnant fixe par tâche, tandis que l’orientation plus large du produit OpenRouter vise à acheminer différentes requêtes vers différents modèles.

Un choix fixe fonctionne lorsque la tâche est étroite et stable. La classification de tickets, l’extraction structurée et l’escalade fondée sur des politiques peuvent souvent utiliser un seul modèle jusqu’à ce que le suivi détecte une dérive.

Les charges de travail mixtes créent un problème différent. Un seul agent peut recevoir des résumés simples, des questions de recherche difficiles, des demandes de code et des tâches de planification pilotées par des outils. Un seul seuil de qualité ne peut pas décrire tous ces travaux.

Le routage automatique d’OpenRouter classe les prompts dans environ 30 types de tâches. Il classe les modèles selon des tendances de dépenses agrégées sur une fenêtre glissante de sept jours, puis applique une tranche de coût sélectionnée et d’autres restrictions.

Ce système et le nouveau cadre résolvent des problèmes connexes à des niveaux différents. Le cadre utilise les exemples d’une entreprise pour choisir un modèle pour une tâche connue. Le routeur utilise le comportement du marché et la classification des prompts pour faire un choix par requête.

Cette tension est utile. Un routeur éclairé par le marché offre commodité et adaptation continue. Une évaluation privée offre fidélité à la tâche et contrôle organisationnel.

Aucun ne domine automatiquement l’autre. Les dépenses agrégées peuvent révéler quels modèles les praticiens jugent fiables, mais la popularité ne prouve pas les performances pour une application donnée. Un petit test interne peut correspondre étroitement à l’application, mais il peut devenir obsolète ou passer à côté de nouveaux candidats.

Un déploiement mature peut les combiner. Les équipes peuvent définir des seuils propres aux tâches, tester des niveaux de candidats et acheminer les cas incertains ou difficiles vers un niveau supérieur. Les requêtes simples restent confiées au modèle le moins cher qui les traite de manière fiable.

Les recommandations distinctes d’OpenRouter sur l’escalade fondée sur la confiance suivent ce schéma. Un modèle moins coûteux traite le trafic normal, tandis que les requêtes sous un seuil de confiance calibré déclenchent un autre appel. Cela peut réduire le coût moyen sans accepter les sorties les plus faibles.

Cependant, le routage crée ses propres dépenses. Le classificateur consomme du temps et des ressources de calcul. Les requêtes escaladées impliquent plusieurs appels. Les différences entre modèles peuvent affecter le ton, l’utilisation des outils, les schémas et la continuité de la conversation.

Le routage dynamique complique aussi le débogage. Lorsqu’un échec se produit, l’équipe doit identifier le modèle sélectionné, le fournisseur, la classification du prompt, la trace des outils et le chemin de repli. Un modèle fixe fournit une base opérationnelle plus simple.

L’architecture la plus défendable peut donc évoluer par étapes. D’abord, établir un modèle fixe mesuré pour chaque tâche stable. Ensuite, recueillir les échecs et les cas ambigus. Enfin, introduire l’escalade là où les données la justifient.

Cette approche préserve le principe central du cadre. Le routage ne devrait pas devenir une autre manière d’éviter de définir une qualité acceptable. Chaque branche nécessite toujours des critères de réussite et un suivi.

La tendance générale du secteur va vers des portefeuilles de modèles. Les modèles de pointe généralistes restent importants pour les travaux difficiles, mais des modèles spécialisés moins chers peuvent absorber les étapes routinières à fort volume. L’agent devient un orchestrateur de capacités plutôt qu’une simple interface autour d’un seul modèle.

Cette transition met les fournisseurs sous pression pour justifier les modèles premium au niveau de la tâche. Elle confère aussi davantage de responsabilités aux équipes applicatives. Elles doivent assumer les données d’évaluation, la politique de routage et l’analyse des échecs plutôt que de déléguer leur jugement à un classement.

Trois signaux mettront à l’épreuve l’argument d’OpenRouter

Le cadre n’aura d’importance que si les équipes peuvent reproduire ses économies sans faire passer des échecs cachés en production.

Le premier signal sera de voir si les développeurs publient des comparaisons au niveau des tâches fondées sur du trafic réel. Les graphiques de benchmarks généraux ne valideront pas l’affirmation d’OpenRouter. Des évaluations répétées montrant des résultats similaires pour des agents de support, d’extraction, de code ou de recherche la renforceraient.

Les rapports les plus convaincants incluront les coûts d’exécution complets, et non des estimations par appel. Ils devraient comptabiliser l’utilisation des outils, les nouvelles tentatives, les replis et l’escalade humaine. Ils devraient également divulguer le seuil et la variation observée d’une exécution à l’autre.

Si ces études montrent que les modèles de niveau intermédiaire franchissent de façon répétée des seuils de qualité étroits, l’approvisionnement fondé d’abord sur les classements s’affaiblira. Si les modèles de pointe continuent de l’emporter après des tests de flux de travail complets, le cadre restera utile en documentant pourquoi le surcoût est nécessaire.

Le deuxième signal est la rapidité avec laquelle le suivi en production modifie le choix initial. Les équipes devraient surveiller la dérive des scores, la fréquence des escalades, la latence et les résultats commerciaux après le déploiement. Un modèle qui réussit un petit test mais échoue face à un trafic diversifié révélerait les limites d’échantillonnage du cadre.

Des performances stables soutiendraient la règle de marge proposée par OpenRouter. Des revirements fréquents indiqueraient que les équipes ont besoin de jeux de données plus vastes, d’évaluateurs plus robustes ou d’une évaluation en ligne plus agressive avant de changer de modèle.

Le troisième signal est l’adoption d’un routage hybride. La thèse d’OpenRouter se renforce lorsque les équipes utilisent des modèles peu coûteux pour le travail routinier et réservent la capacité de pointe aux cas incertains. Elle s’affaiblit lorsque les frais de routage, les comportements incohérents ou les coûts de débogage effacent l’avantage attendu.

Les acheteurs devraient aussi surveiller la réaction des fournisseurs. Les fournisseurs de modèles peuvent introduire des variantes plus petites, de meilleures sorties structurées, une inférence plus rapide ou des outils d’évaluation destinés aux entreprises. Ces changements pourraient déplacer la frontière coût-qualité sans modifier le cadre lui-même.

La contribution durable n’est pas un modèle gagnant particulier. Les catalogues de modèles changent trop vite pour qu’une telle conclusion perdure. La contribution est une règle de décision reproductible qui peut être appliquée à nouveau chaque fois que le marché évolue.

Pour les développeurs, l’action immédiate est simple. Choisissez une tâche de production, définissez un seuil fondé sur les résultats et rassemblez des exemples représentatifs. Testez des candidats issus de niveaux de capacité distincts avec le même prompt, les mêmes outils, le même schéma de sortie et le même évaluateur.

Répétez ensuite l’exécution. Mesurez le coût total de la tâche et l’évolution des scores, et pas uniquement le meilleur résultat. Ne conservez le modèle moins cher que lorsque sa marge résiste à cette répétition.

Pour les acheteurs en entreprise, le cadre offre une meilleure question à poser aux fournisseurs et aux équipes internes. Demandez quelles données sur la charge de travail justifient un choix de modèle, quels échecs l’évaluation détecte et à quelle fréquence la décision est réexaminée.

Pour les travailleurs du savoir, la conséquence est moins visible mais tout aussi importante. Une meilleure sélection de modèles peut rendre les fonctionnalités d’IA plus rapides et plus économiques sans réduire automatiquement la qualité. Une mauvaise sélection peut produire le résultat inverse tout en se cachant derrière un nom de modèle prestigieux.

Le cadre de modèles d’agents d’OpenRouter remplace finalement un raccourci rassurant par une discipline opérationnelle. Le score le plus élevé ne met plus fin à la discussion. Le modèle gagnant doit franchir un seuil pertinent, résister aux variations normales et justifier chaque unité de coût supplémentaire.

Quelle tâche d’agent est suffisamment coûteuse, fréquente ou risquée pour être évaluée en premier ? Préservez ses exemples réels, définissez ce que signifie la réussite et faites en sorte que la prochaine décision de modèle réponde à ces données.