Coût en tokens d’un agent IA par tâche : formule, exemple et mesure

Mesurer le coût par tâche terminée

Le coût en tokens d’un agent IA par tâche doit se calculer sur le résultat vérifié, pas sur un seul appel modèle. Une tâche “terminée” doit avoir une définition simple : brouillon placé au bon endroit, événement créé dans le bon calendrier, itinéraire ouvert vers la bonne destination, ou autre résultat que l’utilisateur peut constater. Les tentatives échouées comptent dans le coût total.

La formule de base est donc : coût total mesuré / nombre de tâches vérifiées comme réussies. Le coût total peut inclure l’usage API, les lectures ou écritures de cache si le fournisseur les facture, les frais d’outil, les services externes, et éventuellement une part d’abonnement ou de crédits si vous décidez de l’allouer à ce lot. Ne double-comptez pas ce qui est déjà inclus dans un forfait ou dans une catégorie de facturation.

Chez FoneClaw, nous abordons le sujet comme un coût de tâche Android complète. Le modèle aide à comprendre et planifier ; les actions téléphone prises en charge réalisent une partie du parcours. Cela peut changer le volume de contexte, les reprises et la durée humaine, mais la seule mesure fiable reste l’usage réel du fournisseur et le nombre de résultats validés.

Construire un registre à partir de l’usage fournisseur

Commencez par un registre simple, avec des catégories disjointes. Les pages Gemini sur le comptage des tokens rappellent que le texte et d’autres modalités, dont les images, sont tokenisés, et que l’usage réel peut inclure entrées, sorties, contexte en cache et tokens de réflexion selon le modèle. La tarification Gemini API montre aussi que les prix varient selon le modèle, la modalité, le niveau de service et certaines fonctions comme le cache ou le grounding.

Le registre minimal ressemble à ceci : entrées non mises en cache, lectures de cache, sorties facturables, frais de cache écriture ou stockage si applicables, frais d’outil, frais de service externe, puis total. Pour un fournisseur avec cache de prompt, la documentation Claude sur le prompt caching distingue les écritures de cache, les lectures de cache et l’entrée ordinaire. Utilisez les champs d’usage du fournisseur pour confirmer qu’un cache a réellement été utilisé.

La formule réutilisable est : sous-total modèle = (tokens d’entrée non mis en cache / 1 000 000 × taux d’entrée par million) + (tokens lus depuis le cache / 1 000 000 × taux de lecture de cache par million) + (tokens de sortie facturables / 1 000 000 × taux de sortie par million). Ajoutez ensuite séparément les frais applicables : écriture ou stockage de cache, outils, services externes, abonnement alloué ou crédits consommés. Le coût par tâche terminée = (sous-total modèle + frais supplémentaires) / tâches vérifiées comme réussies.

Les captures, images, descriptions d’écran et tokens de réflexion doivent suivre la facturation du fournisseur. Si des tokens image sont déjà inclus dans l’entrée, ne les ajoutez pas une deuxième fois comme “frais image” séparé. Si une sortie inclut déjà les tokens de réflexion dans le prix de sortie, ne les refacturez pas. Et surtout, incluez les appels ratés et les reprises dans le total une seule fois : le lot doit déjà contenir toutes les tentatives.

Recalculer un lot hypothétique

Voici un registre pédagogique entièrement hypothétique, en dollars, avec des taux inventés pour montrer la méthode. Ce ne sont pas des prix Google, Anthropic, FoneClaw ou d’un autre fournisseur.

Dans cet exemple, le lot contient 100 tâches tentées et tous les appels, reprises et échecs sont déjà inclus dans les volumes. Si 90 tâches sont vérifiées comme terminées, le coût par tâche terminée est 3,34 $ / 90, soit environ 0,0371 $ par réussite. Si aucune tâche n’est terminée, le coût par réussite n’est pas zéro : la métrique est indéfinie et le lot doit être diagnostiqué.

