# Comment fixer une limite de dépense stricte pour une tâche d'agent de code ? > Une limite stricte doit être appliquée avant chaque appel de modèle ou d'outil payant par une passerelle qui contrôle le budget de la tâche. Réservez le coût maximal, rapprochez l'usage réel, refusez ce qui ne tient pas dans le solde et arrêtez l'agent avec un point de reprise utile. # Comment fixer une limite de dépense stricte pour une tâche d'agent de code ? Un budget strict relève du contrôle d'admission. Avant tout appel facturable, une passerelle fiable doit prouver que le pire coût autorisé tient dans le solde restant. Les alertes après usage ne peuvent arrêter un dépassement déjà produit. Incluez entrée, sortie maximale, tentatives, replis, sous-agents, embeddings, recherches, sandboxes et tout outil payant. ## Séparer limite stricte et objectif souple Utilisez trois valeurs : | Contrôle | But | Comportement | |---|---|---| | Objectif | Coût attendu | Alerter ou choisir un plan moins cher | | Limite souple | Seuil d'escalade | Demander validation ou réduire la qualité | | Limite stricte | Dépense maximale autorisée | Refuser avant le prochain appel | Exemple : objectif $0.60, validation à $0.90, arrêt à $1.00. La limite stricte doit vivre côté serveur, pas seulement dans le prompt. ## Faire passer toute action payante par une passerelle Donnez à l'agent des identifiants courts qui n'appellent que votre passerelle. Elle attache `task_id`, consulte le budget, estime l'action et réserve ou refuse. N'exposez pas une clé permettant de contourner la comptabilité. Appliquez la même règle à la recherche, au sandbox, à l'exécution et à la récupération payante. ## Réserver avant et rapprocher après Estimez le maximum à partir des tokens d'entrée et de la sortie autorisée. Réservez atomiquement, appelez, puis remplacez la réservation par l'usage réel. ```text remaining = hard_limit - committed_cost - open_reservations worst_case = input_cost + max_output_cost + tool_allowance if worst_case > remaining: reject("task_budget_exceeded") else: reserve(worst_case) call_provider() reconcile(actual_cost) ``` La réservation atomique empêche deux sous-agents de consommer le même solde. ## Tarifer avec une grille versionnée Conservez le prix utilisé avec chaque estimation. Les tarifs changent ; un rapport ultérieur ne doit pas recalculer le passé au prix actuel. Si le fournisseur renvoie le coût final, gardez estimation et montant. S'il ne renvoie que des tokens, utilisez la grille choisie avant l'appel. Ajoutez une marge pour les outils incertains ou refusez ce qui ne peut être borné. ## Sécuriser le streaming Réservez toute la sortie permise avant d'ouvrir le flux. Rapprochez l'usage disponible, mais ne supposez pas que fermer le client stoppe immédiatement la facturation. L'annulation est une optimisation, pas la frontière de contrôle. Fixez sortie maximale et délai par appel. Le plafond de tâche couvre tous les flux, tentatives et replis. ## Inclure tentatives et sous-agents Chaque tentative débite le même registre parent. Un nouveau budget à chaque tentative annule la limite. Utilisez des budgets hiérarchiques : | Registre | Limite | Règle | |---|---:|---| | Tâche parente | $1.00 | Plafond absolu | | Sous-agent d'implémentation | $0.55 | Ne dépasse pas le solde parent | | Sous-agent de test | $0.25 | Rend la réservation inutilisée | | Revue finale | $0.20 | Ne s'exécute que s'il reste du solde | Les limites enfants sont des allocations, pas de l'argent supplémentaire. ## S'arrêter avec un point de reprise utile Si l'action ne tient pas, renvoyez une erreur typée et ne retentez pas l'appel refusé. Produisez avec le contexte présent un point de reprise contenant : * modifications terminées et tests ; * travail restant et action bloquée ; * état actuel du dépôt ; * budget supplémentaire estimé ; * jeton de reprise ou ID de tâche. L'arrêt devient ainsi un transfert contrôlé. ## Utiliser les contrôles fournisseur en secours Les limites de compte réduisent le rayon d'impact, mais sont rarement précises par tâche. Elles peuvent agréger plusieurs dépôts, se mettre à jour tard ou omettre les outils. Avec une passerelle multimodèle comme Atlas Cloud, gardez le registre faisant foi dans votre orchestration et enregistrez les ID d'usage pour le rapprochement. Le plafond survit aux changements de modèle. ## Tester la limite comme un contrôle financier Testez concurrence, longs flux, délais, usage absent, tentatives, replis et panne du registre. Refusez par défaut si le service budgétaire tombe. Coûts confirmés plus réservations ne doivent jamais dépasser le plafond. ## Conclusion Une vraie limite s'applique avant la dépense, avec réservations atomiques et un registre couvrant toute action facturable. Un système qui alerte après usage fait de la surveillance, pas un plafond strict. ## FAQ ### max_tokens est-il une limite monétaire stricte ? Non. Il limite une réponse, pas le coût total, les tokens d'entrée, les tentatives, les changements de modèle ou les outils payants. Une limite monétaire exige un registre couvrant chaque action facturable. ### Où faut-il appliquer le budget de l'agent ? Dans une passerelle serveur ou une couche d'orchestration par laquelle passent tous les appels payants. Les compteurs côté client peuvent être contournés ou subir des courses en concurrence. ### Comment budgéter une réponse en streaming ? Réservez le coût de sortie maximal avant d'ouvrir le flux, puis rapprochez l'usage déclaré à la fermeture. Annulez chez le fournisseur si possible, sans dépendre uniquement de cette annulation. ### Les nouvelles tentatives partagent-elles le budget d'origine ? Oui. Tentatives, replis, sous-agents et évaluations débitent le même registre sauf approbation explicite d'un budget séparé. ### Que faire lorsque le solde est insuffisant ? Refusez l'appel facturable suivant et demandez un point de reprise à partir du contexte présent, avec travail terminé, éléments restants et budget supplémentaire requis. ### Les limites du compte fournisseur peuvent-elles remplacer la limite par tâche ? Généralement non. Elles protègent tout le compte et peuvent être asynchrones. Une passerelle par tâche isole immédiatement ; la limite de compte reste une protection secondaire.