API de recherche et de fetch web : que vaut vraiment $0.01

Tous les grands outils de recherche web côté serveur facturent désormais le même prix : $0.01 par recherche. C’est pourtant la partie la moins intéressante de la facture. Dans nos mesures, chaque requête recevait 1 500 à 3 100 tokens de résultats, facturés au tarif d’entrée du modèle choisi. Au tour suivant, le comportement dépend d’une différence de protocole rarement examinée par les équipes : soit l’endpoint conserve les éléments issus de la recherche, soit il les supprime discrètement et laisse le modèle relancer une recherche à vos frais. Nous avons mesuré synthorai:web_search et synthorai:web_fetch de Synthorai sur quatre familles de modèles, puis comparé les résultats aux tarifs publiés par Anthropic et OpenAI pour leurs propres outils de recherche hébergés.

TL;DR

• Synthorai, Anthropic et OpenAI facturent tous $0.01 par recherche ; les relevés de facturation affichent précisément $0.0100.
• Une recherche injecte 1 500 à 3 100 tokens de résultats, facturés au tarif d’entrée du modèle : sur les modèles bon marché, les frais fixes dominent ; sur les modèles premium, les tokens peuvent représenter jusqu’à la moitié du total.
• max_uses fixe un plafond, pas un quota : avec une limite de 10, le modèle s’est arrêté à 3 ; les frais dépendent du nombre de recherches réellement exécutées.
• Le deuxième tour varie selon l’endpoint : /v1/messages rejoue les résultats (≈3 900 tokens, sans nouveaux frais) ; /v1/chat/completions les supprime, si bien qu’une relance nécessitant les sources déclenche une nouvelle recherche payante.

Pourquoi les modèles ont-ils besoin de recherche et de fetch web ?

Parce que les connaissances d’un modèle s’arrêtent à la date limite de ses données d’entraînement, contrairement à la plupart des questions traitées en production. Prix, notes de version, taux de change, résultats sportifs ou contenu d’une URL tout juste envoyée par l’utilisateur : rien de tout cela ne figure dans les poids du modèle. Répondre avec assurance malgré tout, c’est envoyer aux utilisateurs des informations « actuelles » inventées. La recherche web sert à trouver la source quand le modèle ne sait pas où se trouve la réponse. Le fetch web sert à lire une page précise dont il connaît déjà l’URL. Il est possible de construire les deux avec une API de recherche, un scraper et une boucle de tool calling, et de nombreuses équipes le font. Les versions côté serveur existent parce que cette boucle n’apporte aucune valeur propre au produit. L’exécuter chez le fournisseur élimine les allers-retours, le code de parsing et la charge opérationnelle, pour des frais finalement identiques partout.

Comment fonctionne réellement la recherche web côté serveur ?

Toute la boucle s’exécute dans une seule requête API. C’est là tout l’intérêt. Avec des outils côté client, le modèle demande à votre code d’effectuer une recherche, votre code lui renvoie les résultats, et chaque échange retransmet la conversation. Un outil serveur retire votre code de la boucle : vous déclarez {"type": "synthorai:web_search"} dans tools, le modèle produit une requête de recherche, la gateway l’envoie à un fournisseur spécialisé, injecte les résultats dans le contexte du modèle, puis le modèle les lit et répond. Il peut aussi relancer une recherche, dans la limite de max_uses. Une requête entre, une réponse sort, avec les citations et la facture.

Une seule ligne suffit dans une requête ordinaire, sans boucle ni callback :

curl https://synthorai.io/v1/chat/completions \
  -H "Authorization: Bearer $SYNTHORAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "deepseek-v4-flash-0731",
    "messages": [{"role": "user", "content": "What is one AI news headline from this week? Name the source."}],
    "tools": [{"type": "synthorai:web_search", "max_uses": 1}]
  }'

Le fetch web se déclare de la même façon avec un autre type. Placez l’URL dans le message et la gateway récupère la page :

"messages": [{"role": "user", "content": "Fetch https://example.com/pricing and summarize the tiers."}],
"tools": [{"type": "synthorai:web_fetch", "max_uses": 1}]

