Budgétiser ses appels LLM en R : compter les tokens avant de payer

Une app Shiny avec chatbot intégré, un pipeline de résumé automatique de documents, un agent qui interroge une base de données : toutes ces briques ont un point commun, un coût par appel qui dépend du nombre de tokens envoyés et reçus. Tant qu'on reste en phase de prototype, personne ne regarde la facture. Dès que l'app passe en production avec des dizaines d'utilisateurs, le sujet devient un enjeu de pilotage, et c'est souvent l'équipe data qui doit y répondre sans avoir d'outil pour le faire a priori.

Jusqu'ici, la seule façon de connaître le coût d'un prompt était de l'envoyer et de regarder la réponse de l'API après coup. ellmer introduit token_count(), une fonction qui interroge le fournisseur pour savoir combien de tokens une entrée consommerait, sans déclencher l'appel réel. C'est la différence entre estimer une facture et la découvrir en fin de mois. Pour une équipe qui opère plusieurs apps en production, ça change la manière de concevoir les prompts et de dimensionner les contextes envoyés au modèle.

Concrètement, l'usage le plus utile est en amont de l'envoi : on construit son prompt, on insère le contexte (historique de conversation, extraits de documents via RAG, résultats de requêtes), puis on vérifie la taille avant de valider l'appel. Dans une app shinychat, ça permet d'afficher à l'utilisateur ou à l'administrateur une estimation du coût de sa question, ou de tronquer automatiquement un contexte trop long avant qu'il ne fasse exploser la note. C'est aussi un outil de test : on peut comparer deux formulations de prompt système et choisir la plus économique à qualité de réponse égale.

La limite, c'est que token_count() dépend de l'implémentation du fournisseur et peut légèrement diverger du décompte réel facturé, notamment avec des messages systèmes complexes, des appels d'outils ou des pièces jointes. Ce n'est pas un simulateur de facture au centime près, c'est un ordre de grandeur fiable pour arbitrer. Et ça ne remplace pas un vrai suivi de consommation côté fournisseur (dashboard OpenAI, Anthropic, etc.), qui reste la source de vérité pour la facturation.

Le vrai gain est organisationnel plus que technique : ça permet d'introduire un budget token dans le cycle de développement, au même titre qu'un budget mémoire ou un budget de latence. Une équipe qui construit plusieurs apps IA en R peut désormais écrire des tests qui vérifient qu'un prompt type reste sous un seuil donné, avant même de solliciter l'API.

duplicated() signale directement les éléments déjà vus plus tôt dans un vecteur, sans passer par table() ni comparaison manuelle. Combiné à un indice logique inversé, c'est la manière la plus directe de filtrer les doublons tout en gardant la première occurrence.