Claude Sonnet 4.5 avec des outils : calculez le coût d’une tâche, pas seulement celui d’un appel

Le coût d’un appel n’est pas celui d’une tâche

Une intégration peut afficher une seule demande utilisateur tout en envoyant plusieurs requêtes à Claude avant que le travail soit terminé. Le modèle peut proposer d’utiliser un outil ; l’application exécute alors cette opération et renvoie son résultat. Le modèle traite ensuite à nouveau le contexte et décide s’il doit répondre ou recourir à un autre outil. Pour estimer le coût de la tâche, il faut comptabiliser chaque requête adressée au modèle, et pas seulement la demande initiale ou la réponse finale.

Ce guide propose un tableur de calcul pour Claude Sonnet 4.5. Il sépare les tokens d’entrée, les tokens de sortie et les éventuels frais associés aux outils hébergés sur serveur. Il n’inclut ni la mise en cache ni l’API Batch. Il ne suppose pas non plus que toutes les tâches comportent le même nombre de cycles : une recherche simple, un processus en plusieurs étapes et une tentative qui échoue peuvent avoir des coûts différents.

Le calcul porte sur l’utilisation de l’API Claude dans un flux délimité où l’application exécute des outils. Ne le transposez pas automatiquement à Bedrock, Google Cloud ou à une autre plateforme : les identifiants, tarifs, unités de facturation ou calendriers peuvent différer. Pour consulter le guide des tarifs, utilisez le lien interne pricing.index ; pour le modèle, Claude Sonnet 4.5 ; et pour le fournisseur, Anthropic.

Définissez le modèle, le canal et l’identifiant avant d’estimer le coût

Le nom commercial ne suffit pas à reproduire un calcul. Pour l’API Claude, la documentation des identifiants distingue l’alias claude-sonnet-4-5 de la version datée claude-sonnet-4-5-20250929. La page consacrée au cycle de vie indique que cette version est active et que son retrait n’interviendra pas avant le 29 septembre 2026. C’est une référence utile, mais pas une garantie de disponibilité future : vérifiez son statut juste avant de publier le tableur ou de le réutiliser.

Consignez également le canal. Les pages d’Anthropic décrivent des identifiants équivalents pour d’autres fournisseurs, mais il ne faut pas supposer que le même tarif, le même calendrier ou le même format d’utilisation s’applique partout. Le tarif saisi dans le tableur doit correspondre au canal réellement utilisé et à la date de l’exécution. Consultez la documentation des tarifs pour vérifier les prix en vigueur, les éventuelles différences régionales et les conditions propres aux plateformes partenaires.

Les éléments de vérification fournis ne comprennent pas les montants actuels des tarifs d’entrée et de sortie ni le montant des différences régionales. Ils ne sont donc pas présentés ici comme des données confirmées. Le modèle de calcul conserve ces tarifs sous forme de champs modifiables. Avant d’utiliser le résultat pour établir un budget, remplacez-les par les valeurs affichées dans la documentation applicable et notez la date de consultation.

Comptabilisez un cycle complet d’utilisation d’outils

Avec l’utilisation d’outils côté client, une réponse du modèle peut contenir une demande d’utilisation d’un outil. L’application exécute l’action et transmet un résultat d’outil dans un message ultérieur ; le modèle traite alors la suite. Cet échange peut se répéter. Le message qui demande l’utilisation d’un outil ne signifie pas que la tâche est terminée.

Pour chaque requête au modèle, comptez les données d’entrée effectivement envoyées dans cette requête. Elles peuvent inclure le message système, les messages précédents, les définitions des outils, le message de l’utilisateur et les résultats antérieurs que l’application a conservés dans le contexte. Si une nouvelle requête renvoie une partie du contenu précédent, ce contenu contribue de nouveau au calcul de l’entrée de cette requête. Ne comptez pas le résultat d’un outil comme une entrée du modèle tant que vous ne le lui avez pas effectivement envoyé.

