Suivi de l’utilisation

Les statistiques des sessions sont reconstruites à partir des données conservées par les CLI des agents. AirCode Ø ne redécoupe pas vos prompts en tokens. Cette vue n’est ni une facture du fournisseur ni un compteur de quota du compte : elle montre l’activité que les transcriptions locales permettent de vérifier.

Comprendre les différentes catégories de tokens

L’entrée correspond à tout ce que voit le modèle lors d’un appel : historique de la conversation, résultats des outils, instructions système et contexte ajouté. Elle ne se limite pas au dernier message de l’utilisateur. Une longue session peut donc traiter plusieurs fois le même contexte.

N’ajoutez pas automatiquement les tokens de raisonnement aux autres lignes. Certains fournisseurs les incluent dans la sortie ou dans le total natif ; d’autres les présentent comme une catégorie facturable distincte. AirCode Ø conserve ce nombre pour le diagnostic et ne l’ajoute aux totaux et aux coûts que s’il n’est pas déjà inclus par le fournisseur.

Certaines CLI comptent les tokens en cache dans leur nombre de tokens d’entrée. AirCode Ø isole d’abord cette partie : Input + Cached input représente donc l’ensemble du prompt sans compter deux fois les tokens en cache.

Origine des chiffres

La transcription ou le journal d’utilisation conservé par la CLI fait foi. AirCode Ø normalise les données propres à chaque moteur avant de les additionner :

• les blocs de réponse Claude portant le même identifiant de message ne sont comptés qu’une fois ;
• les compteurs cumulatifs de Codex sont convertis en différences par appel, et les événements liés uniquement à la compression du contexte sont ignorés ;
• les messages Gemini réécrits ou annulés ne contribuent qu’à hauteur de leur état logique final ;
• les lectures et les écritures du cache Kimi restent distinctes pour calculer le prix, même si l’interface les regroupe ;
• les mises à jour détaillées des prompts Grok/ACP utilisent la dernière valeur de chaque prompt. Un relevé qui ne donne que le total reste enregistré, mais peut être sans tarif si ses catégories sont inconnues.

Si plusieurs processus reprennent une session avec le même moteur et le même identifiant natif, AirCode Ø les traite comme une seule session logique. Il utilise la transcription la plus complète, sans additionner les doublons.

Attribution à la plateforme cliente

Chaque nouveau lancement enregistre un type de client : Web, Application mobile, Application de bureau, Automatisation ou API. Cette valeur est enregistrée localement avec les métadonnées de la session dans sessions.json, ajoutée au journal structuré de lancement et exposée dans local.clientPlatforms par GET /api/usage. AirCode Ø n’enregistre pas l’en-tête User-Agent brut pour cela. Dans Utilisation de l’IA, la section Utilisation par application affiche les sessions, les tokens, leur part et le coût équivalent en API sur la période choisie : 7 jours, 30 jours, période personnalisée ou totalité de l’historique.

Les tokens et les coûts sont attribués à la première plateforme de lancement connue de la session logique. La reprise d’une session sur un autre appareil n’en double donc pas les chiffres. Les métadonnées conservent aussi la plateforme de chaque lancement, pour permettre l’analyse des reprises entre appareils. Une session créée par un ancien client apparaît sous Inconnu si sa plateforme ne peut pas être déterminée de façon fiable.

Calcul du coût

Quand une CLI fournit un coût, AirCode Ø conserve ce montant sous l’étiquette Coût indiqué par le fournisseur. Sinon, il calcule un Coût estimé, équivalent API à partir du catalogue des prix publics livré avec la version installée d’AirCode Ø :

cost =
  (uncached input × input rate
   + cache reads × cached-input rate
   + cache writes × cache-write rate
   + billable output × output rate)
  / 1,000,000

Les tokens de raisonnement signalés en dehors de la sortie sont facturés comme des tokens de sortie, une seule fois. Si un fournisseur applique un tarif aux longs contextes, AirCode Ø choisit ce tarif pour chaque appel au modèle selon la taille du prompt complet (Input + Cached input).