Le schéma reprend exactement la requête de recherche ci-dessus, telle que nous l’avons mesurée sur deepseek-v4-flash-0731. Le compteur affichait 2 059 tokens d’entrée, soit une question de 30 tokens et environ 2 000 tokens de résultats injectés, ainsi que 169 tokens de sortie et un coût total de $0.0104. Cela correspond à $0.01 de frais de recherche et environ $0.0004 de tokens. La facturation ne comporte que deux éléments : les frais au moment de la recherche et les tokens de résultats au tarif d’entrée habituel du modèle. Un fetch est facturé de la même façon, la page récupérée remplaçant les extraits de résultats.

La déclaration elle-même ne coûte rien : si une requête déclare l’outil sans lancer de recherche, aucun frais n’est facturé. L’outil fonctionne avec tous les modèles du catalogue. C’est la différence structurelle avec les solutions propriétaires : la recherche hébergée d’Anthropic est réservée aux modèles Claude, celle d’OpenAI aux modèles OpenAI, tandis qu’un outil au niveau de la gateway fonctionne quel que soit le modèle ciblé.

Combien coûte réellement une recherche ?

Les frais fixes sont de $0.01, auxquels s’ajoutent les tokens. Plus le modèle est cher, plus la part des tokens augmente. Nous avons envoyé trois fois la même question d’actualité avec une seule recherche sur quatre familles de modèles. Pour chaque modèle, nous avons calculé précisément le tarif des tokens à partir de mesures sans outil, puis isolé les frais par différence :

Sur le modèle le moins cher, les frais de recherche représentent 97% de l’appel. Sur les modèles premium, les tokens injectés absorbent la moitié de la facture. Le montant des frais ne repose pas sur une déduction : nos relevés de facturation les détaillent sur une ligne distincte, à exactement $0.0100 par appel, avec un décompte séparé des tokens injectés par l’outil. Sur un appel de fetch réel, ils représentaient par exemple 3 454 des 3 836 tokens d’entrée. Dans nos mesures, une recherche complète coûtait entre $0.010 et $0.012 selon le modèle utilisé. En budgétant le haut de cette fourchette, vous éviterez les surprises. En pratique, associer la recherche côté serveur à un modèle bon marché revient à payer principalement le service de recherche ; le coût du modèle devient presque négligeable.

Quels sont les trois paramètres qui déterminent la facture en tokens ?

Le nombre de recherches, la longueur des résultats et le poids de la page. Le reste est négligeable. Ces trois paramètres se mesurent directement, et vous en contrôlez directement deux.

Premier paramètre : le nombre de recherches exécutées. max_uses est un plafond, pas un objectif. Pour une question comparant les prix de cinq fournisseurs, autoriser 1, 2 puis 3 recherches a coûté respectivement $0.0106, $0.0216 et $0.0319. Les frais augmentaient linéairement de $0.01 par recherche réellement exécutée. Passer la limite à 5, puis même à 10, n’a rien changé : le modèle s’est arrêté seul après trois recherches. La capacité inutilisée est gratuite, comme pour les budgets de réflexion que nous avons mesurés sur les modèles de reasoning. La valeur par défaut est 3, avec une limite maximale de 10. Sans configuration, le pire cas pour une question qui pousse le modèle à multiplier les recherches correspond donc à trois frais fixes et trois chargements de résultats. Sur les routes qui répondent à un fait unique, fixez max_uses: 1.

Deuxième paramètre : la longueur des résultats. La taille de l’injection dépend de l’étendue de la question, pas du hasard. Sur douze recherches uniques avec deepseek-v4-flash-0731 :

Une question ciblée produit un ensemble de résultats compact. Une comparaison en récupère davantage, environ 45% de plus qu’une question portant sur un fait unique. Pour établir un budget, comptez 2 000 tokens par recherche avec une marge de 20%. Cette estimation couvre tous nos résultats. Aux tarifs habituels des modèles, la part en tokens d’une recherche représente alors entre un vingtième et la moitié des frais fixes de $0.01.

Troisième paramètre : le poids de la page récupérée. Les frais de fetch ne changent jamais ; le reste dépend de la page. Voici nos mesures, toutes effectuées avec le même modèle :