Ce registre ne contient pas de frais d’écriture de cache, de stockage de cache, d’abonnement ou de conversion de devise. Dans un vrai calcul, ajoutez seulement les catégories réellement facturées ou allouées. Le but est de rendre le calcul reproductible, pas de produire un pourcentage d’économie universel.

Ce que l’exécution côté téléphone peut changer

L’exécution côté téléphone peut modifier le coût lorsque l’action prise en charge évite de redécrire la même interface ou de replanifier la même étape. Par exemple, FoneClaw peut lire l’état visible d’une app prise en charge, identifier un champ éditable visible et y saisir un brouillon. Cette saisie ne soumet pas, n’envoie pas et n’appuie pas sur Entrée ; l’utilisateur conserve la décision d’envoi.

Les workflows sauvegardés peuvent aussi stocker des étapes d’outil réutilisables quand elles sont prises en charge. Cela peut réduire certaines reprises, mais ne garantit pas l’absence de futurs appels modèle. Le modèle configuré peut encore être nécessaire pour interpréter la demande, adapter un texte ou vérifier un contexte. Un modèle en ligne peut traiter le contexte fourni ; l’action sur téléphone ne prouve pas que toute l’inférence est locale.

La forme du contexte compte également. Une lecture structurée de l’écran et une capture d’image ne suivent pas toujours le même coût, mais il n’existe pas de règle universelle disant que l’une coûte toujours moins. Utilisez l’outil approprié à la tâche et mesurez avec les champs d’usage du fournisseur. La page Contrôler un téléphone Android avec un agent IA : intention, confirmation et vérification explique comment relier action prise en charge, vérification et résultat visible.

Tester une petite tâche répétable

Pour comparer deux configurations, choisissez dix tâches identiques et peu risquées. Exemple : préparer un brouillon de réponse dans une app prise en charge, sans l’envoyer. Gardez le même téléphone, la même app, le même modèle de consigne, le même texte d’entrée et la même définition de réussite. Une réussite peut être : “le brouillon exact est visible dans le bon champ, pour le bon destinataire, sans envoi automatique”.

Pour chaque essai, notez les entrées non mises en cache, lectures de cache, sorties, éventuels frais d’outil, reprises, résultat final, temps écoulé, temps de relecture humaine et approbations demandées. Gardez le temps humain comme une métrique séparée, ou convertissez-le en argent une seule fois avec un taux horaire choisi. Pour l’énergie, faites pareil : conservez les Wh incrémentaux séparément, ou convertissez-les une seule fois avec énergie incrémentale en Wh / 1000 × prix local du kWh. Ne mélangez pas ensuite ces catégories comme si elles n’avaient pas déjà été comptées.

Le protocole doit aussi inclure les échecs. Une tâche qui finit dans le mauvais champ, qui demande une permission absente, qui perd le contexte après changement d’écran ou qui produit un envoi incertain doit compter dans les tentatives. Avant de relancer, diagnostiquez l’échec ; le guide Diagnostiquer et récupérer un agent IA mobile : runbook Android pour échecs, permissions et relance d’outil aide à éviter de répéter du travail facturé sans comprendre la cause.

Réduire le gaspillage sans retirer les contrôles

Les économies utiles viennent surtout d’entrées claires, d’historiques bornés, de caches confirmés par les champs d’usage fournisseur, et de diagnostics avant relance. Réduire les confirmations qui protègent un destinataire, une permission ou une action externe est une mauvaise optimisation : elle déplace le coût vers le risque.

Gardez les validations pour les actions conséquentes, notamment les messages, paiements, suppressions, modifications ou publications. Côté FoneClaw, les politiques globales et par outil restent une partie du traitement des actions sensibles. La page Fonctionnalités FoneClaw présente les actions Android prises en charge, tandis que Automatiser des tâches Android en plusieurs étapes avec confirmation montre comment structurer une tâche complète sans multiplier les reprises inutiles. Pour arbitrer entre traitement local, cloud et données envoyées, lisez aussi Confiance dans un agent IA : contrôle local Android ou sécurité cloud ?.