Les étiquettes sous le coût ont un sens précis :

• Indiqué par le fournisseur : la CLI a fourni le montant.
• Estimé, équivalent API : AirCode Ø a appliqué les tarifs publics de l’API.
• Indiqué et estimé : le total combine ces deux sources.
• Partiel ou Sans tarif : au moins un relevé contenant des tokens ne pouvait pas être chiffré de façon fiable. Un modèle inconnu ne reçoit jamais un tarif deviné à partir d’une famille de modèles.

L’estimation équivalente en API ne correspond pas nécessairement à votre facture. Les abonnements, crédits, tarifs négociés, offres gratuites, ajustements du fournisseur et taxes ne sont pas inclus dans ce calcul.

AirCode Ø additionne les coûts avec toute leur précision avant l’affichage. L’interface affiche normalement deux décimales, jusqu’à quatre sous un dollar et jusqu’à six sous un centime. La somme des montants arrondis affichés sur chaque ligne peut donc différer légèrement du total de la session.

Attribution par question

Le suivi des questions utilise des bornes de mesure, sans estimer la taille des prompts :

1. Juste avant la livraison réussie d’un prompt, AirCode Ø enregistre l’utilisation cumulative de la session comme point de départ.
2. À la fin du tour, à l’arrêt du processus ou au début d’un prompt de suivi, AirCode Ø relève de nouveau les compteurs.
3. La question reçoit la différence positive ou nulle entre les deux relevés.

Un message de suivi envoyé pendant que l’agent travaille encore ferme la question précédente à ce moment-là avec le résultat Fermée par un suivi. Les différences négatives sont ramenées à zéro : une transcription réécrite ou tronquée ne peut pas créer une utilisation négative.

L’activité non attribuée de la session correspond à :

complete session total − sum of tracked questions

Elle comprend souvent le démarrage, l’utilisation antérieure à ce suivi ou une activité qu’il est impossible de rattacher à un prompt précis. Elle reste incluse dans le total de la session.

Le journal de suivi conserve un aperçu et un hash du prompt pour identifier la question ; il ne duplique pas le prompt complet déjà présent dans la transcription native.

Durée d’exécution et mises à jour en direct

La durée d’exécution mesure le temps écoulé entre la livraison d’un prompt et la fin du tour. Les périodes d’inactivité entre les tours sont exclues. Pour un tour en cours, elle va jusqu’au dernier relevé : la durée et les tokens peuvent changer tant que la fenêtre reste ouverte.

Les anciennes sessions peuvent avoir des totaux de tokens complets sans historique par question, car ce suivi n’est pas reconstruit rétroactivement. Les statistiques peuvent aussi être indisponibles si la transcription native manque ou a été supprimée. Pour un litige de facturation ou une limite de compte, consultez les données du fournisseur, qui font autorité.

Compteurs des limites du compte

Les compteurs en haut des cartes de fournisseurs, dans Utilisation de l’IA, montrent les quotas du compte, distincts du calcul à partir des transcriptions. AirCode Ø les lit depuis l’API du fournisseur et met la réponse en cache pendant quelques minutes. Plusieurs appareils ouverts partagent ainsi un appel au lieu d’interroger chacun le service.

Ce cache explique pourquoi un écran laissé ouvert peut afficher une valeur en retard après une session intensive. Le bouton d’actualisation de chaque carte demande immédiatement de nouvelles valeurs à l’API du fournisseur. Le bouton Actualiser en haut de la page fait de même pour tous les comptes connectés, tout comme le geste de rafraîchissement sur mobile.

Si l’API limite les requêtes, l’actualisation conserve les dernières valeurs connues et affiche la raison sur la carte. Appuyer plusieurs fois utilise la réponse en cache au lieu de multiplier les appels au fournisseur, sans prolonger le délai de nouvelle tentative automatique qui protège les vérifications en arrière-plan.