La sortie est également comptabilisée pour chaque requête. Dans un cycle intermédiaire, elle peut prendre la forme d’une instruction d’outil et de ses arguments ; dans le dernier cycle, elle peut être une réponse destinée à l’utilisateur. Ne partez pas du principe qu’une sortie intermédiaire ne coûte rien. Pour Claude Sonnet 4.5, l’utilisation d’outils peut ajouter des tokens système associés à l’outil choisi. Leur nombre dépend de la configuration ; consultez la documentation tarifaire pour le vérifier. N’ajoutez pas une valeur générique sans avoir vérifié l’outil et le mode d’utilisation concernés.

Un outil hébergé sur serveur demande un suivi distinct. Ses opérations peuvent avoir leurs propres frais, et certaines boucles peuvent s’exécuter en interne dans le service. Dans ce cas, chaque opération interne ne correspond pas nécessairement à un appel visible côté client. Suivez séparément le nombre de requêtes au modèle et le nombre d’opérations de l’outil ; facturez chaque élément selon l’unité indiquée dans sa documentation.

Modèle de calcul par cycle et par tâche

Organisez le tableur avec une ligne par requête au modèle et un tableau séparé, ou un bloc distinct, pour les frais des outils. Pour chaque ligne de modèle, notez les tokens d’entrée facturables, les tokens de sortie facturables, ainsi que les prix d’entrée et de sortie correspondant au canal et à la date consignés. Si vous utilisez un outil hébergé, consignez aussi chaque opération facturée par cet outil. Vous pourrez ainsi additionner le coût d’une tâche sans mélanger les unités.

Le coût estimé en tokens pour chaque appel se calcule ainsi : (tokens d’entrée ÷ unité tarifaire) × prix d’entrée + (tokens de sortie ÷ unité tarifaire) × prix de sortie. L’unité tarifaire doit être celle publiée par le fournisseur ; si le prix est exprimé par million de tokens, l’unité est un million. Pour une tâche, additionnez les coûts de tous les appels au modèle, puis ajoutez à part les frais applicables aux outils.

Ne dédupliquez pas théoriquement le contexte dans le total des entrées. Si un message système, un schéma d’outil ou un résultat antérieur apparaît dans trois requêtes facturables, comptez l’utilisation enregistrée dans chacune d’elles, même si le texte est identique. À l’inverse, n’ajoutez pas de tokens estimés pour un contenu qui n’a pas été envoyé. Lorsque les mesures fiables manquent, indiquez qu’il s’agit d’une estimation et confrontez-la à l’outil de comptage des tokens ou aux données d’utilisation renvoyées par l’API.

Trois scénarios illustratifs

Les scénarios ci-dessous montrent comment organiser le décompte ; ils ne prédisent pas une utilisation universelle. Les volumes de tokens sont des nombres d’exemple destinés à tester le tableur, et non des mesures de Claude ou des tarifs publiés. Pour obtenir un coût réel en monnaie, remplacez les volumes illustratifs par les données enregistrées par votre application et utilisez les prix vérifiés pour votre canal.

Scénario A : une question reçoit une réponse sans outil. Comptez l’unique requête au modèle, y compris les messages et le contexte envoyés, ainsi que la sortie générée. Si l’application inclut une définition d’outil même lorsque celui-ci n’est pas utilisé, vérifiez le contenu réel de la requête ; ne partez pas du principe que cette définition était gratuite ou absente. Ce scénario ne comporte qu’un seul cycle de modèle, mais cela ne signifie pas que toutes les questions du produit auront le même coût.

Scénario B : une question nécessite une recherche. Comptez le premier appel, la réponse qui demande l’utilisation de l’outil, l’opération de recherche, puis l’appel suivant qui inclut le résultat. Si vous utilisez un outil hébergé sur serveur, enregistrez ses frais selon l’unité indiquée dans sa documentation ; ne les convertissez pas en tokens. Si l’application intègre une recherche externe côté client, consignez les éventuelles dépenses externes séparément de la facture de tokens Claude.

