Gérer les coûts

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

Comment les coûts sont consignés

Chaque exécution d’agent écrit un journal d’exécution qui consigne 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 prix proviennent du catalogue models.dev, qui ne sert qu’à enrichir la liste des modèles avec le prix et la fenêtre de contexte — jamais comme source d’identifiants de modèle. Un modèle que le catalogue ne peut pas tarifer consigne 0 $ et les exécutions à coût nul sont exclues du résumé Utilisation et coût. Un modèle Ollama local n’affiche donc aucune dépense, même si ses nombres de jetons sont tout de même consignés. Un forfait à tarif fixe (kimi-code, un abonnement Claude) est traité 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 tout de même estimée à ces tarifs. Dans une chaîne de repli, le coût de l’exécution est calculé selon le modèle qui l’a réellement servie, et non selon celui qui a été demandé.

Voir ce que vous dépensez

Observabilité → Aperçu

Pour y accéder : pied de la barre latérale → Observabilité. L’onglet Utilisation s’ouvre en premier (totaux de jetons depuis le début) ; passez à Aperçu — le deuxième onglet — pour la principale surface de coûts :

Un sélecteur de période : dernières 24 heures, 7 derniers jours, 30 derniers jours ou tout
Des filtres à facettes sur l’agent, le modèle, le statut et le rôle, sous forme de puces supprimables
Un bandeau 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 pour « Tout »)
Des graphiques d’activité et de coût, ainsi qu’une répartition coût par rôle qui ventile 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 commande pour tout afficher. Toucher une ligne filtre toutes les autres surfaces sur cet agent
Le journal d’exécution détaillé, qui ouvre un volet 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 dépenses observées des sept derniers jours sous forme d’un seul montant en dollars, avec une répartition par fournisseur et, lorsqu’un fournisseur en publie une, 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 énumère ses exécutions avec le statut, la durée, les heures de début et de fin, le PID et l’adaptateur. Cet onglet n’affiche pas le coût — utilisez pour cela le tableau par agent d’Observabilité → Aperçu.

Plafonner une exécution autonome

Deux commandes slash, saisies dans le composeur d’un espace, sont les seules exécutions soumises à 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 calculées atteignent 500 cents (5,00 $). À 80 % de ce montant, la boucle oriente d’abord le modèle vers la conclusion, en lui demandant de laisser une transmission propre, afin qu’il ne meure pas en pleine tâche.
Un objectif durable entier est plafonné à 5000 cents (50,00 $), à moins de passer --budget <dollars>. Le superviseur transmet le budget restant de l’objectif à 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 du nombre d’exécutions. Les deux sont facultatifs ; sans eux, l’objectif n’est borné que par le coût.
Un objectif qui atteint son plafond s’arrête à budgetExhausted et ne peut être repris qu’en augmentant le budget.

Comme le plafond est calculé selon les prix, 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 anti-boucle, 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 anti-boucle l’oriente.

Réduire la consommation de jetons

Compacter une longue conversation

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

La compaction est refusée 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 publiés par le modèle sélectionné. Les niveaux plus élevés consomment plus de jetons de raisonnement. Réservez les niveaux supérieurs aux tâches qui les exigent.

Choisir le modèle par agent

Le modèle est un champ propre à chaque agent : un agent de formatage ou de triage peut donc fonctionner sur un modèle économique, tandis qu’un agent d’architecture fonctionne sur un modèle coûteux. Filtrez par modèle le tableau par agent d’Observabilité → Aperçu pour voir quelle association vous coûte réellement.

Repérer les exécutions au nombre de jetons démesuré

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

Ce qui se passe si un budget est défini hors bande

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 de 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) consigne un incident d’avertissement et déclenche un événement BudgetThresholdCrossed auquel vous pouvez rattacher un déclencheur de pipeline.
L’épuisement du budget consigne un incident grave, déclenche le même événement et bascule le statut de cycle de vie de l’agent à paused.
Le blocage avant lancement existe, mais il n’est consulté que par le récupérateur d’exécutions orphelines et le réconciliateur de tickets bloqués au moment de planifier une reprise — un lancement normal ne l’atteint jamais, et rien sur le chemin de lancement ne vérifie le statut en pause. Le seul signal visible est la pastille de cycle de vie dans l’organigramme.

Guides connexes

Concepts connexes

Cycle de vie du lancement d’un agent