L'explosion des jetons agentiques : Attribution des coûts et budgets pour le code Claude en CI/CD

Lorsque les agents passent des sessions interactives aux pipelines CI/CD, le mécanisme de régulation humain disparaît et les boucles ReAct augmentent le contexte de manière quadratique. La facture du fournisseur vous indique combien vous avez dépensé. Elle ne peut pas vous dire pourquoi — ni où couper sans paralyser la vélocité.

Pourquoi le CI/CD change la donne économique

Les sessions d'IA interactives disposent d'un mécanisme de régulation intégré : l'humain devant le clavier. L'humain lit la sortie de l'agent, décide de la prochaine étape et consomme environ une invite toutes les quelques minutes. Ce rythme est une limite de débit souple même lorsqu'aucune politique ne l'impose.

Les pipelines CI/CD n'ont pas cela. Un agent configuré pour la révision automatisée de PR peut être déclenché des centaines de fois par heure par le trafic de commits ordinaire, et rien dans son environnement ne le ralentit. Le calcul est pire que ce que la fréquence de déclenchement suggère, car le coût par appel lui-même augmente — les frameworks d'agents comme ReAct ajoutent le résultat de chaque action dans la fenêtre de contexte avant l'étape de raisonnement suivante. La consommation de jetons par exécution d'agent augmente approximativement en O(n²) par rapport au nombre d'étapes.

.

‍

L'angle mort de la facturation du fournisseur

Les tableaux de bord d'Anthropic et d'OpenAI vous indiqueront exactement combien de jetons votre organisation a consommés mardi dernier. Ils ne vous diront pas pourquoi. Le fournisseur n'a pas de contexte applicatif — il ne peut pas distinguer un pipeline de données de production critique du projet annexe en boucle infinie d'un ingénieur junior. Les deux sont facturés de la même manière.

Sans attribution granulaire, la finance recourt au seul outil disponible : les interdictions générales. L'utilisation de l'IA est suspendue en attendant un examen. Les charges de travail légitimes sont ralenties au même titre que les charges incontrôlées. Les responsables de l'ingénierie apprennent à redouter le moment de la clôture mensuelle. Le problème fondamental est que l'attribution doit se faire à l'ingestion, et non à la facturation — au moment où la facture arrive, les étiquettes dont vous aviez besoin ont disparu.

La facture du fournisseur répond à la question « combien ». Le registre attribué par la passerelle répond à la question « quel dépôt, quel pipeline, quelle étape d'agent et quoi corriger ». Cette différence transforme une crise financière en un ticket d'ingénierie.

Étiquetage des métadonnées au niveau de la passerelle

La base de l'attribution des coûts est l'étiquetage obligatoire au niveau de la passerelle. Chaque requête provenant d'un pipeline CI/CD injecte un petit objet JSON via l'en-tête X-TFY-METADATA, identifiant l'équipe, le dépôt, le pipeline, l'étape de l'agent et le centre de coûts responsable. La structure est simple, délibérée et identique pour chaque équipe :

HTTP · en-tête requis pour chaque requête CI

X-TFY-METADATA: {
  "team":         "payments-platform",
  "repo":         "transaction-service",
  "pipeline":     "pr-security-audit",
  "agent_step":   "step-2-policy-check",
  "cost_center":  "eng-backend",
  "environment":  "production"
}

Les étiquettes sont obligatoires, non facultatives. Les requêtes non étiquetées sont rejetées à la passerelle, et non passées silencieusement. C'est la politique qui produit une observabilité à 100 % — il n'y a pas de catégorie « inconnue » dans le tableau de bord, car il n'y a pas de chemin qui en produise une. Le coût de l'application est une règle Cedar/OPA. Le coût de la non-application est une escalade financière trimestrielle.

‍

‍

Grâce aux balises, la passerelle compte les jetons d'entrée, de sortie et mis en cache pour chaque appel, évalue le coût du résultat en fonction des tarifs actuels du fournisseur et enregistre une entrée de grand livre entièrement attribuée. Les vues de coûts sont ventilées par utilisateur, modèle et équipe, prêtes à l'emploi, avec une option « Télécharger les données brutes » qui vous permet d'exporter avec des champs de regroupement personnalisés (nom d'utilisateur, nom du modèle, équipes ou toute clé de métadonnée que vous avez balisée). Chaque dépense est identifiée.

Budgets par projet avec disjoncteurs

Un tableau de bord sans application des règles ne sert à rien. TrueFoundry associe des budgets hiérarchiques à application mathématique stricte à chaque centre de coûts produit par le balisage. Les budgets sont une liste ordonnée de règles, chacune étant définie par des sujets, des modèles ou des clés de métadonnées. Deux sémantiques distinguent les règles budgétaires des règles de limitation de débit, et il est important de les comprendre précisément :

