Cherry Studio : consommation de tokens et coûts des requêtes

Dans les statistiques de coûts de Cherry Studio, votre image est générée, mais la colonne Cost de Requests reste vide ou affiche un tiret : cela ne signifie pas que la génération est gratuite. Un montant affiché ne constitue pas non plus, à lui seul, la facture du fournisseur. Retrouvez d’abord la requête dans Settings → Usage → Requests, puis vérifiez l’origine du montant, l’unité de facturation et le débit réel pour déterminer si un tarif manque, si le client ne peut pas calculer le coût ou si les deux systèmes comptabilisent des appels différents.

Conservez les requêtes et les écritures de facturation existantes avant de poursuivre. Inutile de générer plusieurs fois une image pour faire apparaître un nombre dans Cost. Les explications ci-dessous s’appuient sur le code de la version officielle et sur les changements intégrés au projet : elles décrivent le fonctionnement du suivi des coûts, sans établir qu’une combinaison précise de fournisseur, de modèle et de compte a été validée par des appels réels.

Vérifiez la version : le réglage par image est dans main, pas encore dans la dernière version publiée

Au 17 octobre 2026, la dernière version officielle reste v2.1.6 ; la pull request (PR) #21892 ajoutant le réglage du prix par image a été intégrée à main le même jour. main est la branche de développement. L’intégration d’un changement ne prouve donc pas que la version officielle installée sur votre ordinateur le contient déjà. Voir la version officielle publiée et la modification ajoutant le réglage par image.

Le 16 octobre 2026, codeBennyLaw a signalé dans le ticket #21870 que, sous Windows avec v2.1.6, les réglages du modèle ne proposaient que des prix par million de tokens et que certaines requêtes d’images affichaient un tiret dans Cost. Ce témoignage décrit son environnement ; il ne permet pas de conclure que tous les modèles d’images sont gratuits. Le ticket a depuis été fermé avec l’intégration de la PR, mais les étapes à suivre dépendent toujours de votre version installée.

Interface réellement disponible	Possibilités	Action à effectuer
Éditeur de prix des modèles de v2.1.6	Prix des tokens d’entrée, de sortie et de cache, avec paliers ; aucun champ de prix par image	Vérifier les tarifs des modèles facturés en tokens ; comparer directement les requêtes facturées par image aux écritures du fournisseur
Version intégrant la PR #21892, avec les champs Price unit et Image price effectivement visibles	Définir le prix de chaque image générée	Confirmer que le fournisseur facture bien par image, saisir le tarif correspondant et vérifier une nouvelle requête
Version plus récente ou personnalisée dont l’interface diffère	Fonctions propres à cette version	Lire ses indications et examiner ses champs réels, sans déduire la configuration d’une capture d’une autre version

Ce tableau repose sur l’éditeur de prix de v2.1.6 et l’éditeur après intégration du changement. Les noms anglais des champs sont conservés ci-dessous pour vous aider à les repérer ; les libellés affichés dépendent de la langue du client.

Retrouvez la même requête dans Requests

Identifiez l’appel avant de comparer les montants. Préparez la version du client, la configuration du fournisseur utilisée à ce moment-là, l’ID exact du modèle et les relevés d’utilisation ou de débit du même compte fournisseur. Deux modèles portant le même nom à l’écran ne désignent pas nécessairement le même modèle ni le même canal de facturation.

Ouvrez Settings → Usage → Requests, sélectionnez une période qui couvre la requête et retrouvez-la à l’aide de Date.
Comparez le nom du modèle de chaque ligne et le nom du fournisseur affiché en dessous. La colonne Source indique l’assistant, la conversation ou la fonction à l’origine de l’appel ; elle n’indique pas l’origine du coût.
Notez la date, l’heure, Tokens, Cost et la devise. Si la ligne manque, repassez d’abord au tri par Date, vérifiez la période et utilisez le chargement de lignes supplémentaires en bas du tableau. Le tri par Cost filtre aussi selon la devise sélectionnée : les lignes sans montant peuvent alors disparaître des résultats.
Conservez également les écritures du fournisseur sur cette période. La date enregistrée par le client correspond à la fin de l’appel ; le fournisseur peut utiliser une autre heure de comptabilisation ou un autre fuseau horaire. Prévoyez une fenêtre qui couvre toute la durée de la requête.

Les champs et leur affichage sont visibles dans le code officiel du tableau Requests et dans la logique d’enregistrement des appels.

