Gérer les coûts

Ce guide vous montre comment voir ce que coûtent les exécutions d’agents et comment plafonner une exécution autonome.

Comment les coûts sont enregistrés

Chaque exécution d’agent écrit un journal d’exécution qui porte ses jetons d’entrée, ses jetons de sortie, ses jetons de raisonnement, ses jetons de lecture en cache et d’écriture en cache, un coût estimé en cents et le coût des sous-agents qu’elle a lancés.

Les tarifs proviennent du catalogue models.dev, qui sert uniquement à enrichir la liste des modèles avec un prix et une fenêtre de contexte — jamais comme source d’identifiants de modèles. Un modèle que le catalogue ne peut pas tarifer est enregistré à 0 $ et les exécutions à coût nul sont exclues du récapitulatif Utilisation et coût. Un modèle Ollama local n’affiche donc aucune dépense, même si ses compteurs de jetons restent enregistrés. Un forfait à tarif fixe (kimi-code, un abonnement Claude) se comporte de la même façon uniquement lorsque le catalogue n’a pas de prix pour le modèle servi ; s’il en a un, l’exécution est quand même estimée à ces tarifs. Avec une chaîne de repli, l’exécution est tarifée d’après le modèle qui l’a réellement servie, et non celui qui a été demandé.

Voir ce que vous dépensez

Observabilité → Aperçu

Ouvrez-la depuis le pied de la barre latérale → Observabilité. L’onglet Utilisation s’ouvre en premier (totaux de jetons cumulés) ; basculez sur Aperçu — le deuxième onglet — pour la surface de coûts principale :

Un sélecteur de période : dernières 24 heures, 7 derniers jours, 30 derniers jours ou tout l’historique
Des filtres à facettes sur l’agent, le modèle, le statut et le rôle, sous forme de puces supprimables
Une bande d’indicateurs : exécutions totales, coût total, taux d’erreur, taux de cache, jetons par seconde, latence moyenne et délai avant le premier jeton, chacun avec une variation par rapport à la période précédente (masquée sur « Tout »)
Des graphiques d’activité et de coût, ainsi qu’une répartition Coût par rôle qui découpe les dépenses entre l’agent principal, ses sous-agents et son conseiller
Un tableau par agent trié par coût, les dix premiers avec une bascule pour tout afficher. Toucher une ligne filtre toutes les autres surfaces sur cet agent
Le journal d’exécution granulaire, qui ancre un tiroir de transcription pour une exécution sélectionnée

Paramètres → Serveur → Fournisseurs de modèles

La carte Utilisation et coût de cette page affiche les sept derniers jours de dépenses observées sous la forme d’un seul montant en dollars, avec une répartition par fournisseur et, lorsqu’un fournisseur en publie un, le temps restant avant la réinitialisation de la prochaine fenêtre de quota.

Les exécutions d’un seul agent

Paramètres → Espace de travail → Agents → sélectionnez un agent → Journaux liste ses exécutions avec leur statut, leur durée, leurs heures de début et de fin, leur PID et leur adaptateur. Cet onglet n’affiche pas le coût — utilisez pour cela le tableau par agent dans Observabilité → Aperçu.

Plafonner une exécution autonome

Deux commandes slash, saisies dans le compositeur d’un espace, sont les seules exécutions dotées d’un plafond de dépenses :

/goal ship the auth refactor --budget 20
/loop keep the flaky tests green

Chaque segment d’une exécution /goal ou /loop s’arrête lorsque ses dépenses tarifées atteignent 500 cents (5,00 $). À 80 % de ce montant, la boucle oriente d’abord le modèle pour qu’il conclue et laisse une passation propre, afin qu’elle ne meure pas en pleine tâche.
Un objectif durable entier est plafonné à 5 000 cents (50,00 $), sauf si vous passez --budget <dollars>. Le superviseur propage le budget restant de l’objectif dans chaque segment, de sorte qu’un budget explicite n’est jamais dépassé d’un segment entier.
--days N ajoute une échéance en temps réel et --max N un plafond de nombre d’exécutions. Les deux sont facultatifs ; sans eux, l’objectif n’est borné que par le coût.
Un objectif qui heurte son plafond s’arrête à budgetExhausted et ne peut être repris qu’en augmentant le budget.

Comme le plafond repose sur une tarification, un modèle que le catalogue ne peut pas tarifer ne l’atteint jamais. Une telle exécution est plutôt bornée par le garde-fou de répétition contre les boucles infernales, par l’abandon du superviseur après trois échecs consécutifs et par vous.

Un message dans un espace, une @-mention ou une étape de pipeline n’a aucun plafond de dépenses. L’exécution se termine lorsque le modèle s’arrête, lorsque vous l’arrêtez, ou lorsque le garde-fou contre les boucles infernales la réoriente.

Réduire la consommation de jetons

Compacter une longue conversation

Saisissez /compact dans le compositeur de l’espace. La commande est interceptée côté client et n’arrive jamais dans la transcription ; le serveur replie l’historique plus ancien dans un résumé ancré et la conversation se poursuit sur le contexte compacté.

Le compactage est refusé pendant qu’un agent est au milieu d’un tour et lorsqu’il n’y a rien d’assez ancien à replier. Le harnais intégré compacte aussi de lui-même à mesure que l’historique approche de la fenêtre de contexte du modèle.

Choisir délibérément le niveau d’effort

L’Effort de raisonnement d’un agent (Paramètres → Espace de travail → Agents) propose les niveaux que publie le modèle sélectionné. Les niveaux plus élevés dépensent davantage de jetons de raisonnement. Réservez les niveaux les plus hauts au travail qui les exige.

Choisir le modèle par agent

Le modèle est un champ propre à chaque agent : un agent de mise en forme ou de tri peut donc tourner sur un modèle bon marché, tandis qu’un agent d’architecture tourne sur un modèle coûteux. Filtrez le tableau par agent d’Observabilité → Aperçu par modèle pour voir quelle combinaison vous coûte réellement.

Repérer les exécutions aux compteurs de jetons disproportionnés

Ouvrez le journal d’exécution d’Aperçu (les 50 exécutions filtrées les plus récentes) et le tiroir de transcription sur tout ce qui sort de l’ordinaire. Les causes courantes sont un prompt système ou une persona trop longs, un contexte qui aurait dû être compacté et une tâche qui aurait dû être plusieurs tâches plus petites.

Ce qui se passe lorsqu’un budget est défini hors circuit

Pour être complet, si monthlyBudgetCents ou une politique budgétaire est écrit directement dans la ligne d’un agent :

Les budgets sont évalués après la fin d’une exécution, et non avant le lancement. Un écouteur sur la fin d’exécution compare les dépenses de l’agent depuis le début du mois à son plafond.
Le franchissement du seuil souple (80 % par défaut) enregistre un incident d’avertissement et déclenche un événement BudgetThresholdCrossed sur lequel vous pouvez brancher un déclencheur de pipeline.
L’épuisement du budget enregistre un incident dur, déclenche le même événement et bascule le statut de cycle de vie de l’agent sur paused.
Le bloc de pré-lancement existe, mais il n’est consulté que par le nettoyeur des exécutions orphelines et le réconciliateur des tickets bloqués lors de la planification d’une reprise — un lancement normal ne l’atteint jamais et rien sur le chemin de lancement ne vérifie le statut paused. Le seul signal visible est le badge de cycle de vie dans l’organigramme.

Guides connexes

Concepts connexes

Cycle de vie du lancement d’un agent