• Le suivi budgétaire s'effectue pour chaque règle correspondante. Si une requête correspond à trois règles, le coût est débité sur les trois. Les budgets superposés — un budget d'équipe de 500 $ en plus d'un budget de 50 $ par dépôt, lui-même en plus d'un budget de 10 $ par développeur — restent tous synchronisés simultanément.
• Les décisions d'autorisation/de blocage proviennent uniquement de la première règle correspondante. Les règles sont évaluées de haut en bas, et la première dont les conditions correspondent décide si la requête est acceptée ou rejetée. Placez les dérogations de haute priorité en haut, les valeurs par défaut en bas.

Les alertes budgétaires se déclenchent à quatre seuils configurables — 75 %, 90 %, 95 % et 100 % du plafond — avec des canaux de notification pour les e-mails, les webhooks Slack et les bots Slack. La vérification est effectuée toutes les 20 minutes par rapport au dernier grand livre attribué :

Tableau 1 — Seuils budgétaires. Chaque seuil se déclenche une fois par période budgétaire (jour / semaine / mois) et se réinitialise au début de la période suivante. Les alertes sont vérifiées toutes les 20 minutes.

Le comportement à 100 % fait partie de la conception, ce n'est pas une fonctionnalité ajoutée a posteriori. La passerelle renvoie une erreur structurée qui nomme le budget épuisé et oriente l'opérateur vers le tableau de bord :

JSON  ·  Réponse 429 en cas de plafond strict

{
  "error":      "Budget Exceeded",
  "rule_id":    "transaction-service-daily",
  "detail":     "Repository \"transaction-service\" has exhausted its
                 daily $50 AI budget at 14:32 UTC.",
  "mitigation": "Review pipeline logs for infinite loops or request a
                 quota increase via the platform team.",
  "dashboard":  "https://gateway.example.com/budgets/transaction-service"
}

Un pipeline qui atteint son budget devrait savoir quoi faire ensuite sans que le développeur ait à solliciter l'équipe plateforme pour obtenir du contexte. Les runners CI interprètent le 429 comme un signal de repli standard ; la compilation échoue proprement avec un message exploitable plutôt que de planter de manière confuse.

Il y a un autre comportement à connaître : le mode audit. Définir block_on_budget_exceed: false sur n'importe quelle règle maintient le suivi et les alertes actifs, mais laisse passer les requêtes. C'est le bon réglage par défaut pendant le premier mois de déploiement. Observez les alertes se déclencher contre des plafonds simulés ; ajustez les plafonds ; et seulement ensuite activez l'application. Ignorer le mode audit, c'est se réveiller avec une équipe en colère dont tous les pipelines ont échoué à 03h00.

YAML  ·  configuration de budget superposé

name: cicd-budget
type: gateway-budget-config
rules:
  - id: "ml-team-override"
    when: { subjects: ["team:ml-engineering"] }
    limit_to: 200
    unit: cost_per_day
    budget_applies_per: ["user"]
  - id: "default-user-daily"
    when: {}
    limit_to: 10
    unit: cost_per_day
    budget_applies_per: ["user"]
  - id: "per-repo-daily"
    when: {}
    limit_to: 50
    unit: cost_per_day
    budget_applies_per: ["metadata.repo"]
    alerts:
      thresholds: [75, 90, 100]
      notification_target:
        - type: slack-webhook
          notification_channel: "ai-budget-alerts"

Créer un tableau de bord d'attribution des coûts

Les données balisées qui transitent vers la couche de métriques de la passerelle permettent à l'équipe plateforme de créer des tableaux de bord qui répondent aux questions d'attribution au lieu de produire davantage de bruit agrégé. Au lieu de fixer un pic et de demander « qui a fait ça ? », le tableau de bord vous indique déjà qu'à 02h00 UTC, l'équipe frontend a déployé un nouvel agent sur react-monorepo qui a halluciné une dépendance manquante et est entré dans une boucle de résolution de 400 étapes.

Ce type de contexte opérationnel transforme le coût d'un problème financier en un problème d'ingénierie. Une fois que vous constatez que le passage de l'étape initiale de résumé de code de Sonnet à Haiku réduit le coût de cette étape de 80 % sans affecter la qualité de la révision des PR, vous effectuez le changement. Vous ne discutez pas des plafonds budgétaires en comité de pilotage. Les vues de suivi des coûts de TrueFoundry sont livrées prêtes à l'emploi pour les perspectives Utilisateur, Modèle et Équipe, et l'exportation de données brutes vous permet de filtrer sur n'importe quelle clé de métadonnée — ainsi, une vue par dépôt, par pipeline ou par étape d'agent est un téléchargement en un clic, et non un projet d'ingénierie de données.

‍

‍

Prévision des dépenses mensuelles avant l'arrivée de la facture