Si le tableau entier est vide, commencez par vérifier la période, le chargement et la fin effective de l’appel. Si seul Cost manque, poursuivez avec les prix et l’origine du montant. Ces situations appellent des vérifications différentes ; réinstaller le logiciel ou effacer l’historique ne permet pas, en soi, de savoir si le fournisseur a débité votre compte.

Trois cas pour Cost, que la colonne Source ne distingue pas

L’origine du montant compte davantage que sa précision apparente. Le client tente d’abord d’accepter le coût transmis par le fournisseur si les conditions requises sont remplies. Sinon, il l’estime à partir des prix enregistrés au moment de l’appel ; si aucune de ces deux méthodes n’aboutit, le montant reste absent. Voir la logique de calcul et d’enregistrement des coûts.

État de l’enregistrement	Signification	Utilisation pour le rapprochement
`costSource` vaut `provider`	Le client a accepté le coût renvoyé par le fournisseur ; les conditions portant sur les capacités déclarées, le montant et la devise doivent être remplies	Le traiter comme une information de coût jointe à cette réponse, puis le comparer au débit du compte fournisseur
`costSource` vaut `computed`	Le client a calculé le montant à partir de l’utilisation et des prix conservés au moment de l’appel	S’en servir pour estimer les dépenses et suivre leur évolution, en vérifiant que les tarifs locaux correspondent à ceux du compte
Cost et son origine sont absents	Aucun montant fournisseur exploitable, et calcul local impossible	Le montant est inconnu ; consulter le débit réel chez le fournisseur, sans remplacer la valeur manquante par zéro

Dans v2.1.6, un Cost absent est affiché sous la forme - ; le libellé anglais du code main examiné est Unable to estimate. Le tableau Requests ne comporte ni colonne costSource distincte ni infobulle indiquant l’origine du coût. Ne confondez pas Source avec cette information et ne déduisez pas l’origine d’un simple montant. En l’absence d’une indication explicite dans l’interface, considérez cette origine comme indéterminée. Voir le tableau dans main et les libellés anglais.

La présence d’un champ de coût dans une réponse ne garantit pas que le client l’acceptera. Celui-ci vérifie aussi, notamment, si le fournisseur déclare transmettre un coût réel et si la devise peut être déterminée. Vous n’avez pas à modifier les enregistrements internes pour effectuer cette vérification : le rapprochement avec un débit passe toujours par le compte fournisseur. Voir l’explication officielle des règles de coût.

Estimation par tokens : vérifiez l’unité, puis les catégories

Tokens dans Requests représente un total d’utilisation, qu’il ne faut pas multiplier directement par un tarif unique. computed signifie seulement que le montant est calculé localement, pas que le nombre de tokens est lui aussi une estimation locale. La fonction de total utilise d’abord totalTokens ; à défaut, elle additionne les compteurs d’entrée et de sortie disponibles. Si les deux sont inconnus, elle laisse le total absent. Voir la définition du total de tokens.

Ouvrez Settings → Model Provider → votre fournisseur → roue dentée du modèle concerné → More settings, puis repérez la zone des prix. Comparez les valeurs au tarif actuel du compte, du modèle et du palier de facturation concernés :

Input Price / Output Price : prix par million de tokens d’entrée et de sortie, respectivement. Si le fournisseur donne un prix pour mille tokens, convertissez-le d’abord en prix par million. Ne recopiez pas directement le nombre.
Cache Read Price / Cache Write Price : prix de lecture et d’écriture du cache. Un champ vide dans cet éditeur reprend le prix d’entrée du palier ; saisir 0 revient à définir localement un tarif gratuit. Une valeur vide ne signifie donc pas gratuité.
Paliers selon la longueur d’entrée : le client choisit le palier d’après le nombre total de tokens d’entrée de l’appel et applique ce tarif à l’appel entier. Il ne répartit pas progressivement les tokens entre plusieurs tranches. S’il manque une donnée d’utilisation ou un tarif nécessaire, l’estimation peut rester absente.

Les champs et l’enregistrement des tarifs figurent dans l’éditeur de prix ; les règles de calcul sont décrites dans la documentation des coûts.