Avec un modèle bon marché, même l’article Wikipédia ne coûte qu’un centime et demi. Faites passer le même fetch par un modèle à $2 par million de tokens et la page coûte six centimes et demi, soit cinq fois le montant des frais fixes. Autre donnée utile pour le budget : une même page ne produit pas le même nombre de tokens selon la famille de modèles. L’article riche en données représentait 5 196 tokens sur DeepSeek et 5 508 sur qwen3.8-max, soit un surcoût de 6% lié au tokenizer, cohérent avec nos mesures de densité.

Que deviennent les résultats de recherche au tour suivant ?

Les deux protocoles API font ici un choix différent, qui détermine le coût de la relance. Dans /v1/messages, un tour assistant est une liste de blocs de contenu. L’activité des outils serveur fait donc officiellement partie du tour : la réponse contient server_tool_use, puis web_search_tool_result, puis le texte. Le protocole prévoit que ces blocs soient renvoyés au tour suivant. Les sources sont ainsi conservées et refacturées comme tokens d’entrée. Dans /v1/chat/completions, un message assistant est une simple chaîne de contenu, sans emplacement pour les résultats des outils serveur. Ceux-ci sont absorbés côté serveur. Seule la réponse visible entre dans l’historique, et les sources disparaissent.

Nous avons exécuté la même paire recherche-relance sur claude-sonnet-5 avec les deux interfaces. Via /v1/messages, la relance a compté 3 911 tokens d’entrée pour un coût de $0.0109, entièrement lié aux tokens. Aucune nouvelle recherche n’a été lancée, car le modèle disposait toujours des résultats. Via /v1/chat/completions, elle a coûté $0.0204, soit davantage que le rejeu. Le modèle ne disposait plus que de son propre résumé en une ligne et a lancé une nouvelle recherche : $0.01 de frais supplémentaires, plus un nouveau chargement de résultats. Cette nouvelle recherche n’est toutefois pas systématique. Lors d’un test précédent avec la même relance et le même mécanisme d’absorption sur deepseek-v4-flash-0731, le modèle a répondu directement à partir de son résumé, pour 460 tokens d’entrée et $0.00009. Avec l’absorption, le coût de la relance suit donc deux scénarios distincts : presque nul si le résumé suffit, ou frais fixes plus chargement des résultats si le modèle décide de retourner sur le web.

Aucun endpoint n’est intrinsèquement moins cher : ils placent simplement le coût à des endroits différents. Le format par blocs impose à chaque tour un coût prévisible en tokens, mais ne rachète jamais des sources déjà obtenues. Le format absorbé parie que les relances n’auront pas besoin des sources et paie une nouvelle recherche chaque fois que ce pari échoue. Les conversations longues avec des relances simples conviennent à /v1/chat/completions. Les agents de recherche qui interrogent les sources ont intérêt à utiliser /v1/messages, où les règles de superposition du prompt cache s’appliquent aux résultats conservés comme à tout autre contexte volumineux.

Que facturent Anthropic et OpenAI, et où leurs outils fonctionnent-ils ?

La comparaison tient en une phrase : chaque fournisseur facture $0.01 par recherche, puis applique le tarif des tokens de son modèle. Anthropic facture $10 pour 1 000 recherches, les résultats étant comptés comme tokens d’entrée. Son fetch web n’a pas de frais fixes et ne facture que les tokens. OpenAI facture également $10 pour 1 000 appels, avec un traitement des tokens qui varie selon le niveau du modèle. Les frais sont donc identiques ; la variable est le tarif d’entrée du modèle appliqué aux 1 500 à 3 100 tokens injectés.

La vraie différence entre les trois n’apparaît pas dans la grille tarifaire : elle tient à l’endroit où les outils peuvent s’exécuter. Les outils serveur propriétaires sont conçus pour les stacks d’agents de leur fournisseur et restent limités à ses interfaces. La documentation d’Anthropic précise que la recherche web n’est pas disponible sur Amazon Bedrock, que seule la recherche basique fonctionne sur Google Cloud et que Microsoft Foundry exige un déploiement hébergé chez Anthropic. Le fetch web n’est disponible ni sur Bedrock ni sur Google Cloud. La recherche d’OpenAI dépend de sa Responses API. Si vous déplacez votre workload vers un autre cloud ou une autre famille de modèles, l’outil propriétaire ne suit pas. C’est aussi pourquoi une gateway ne transmet pas ces outils : ils ne peuvent pas accompagner le trafic. Un outil au niveau de la gateway fait le choix inverse : une seule déclaration continue de fonctionner après un changement de modèle comme après une migration de plateforme.