Les données de balisage agrégées rendent également la prévision plus gérable. Les charges de travail agentiques sont irrégulières — les tâches CI lourdes et périodiques dominent la facture — c'est pourquoi de simples moyennes glissantes sous-estiment systématiquement les dépenses. La moyenne des 7 derniers jours est une mauvaise prévision pour une charge de travail dont le 95e centile est 4 fois supérieur à sa moyenne.

Le bon modèle est une prévision glissante P95, exécutée par dépôt et par équipe. La P95 saisit le risque de pic que la moyenne tend à lisser, projetant les dépenses de fin de mois avec suffisamment d'anticipation pour ajuster les budgets, augmenter les quotas ou arrêter un pipeline problématique avant que les finances ne soient surprises. Le mot clé est « surprise » : cette prévision est conçue pour les éviter. En pratique, une prévision P95 sur 7 jours a suivi les dépenses réelles de fin de mois avec une précision de 8 à 12 % sur les charges de travail que nous avons mesurées — suffisamment précis pour agir, et bien meilleur que l'alternative de la moyenne glissante.

Un exemple concret : 8 400 $ → moins de 800 $

Une organisation de 50 ingénieurs a développé un agent de révision de code Claude en trois étapes qui s'exécutait sur chaque pull request : (1) résumer le diff, (2) examiner le diff par rapport aux politiques de sécurité via un serveur de documentation MCP, (3) suggérer des modifications de code. Architecture sensée, flux de travail utile, aucun signal d'alarme évident.

À raison d'environ 15 PR par ingénieur et par semaine, en tenant compte des tentatives et du coût de la fenêtre contextuelle lié à l'injection de fichiers entiers dans les invites, l'agent a consommé en moyenne environ 400 000 jetons d'entrée par PR. Facture du premier mois pour l'automatisation CI/CD : 8 400 $.

Tableau 2 — Explication détaillée d'un débogage d'attribution des coûts. Cinq clics sur la passerelle, un changement de configuration. Sans attribution, la réponse aurait été une interdiction générale de Sonnet pour les flux de travail CI. Avec attribution, la réponse a été une modification de configuration d'une seule ligne.

Cet écart — entre « interdire le modèle » et « mettre en cache une invite » — représente tout l'intérêt d'une attribution correcte. Les données de coût existent de toute façon ; la question est de savoir si vous disposez des étiquettes pour les interpréter.

FAQ

Les budgets doivent-ils être exprimés en dollars ou en jetons ?

Les deux, simultanément. Les dollars s'alignent sur la finance et la planification opérationnelle. Les jetons sont la métrique d'ingénierie qui permet de déboguer l'efficacité des invites. TrueFoundry suit les deux — la finance gère les tableaux de bord en dollars, l'ingénierie gère les tableaux de bord en jetons, et la passerelle est la source de vérité pour les deux. Les changements de prix des fournisseurs sont absorbés au niveau des dollars sans que l'ingénierie n'ait à refactoriser quoi que ce soit ; les nouvelles optimisations sont absorbées au niveau des jetons sans que la finance n'ait besoin de connaître le nom du modèle.

Que se passe-t-il lorsqu'une limite stricte est atteinte en cours de pipeline ?

Le pipeline reçoit une erreur 429 avec le message descriptif affiché précédemment et un lien vers le tableau de bord des budgets. Les exécuteurs CI interprètent le 429 comme un signal de repli standard ; la compilation échoue proprement avec un message exploitable plutôt que de planter de manière confuse. Les augmentations de quota sont enregistrées comme des tickets standard auprès de l'équipe plateforme — l'URL du tableau de bord dans le corps de l'erreur court-circuite la série habituelle de « Je ne comprends pas pourquoi cela échoue ».

Le balisage obligatoire ralentit-il le déploiement ?

En pratique, non — les wrappers du SDK gèrent l'injection automatiquement à l'intérieur des modèles CI, de sorte que les développeurs individuels n'ont jamais à modifier les en-têtes. Le coût unique est la mise à jour des modèles de pipeline de l'équipe ; le coût récurrent est nul. Le bénéfice récurrent se manifeste dans chaque tableau de bord, chaque alerte et chaque analyse post-mortem qui en découle.

Quelle est la différence entre les limites de débit et les limites budgétaires — quand utiliser l'une ou l'autre ?

Les limites de débit arrêtent les pics ; les limites budgétaires arrêtent les dépenses. Les limites de débit sont exprimées en requêtes/minute ou jetons/minute — elles protègent les services en aval contre la surcharge et sont évaluées par requête. Les budgets sont exprimés en dollars par jour/semaine/mois — ils protègent le portefeuille de l'entreprise et sont évalués par rapport au grand livre cumulatif. La plupart des piles de production exécutent les deux, avec des portées différentes. Les modèles sont complémentaires, pas redondants.

‍

‍