Rassemblez les quantités par catégorie et leurs tarifs dans une même note : entrée hors cache × tarif d’entrée + lecture du cache × tarif de lecture + écriture du cache × tarif d’écriture + sortie × tarif de sortie, en ramenant chaque terme à l’unité d’un million de tokens. Si le total d’entrée inclut déjà le cache, séparez les catégories avant le calcul pour ne pas compter ces tokens une seconde fois comme entrée ordinaire. De même, ne rajoutez pas les tokens de raisonnement lorsqu’ils sont déjà compris dans la sortie. Sans ventilation par catégorie, notez l’information comme inconnue ; le total Tokens ne suffit pas à reconstituer une facture précise.

Vérifiez également la devise : dans cet éditeur, $ correspond à USD et ¥ à CNY, pas à JPY. Changer de symbole ne convertit pas les prix à un taux de change. Si votre recharge ou votre relevé bancaire est dans une devise locale, par exemple en euros, tandis que le modèle est tarifé en dollars, rapprochez d’abord les coûts des appels en dollars, puis vérifiez séparément le taux de change et les frais de recharge. N’additionnez pas directement des montants dans deux devises. Voir le code des devises et de l’enregistrement des prix.

Après avoir modifié un prix, quittez le champ, puis rouvrez le même modèle pour vérifier que la valeur a été enregistrée. Vérifiez aussi si un multiplicateur ou des règles de prix par plage horaire sont configurés pour le fournisseur : un tarif réel qui comprend déjà le multiplicateur ne doit pas être multiplié une nouvelle fois. Les anciennes requêtes conservent les prix enregistrés à leur exécution ; modifier le tarif actuel ne les recalcule pas automatiquement. Voir les règles de multiplicateur et de plage horaire et la capture des prix au moment de l’appel.

Cost vide pour une image : facturation par requête ou par image ?

Un prix par requête, un prix par image et une facturation en tokens d’image correspondent à des modes de facturation distincts. Une seule requête peut retourner plusieurs images. Un montant fixe par requête ne doit pas être saisi directement comme prix de chaque image, ni dans Input Price ou Output Price.

Dans v2.1.6, le calcul par image existe déjà dans le mécanisme interne, mais l’éditeur de prix du client de bureau n’offre pas de champ correspondant. Pour calculer localement ce coût, les prix capturés à l’exécution doivent contenir perImage, avec unit égal à image, et l’appel doit fournir imageCount. Des tarifs de tokens seuls ou une unité pixel ne suffisent pas. Voir les conditions du calcul des coûts d’image.

Si le nouveau réglage est réellement présent dans votre version et que le fournisseur facture explicitement chaque image générée, procédez ainsi :

Dans les prix du même fournisseur et du même modèle, sélectionnez Image dans Price unit.
Saisissez dans Image price le prix d’une image dans la devise correspondante. Quittez le champ, puis rouvrez le modèle pour vérifier l’enregistrement.
Laissez le champ vide si le prix est inconnu. Ne saisissez 0 que si le tarif est réellement nul : un zéro artificiel modifie l’affichage local, mais n’empêche pas le fournisseur de facturer.
Le sélecteur choisit uniquement le tarif à modifier ; les tarifs de tokens et d’images sont tous deux conservés. Il n’ajoute pas de forfait par requête et ne prend pas en charge l’estimation par pixel ou par token d’image.
Vérifiez une nouvelle génération après le changement. Une fois le résultat obtenu, notez le nombre réel d’images, l’heure de la requête et le nouveau Cost, puis comparez-les aux écritures du fournisseur. Le calcul local doit correspondre à nombre d’images générées × prix par image applicable au moment de la requête, en tenant compte des multiplicateurs ou règles horaires applicables au fournisseur. Une requête de vérification peut être facturée ; privilégiez une génération dont vous avez déjà besoin.

Ces étapes correspondent au nouvel éditeur de prix et à la fonction d’enregistrement des tarifs. Si le champ n’existe pas, utilisez pour l’instant les écritures réelles du fournisseur. Vous pourrez le configurer lorsque la version officielle que vous installez inclura explicitement cette fonction.

Une nouvelle requête peut encore ne pas avoir de Cost après la saisie du prix. Vérifiez si elle a utilisé une autre configuration de modèle, si le nombre d’images est disponible, si les données de devise sont complètes et si le contrat réel correspond bien à une tarification par image. Le traitement officiel des tâches personnalisées de génération enregistre imageCount à partir du nombre d’URL d’images retournées : le nombre de fichiers téléchargés avec succès sur votre ordinateur ne peut pas s’y substituer. Ce comptage ne garantit pas non plus la même règle de facturation chez tous les fournisseurs. Voir le code d’enregistrement des tâches d’image.