FAQ

Combien coûte l’API de recherche web par requête ?

$0.01 par recherche exécutée, détaillé sur une ligne distincte dans les relevés de facturation, auxquels s’ajoutent les résultats injectés au tarif d’entrée du modèle, soit 1 500 à 3 100 tokens par recherche dans nos tests. Une requête qui déclare l’outil sans lancer de recherche n’entraîne aucuns frais. Pour un modèle courant, prévoyez un coût total de $0.010-0.012 par recherche. Sur les modèles les moins chers, les frais fixes représentent 97% du total.

Les résultats de recherche sont-ils refacturés aux tours suivants ?

Cela dépend de l’endpoint. Avec /v1/messages, les blocs de résultats sont rejoués avec l’historique, soit environ 3 900 tokens d’entrée par tour dans nos tests, sans nouveaux frais de recherche. Avec /v1/chat/completions, les résultats sont absorbés après le tour. La relance coûte presque rien si le modèle répond à partir de son résumé, soit $0.00009 dans un test, mais elle entraîne de nouveaux frais et un nouveau chargement de résultats si le modèle relance une recherche, soit $0.0204 dans un autre test. La recherche propriétaire d’Anthropic documente le rejeu comme comportement standard ; les résultats y sont donc refacturés à chaque tour.

Comment plafonner le coût de la recherche web pour une requête ?

Avec max_uses. Il fixe une limite stricte que le modèle ne peut pas dépasser, avec une valeur par défaut de 3 et un maximum de 10. Les frais ne dépendent que du nombre de recherches réellement exécutées, et la capacité inutilisée est gratuite. Pour les routes qui répondent à un fait unique, max_uses: 1 limite le pire cas à un seul montant de frais fixes et un seul chargement de résultats.

Quand faut-il utiliser le fetch web plutôt que la recherche web ?

Utilisez le fetch lorsque vous connaissez déjà l’URL et souhaitez récupérer la page entière ; utilisez la recherche lorsqu’il faut d’abord trouver les sources. Les deux coûtent $0.01 par utilisation via la gateway. Un fetch injecte toutefois toute la page, de 209 tokens pour une page minimale à 27 380 pour un long article dans nos mesures, alors qu’une recherche injecte des extraits provenant de plusieurs sources. Pour les pipelines de lecture et de résumé utilisant spécifiquement des modèles Claude, l’outil de fetch d’Anthropic est moins cher, car il n’applique aucuns frais fixes.

Mesures effectuées le 2026-08-10 via la gateway Synthorai avec synthorai:web_search et synthorai:web_fetch sur deepseek-v4-flash-0731, gpt-5.6-luna, qwen3.8-max et claude-sonnet-5 : tarifs des tokens calculés pour chaque modèle à partir de deux mesures de référence sans outil ; frais de recherche obtenus en soustrayant la valeur des tokens du coût facturé (n=3 par modèle) ; série de tests sur max_uses ; mesure du volume de résultats par type de requête (4 types x 3 exécutions) ; tests du tour suivant sur les deux endpoints avec des questions identiques ; série de fetch sur cinq pages (trois de nos pages, une page externe minimale et un long article). Les frais ont été vérifiés dans les relevés détaillés de facturation, avec une ligne par appel pour les frais d’outil et une autre pour les tokens injectés, et non déduits uniquement des totaux. Les chiffres d’Anthropic et d’OpenAI correspondent aux tarifs publiés dans leur documentation au moment de la publication. Les nombres du schéma proviennent d’un appel mesuré sans modification. Les tarifs et le comportement peuvent évoluer ; vérifiez-les dans vos propres relevés d’utilisation.

← Retour au blog