Scénario C : une action nécessite plusieurs appels successifs ou une tentative échoue. Si le premier outil renvoie une erreur et que l’application demande au modèle de la corriger, additionnez cet appel et les suivants. Si le processus redémarre dans le cadre d’une nouvelle tentative, conservez l’identifiant de cette tentative et ajoutez sa consommation au coût de la tâche terminée. Ne rendre compte que de la tentative réussie masquerait les dépenses nécessaires pour obtenir le résultat.

Les variables susceptibles de modifier le résultat

Le nombre de cycles est souvent une variable déterminante. Une tâche terminée après la première réponse peut nécessiter moins d’appels qu’une autre qui demande trois décisions du modèle. Mais n’attribuez pas automatiquement toute différence au modèle : elle peut dépendre de la logique de l’application, de l’état de l’outil, de la qualité des données, de la limite de nouvelles tentatives ou du critère de réussite.

La quantité de contexte conservée par le client joue également un rôle. Renvoyer des définitions longues, des messages antérieurs et des résultats volumineux peut augmenter les entrées des cycles suivants. Réduire l’historique peut modifier la consommation, mais cela n’est approprié que si les informations nécessaires à la tâche sont préservées. Mesurez l’effet lors d’une exécution contrôlée au lieu de supposer que le contexte est automatiquement résumé ou facturé une seule fois.

Les schémas des outils et les tokens système qui leur sont associés constituent une autre variable. Leur quantité exacte dépend de l’outil et de la configuration ; vérifiez-la dans la documentation tarifaire et dans le comptage de la requête. Un résultat d’outil volumineux peut aussi augmenter l’entrée de l’appel suivant, à condition qu’il soit effectivement envoyé au modèle.

Enfin, distinguez les tâches qui échouent, les nouvelles tentatives automatiques et les corrections demandées par l’utilisateur. Un budget fondé sur le coût moyen des seules tâches terminées peut sous-estimer les dépenses s’il ignore les tentatives échouées. Il est utile de publier à la fois le coût par tentative et le coût cumulé par tâche terminée, en précisant la période et l’ensemble des exécutions mesurées.

Vérifiez le tableur en production et indiquez les exclusions

Pour effectuer un audit, conservez un identifiant de tâche et de tentative, l’identifiant du modèle, le canal, le numéro de chaque requête, les outils disponibles, les résultats envoyés au modèle et les données d’utilisation de chaque réponse. Consignez également les appels échoués et les opérations qui n’ont produit aucune réponse utile. Évitez de stocker des données personnelles ou des secrets qui ne sont pas nécessaires à l’analyse ; les métriques de coût peuvent être associées à des identifiants internes pseudonymisés.

La documentation de l’API comprend un endpoint de comptage des tokens qui accepte les messages, les instructions système et les outils. Il peut aider à estimer une requête avant son envoi. Il ne remplace ni la vérification des données d’utilisation renvoyées lors de l’exécution ni celle de la facture finale, en particulier en présence de cycles multiples, d’erreurs ou de frais d’outils. Utilisez l’estimation préalable pour planifier et les journaux effectifs pour auditer.

Comparez le coût calculé à la facture pour une période et un canal équivalents. En cas d’écart, recherchez des appels manquants, une mauvaise interprétation des unités tarifaires, des différences régionales ou des frais distincts pour les outils. Prévoyez une colonne consacrée aux exclusions explicites. Ce calcul ne comprend ni la mise en cache ni l’API Batch ; ces options peuvent nécessiter un traitement spécifique et ne doivent pas être ajoutées à la formule comme si elles faisaient partie du flux de base.

Un chiffre utile n’est pas forcément une prédiction exacte. Publiez la méthode, la date des tarifs, l’ensemble de tâches étudié, le nombre de tentatives et les exclusions. Si l’échantillon est peu varié, présentez le résultat comme celui de cet échantillon, et non comme le coût typique de toute tâche utilisant Sonnet 4.5.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.