Rapprochez le débit fournisseur et conservez de quoi expliquer l’écart

Commencez par une requête terminée : c’est plus simple que de comparer directement deux totaux mensuels. Utilisez le même compte fournisseur. Si les relevés permettent de distinguer les appels par libellé ou groupe de clé, notez cette information, sans inclure la clé complète dans une capture ou une demande d’assistance.

Éléments à conserver	Côté Cherry Studio	Côté fournisseur
Identité	Version du client, configuration du fournisseur, nom affiché du modèle et ID exact correspondant	Compte réellement utilisé, ID du modèle, palier tarifaire applicable
Temps	Heure de fin de la requête et fuseau local	Heure de comptabilisation, fuseau et fenêtre couvrant le même appel
Quantités	Tokens visibles ; nombre d’images réellement retournées	Utilisation ventilée en entrée, sortie et cache ; nombre de requêtes ou d’images facturées
Montants	Cost tel quel, sa devise et les valeurs absentes	Débit réel, devise, remboursements ou ajustements visibles
Correspondance	Conversation ou fonction à l’origine de la requête	Identifiant de requête ou d’écriture de facturation fourni par le service

Si les deux côtés affichent explicitement le même ID de requête fournisseur, utilisez-le en priorité pour le rapprochement. Sinon, combinez le compte, le modèle, la fenêtre temporelle et les quantités. Les identifiants internes de Cherry Studio ont leur propre format ; ne supposez pas qu’ils sont identiques à ceux du fournisseur. Voir la structure officielle des enregistrements.

Si vous utilisez déjà BetterToken, consultez l’utilisation actuelle et l’historique des débits dans le tableau de bord, conformément aux indications officielles sur le suivi des dépenses, puis comparez modèle, heure, statut et tokens à partir des champs réellement disponibles sur la page.

Si les montants diffèrent, vérifiez dans cet ordre :

Les quantités ne correspondent pas. Vérifiez si d’autres outils utilisent le même compte ou si une action a déclenché plusieurs appels. Les nouvelles tentatives du SDK que le client ne peut pas observer n’apparaissent pas nécessairement dans Requests. Les lignes des deux côtés ne correspondent donc pas automatiquement une à une.
Les quantités correspondent, mais pas les montants. Vérifiez le modèle, l’unité par image, par requête ou par token, les règles du cache, les paliers, la devise, le multiplicateur et le tarif réel du compte. Comparez ensuite avec les prix conservés au moment de l’appel.
Le fournisseur a débité le compte, mais Cost est vide. Gardez la valeur absente et ajoutez à votre relevé « estimation impossible dans le client ; débit effectué par le fournisseur », avec le montant correspondant. Ne remplacez pas une valeur inconnue par zéro.
Le client n’a aucune ligne ou affiche un échec, mais le fournisseur a une écriture. Vérifiez d’abord les règles du fournisseur concernant la fin de l’opération, la facturation et les remboursements. Transmettez l’heure, le modèle et son identifiant de requête après retrait des données sensibles ; ne relancez pas immédiatement une série de requêtes pour reproduire le problème.

La documentation officielle décrit ces enregistrements comme des données d’analyse capturées dans la mesure du possible. Les nouvelles tentatives invisibles au client, les appels en échec et les enregistrements migrés depuis d’anciennes versions peuvent tous compliquer la comparaison des quantités. Les écritures du fournisseur font foi pour les débits réels ; demandez-lui d’expliquer toute écriture ambiguë, car un Cost vide ne permet pas de déterminer ce qui a été facturé. Voir la couverture du suivi et ses limites.

Quand la vérification est-elle terminée ?

Vous devez pouvoir conserver les deux enregistrements d’une même requête et expliquer trois points : le modèle et l’unité de facturation utilisés, l’origine connue du montant du client ou son statut d’estimation/valeur inconnue, et le débit final du fournisseur avec la raison d’un éventuel écart. Si vous avez changé un tarif local, vérifiez son enregistrement et le calcul sur une nouvelle requête. Conservez les anciennes valeurs sans attendre de recalcul automatique de l’historique.

Commencez maintenant par une requête d’image existante : notez la version, le modèle, l’heure, le nombre réel d’images, Cost et le débit fournisseur. Une fois cette ligne expliquée, élargissez la période. Si elle reste inexpliquée, transmettez les champs manquants et les données de la requête concernée au fournisseur ou au projet du client pour examen.