OpenRouter publie des benchmarks live pour comparer moteurs de recherche, modèles et profondeur de requête dans vos agents

Le budget de recherche comme premier levier de qualité

Quand on câble un agent LLM avec de la recherche web, quatre paramètres entrent en jeu : le modèle, le moteur de recherche, la méthode (recherche en amont ou outil à la discrétion du modèle) et le nombre de tours autorisés. OpenRouter a systématisé la comparaison de ces combinaisons sur quatre suites de tests — BrowseComp (fact-finding difficile), DeepSearchQA (questions multi-hop), WideSearch (collecte large) et HLE (questions d'examen expert) — et publie les résultats sous forme de leaderboards live.

Le constat le plus net : augmenter le budget de recherche à partir d'un seul tour améliore la qualité plus que tout autre changement possible. Sur BrowseComp avec Perplexity, les chiffres parlent d'eux-mêmes :

Passer de 1 à 25 tours double environ le score pour un surcoût de seulement 2,5 à 7 fois par question. OpenRouter note que l'augmentation de la profondeur de recherche est le moyen le moins coûteux d'améliorer la qualité qu'ils aient trouvé.

Autre observation contre-intuitive : plus de tours ne ralentit pas systématiquement la réponse. Sur les configurations testées, le modèle Luna a paradoxalement affiché des temps de réponse plus courts avec un budget élargi : 111 secondes par question avec 25 tours contre 140 secondes avec 1 seul tour. Ce phénomène s'explique par la stratégie des modèles OpenAILaboratoire d’IA américain à l’origine des modèles GPT et de ChatGPT, accessibles par API et non téléchargeables., qui compensent un budget de recherche restreint par davantage de raisonnement interne. Sur l'ensemble des 35 configurations testées à 1 et 5 tours, plus d'un tiers affichaient des temps plus longs avec un budget réduit — tous sur des modèles OpenAI.

Le taux d'échec dicte le coût worst-case

Le revers du budget élargi apparaît quand le modèle ne trouve pas de réponse. Les données montrent que les modèles épuisent leur budget en tentant de trouver une réponse même s'ils finissent par échouer :

La tentative la plus profonde enregistrée — 81 recherches sur une table WideSearch — s'est soldée par une réponse incorrecte. Pour un workload à fort taux d'échec, réduire la profondeur de recherche devient un levier direct de maîtrise des coûts.

Sur les tâches simples, le constat est similaire : sur HLE, GPT-5.6 Sol avec Perplexity obtient un score comparable entre 1 et 25 tours, pour un coût triplé.

Le modèle pèse plus que le moteur

Une fois le budget fixé, le choix du modèle a plus d'impact que celui du moteur de recherche. Sur BrowseComp à 25 tours :

Sur cette suite spécifique, l'écart moyen entre moteurs à modèle constant est de 10 points ; entre modèles frontier et cost-efficient, il monte à 15 points. Côté coût, la variation entre moteurs est plus marquée sur les modèles frontier (le plus cher coûte 2,5 fois le moins cher) que sur les modèles économiques (1,5 fois).

OpenRouter souligne que cette comparaison est rendue possible par le fait que le server tool se situe au-dessus du provider : changer de modèle dans la requête ne modifie pas le comportement de recherche, y compris pour les modèles dont le provider ne propose pas de recherche native.

Ce qui est paramétrable aujourd'hui

Deux modes de recherche sont disponibles via l'API OpenRouter :

• Plugin web : une recherche unique avant que le modèle commence à écrire — option rapide et peu coûteuse pour les questions nécessitant des faits récents.
• Server tool : le modèle reçoit l'outil de recherche et décide lui-même quoi chercher — adapté aux réponses nécessitant plusieurs étapes.

Le moteur se configure via le paramètre engine : exa, parallel, perplexity ou native ; auto essaie d'abord le natif avant de basculer sur un tiers. Le champ max_tool_calls fixe le nombre de tours autorisés, et max_results le nombre de résultats par recherche.

Méthodologie et limites à connaître

Les runs passent par l'API publique OpenRouter sur des endpoints de production, via un harnessCadre d’évaluation / d’exécution qui mesure, contraint et observe un modèle ou un agent (jeux de tests, métriques, logs). de benchmark open sourceLogiciel dont le code source est disponible sous une licence qui autorise étude, modification, redistribution.. La configuration est standardisée : dix résultats par recherche, pas de page fetching, pas d'exécution de code. Le raisonnement est fixé par modèle. Les scores sont stricts (correct/incorrect contre une clé de réponse officielle, avec un LLMLarge Language Model : modèle de langage entraîné sur d’énormes corpus pour prédire et générer du texte. judge pour les comparaisons sémantiques).

Point important : ces scores ne sont pas comparables aux leaderboards d'agents publiés par les vendors. Ces derniers mesurent des produits agents complets combinant recherche, page fetching et outils de code. Les benchmarks OpenRouter isolent la configuration de recherche seule — le modèle ne lit que des extraits de résultats. L'objectif est la comparabilité entre configurations, pas la maximisation des scores absolus.

Les leaderboards affichent toujours le dernier run qualifiant pour chaque configuration, et les classements évoluent au fil des nouveaux runs.