7 règles Claude Code pour limiter les dépenses des agents autonomes en 2026

Découvrez comment utiliser le service dans la documentation Ailoot.

Où va l’argent : 3 catégories de dépenses pour un agent autonome ?#

Ne confondez pas ces trois canaux : ils fonctionnent indépendamment et nécessitent des réglages différents :

1. Jetons LLM. Claude, OpenAI ou Gemini facturent le contexte d’entrée et de sortie de chaque requête. Les Anthropic Task Budgets (voir la règle 2) et un abonnement plutôt que le paiement à l’usage de l’API peuvent aider dans ce cas.
2. Infrastructure cloud. Via MCP ou un outil Bash, l’agent crée des ressources EC2, RDS, S3 ou déploie des lambdas. AWS Budgets, GCP ou Yandex Cloud avec un coupe-circuit peuvent aider dans ce cas (règle 5).
3. API tierces. L’agent déclenche un paiement Stripe, envoie 100 SMS par une passerelle ou configure mille abonnements Telegram. Des clés sandbox aux autorisations restreintes et un plafond strict dans le tableau de bord du fournisseur peuvent aider dans ce cas (règle 6).

Voici maintenant 7 règles. Chacune couvre un ou deux canaux.

Comment définir un plafond strict pour les dépenses de l’API (règle 1)#

Où l’activer (prévoyez au moins 2 minutes par fournisseur) :

Anthropic Console. console.anthropic.com → Settings → Limits → Monthly spend limit. Définissez le montant que vous êtes prêt à perdre au cours du pire mois. Lorsqu’il est atteint, l’API renvoie 429 et consigne l’événement. Pas de « je réessaierai dans une minute » : l’accès est bloqué jusqu’à la fin du mois.

OpenAI Platform. platform.openai.com → Billing → Usage limits. Il existe de même une limite souple (alerte par e-mail) et une limite stricte (arrêt de l’API). Configurez les deux ; fixez la limite stricte à 1,5 fois la limite souple pour vous laisser le temps de réagir.

AWS Bedrock / Google Vertex. Si vous accédez à Claude/Anthropic par l’intermédiaire d’un fournisseur cloud, le plafond strict doit être défini côté cloud, pas chez Anthropic. C’est la règle 5.

Ce qui ne constitue pas un plafond strict : les alertes par e-mail (« vous avez dépensé 80 % de votre budget »). Elles arrivent avec du retard, et personne ne lit ses e-mails la nuit. Seule une barrière synchrone du côté du fournisseur convient.

Fonctionnement des Anthropic Task Budgets et emplacement du réglage (règle 2)#

Consultez la documentation officielle d’Anthropic pour en savoir plus. L’essentiel : il s’agit d’une limite souple, pas d’une limite stricte. Si l’agent a déjà créé une instance EC2, Task Budget ne l’annulera pas.

En pratique, vous transmettez le champ task_budget dans le payload de la requête (par exemple, 100 000 jetons d’entrée pour l’ensemble de la tâche). Claude reçoit des informations sur le budget et réduit lui-même l’ampleur de ses plans, en simplifiant des étapes ou en ignorant des sous-tâches. À mesure que le budget approche de zéro, il conclut et renvoie un résumé intermédiaire au lieu de vous remercier de votre attention.

Limites :

• API Anthropic uniquement. Ne fonctionne pas sur Bedrock/Vertex, qui ont leur propre facturation
• Modèles bêta uniquement (Opus 4.7, 4.8, Fable 5, Mythos 5). Pas sur Sonnet 4.6 ni Haiku
• Ne couvre pas les dépenses cloud ni les API tierces. Si Claude lance une instance EC2, Task Budget ne réagit pas

Utilisez cette fonction avec la règle 1 (plafond strict), et non à sa place.

Les garde-fous de coût relèvent de l’ingénierie du contexte : vous décidez ce que l’agent peut faire ou non, ainsi que l’emplacement de son arrêt d’urgence.

Ce qu’il faut bloquer avec les hooks PreToolUse dans Claude Code (règle 3)#

Au 1er juin 2026, les autorisations dans Claude Code sont évaluées dans l’ordre deny → ask → allow. Cela signifie que :

• vérifiez séparément le mode de permission sélectionné ; un test deny en mode normal ne prouve pas la protection en mode de contournement
• si un hook renvoie exit 2, l’appel d’outil est bloqué
• allowedTools s’applique uniquement lorsque les règles deny et les hooks ne s’activent pas

Un PreToolUse minimal vérifiant quelques écritures de commandes dangereuses : filtre textuel, pas analyseur shell complet ni barrière d’accès. Équivalents, scripts, autres outils et ressources cloud existantes exigent des contrôles distincts.

#!/usr/bin/env bash
# ~/.claude/hooks/block-dangerous-bash.sh
INPUT=$(cat)
if ! COMMAND=$(printf '%s\n' "$INPUT" | jq -er '.tool_input.command | select(type == "string")'); then
  echo "Bloqué : entrée du hook Bash invalide" >&2
  exit 2
fi

# Vérifie les motifs listés sans couvrir toute opération équivalente
if echo "$COMMAND" | grep -qiE '(rm -rf|aws s3 rb|terraform destroy|kubectl delete|drop database)'; then
  echo "Blocked: destructive command" >&2
  exit 2
fi

exit 0

Enregistrez-le au chemin indiqué, vérifiez jq et rendez-le exécutable avec chmod +x ~/.claude/hooks/block-dangerous-bash.sh. Associez-le à ~/.claude/settings.json :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "~/.claude/hooks/block-dangerous-bash.sh" }]
      }
    ]
  }
}

Consultez la documentation officielle.

Confirmez l’enregistrement dans /hooks, puis transmettez un JSON inoffensif au script sans exécuter son champ de commande. Une forme destructive listée doit retourner 2 ; une commande anodine 0. Testez aussi l’entrée malformée. La regex couvre seulement les appels Bash correspondants ; identifiants limités et isolation imposent la vraie limite. Voir l’exemple officiel entrée/sortie.

Pourquoi utiliser une liste d’autorisation allowedTools et pourquoi le mode --dangerously-skip-permissions ne doit pas être utilisé sur l’hôte (règle 4)#

Une liste d’autorisation applique le principe du moindre privilège. Au lieu de « tout autoriser » (--dangerously-skip-permissions), ajoutez uniquement ce dont la tâche a besoin :

{
  "permissions": {
    "allow": [
      "Bash(npm install:*)",
      "Bash(npm run build)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Read(./src/**)",
      "Write(./src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(curl * | sh)",
      "Write(/etc/**)",
      "Write(~/.ssh/**)"
    ]
  }
}

À savoir sur le mode de contournement :

• Linux/macOS refusent de démarrer Claude Code en mode de contournement en tant que root ou avec sudo : protection intégrée
• Sur votre propre machine, le contournement désactive toutes les demandes de confirmation, et l’agent peut exécuter rm -rf sur tout ce qu’il veut, ouvrir les clés SSH et téléverser des données dans le cloud
• N’exécutez jamais --dangerously-skip-permissions sur l’hôte, mais uniquement dans :
  • un conteneur Docker avec un montage de volume limité (uniquement le dossier requis)
  • une machine virtuelle isolée (Multipass, Lima, Orbstack)
  • GitHub Codespaces / Replit / un autre bac à sable

Une commande docker run minimale pour le mode de contournement :

docker run --rm -it \
  -v "$PWD:/workspace" \
  -w /workspace \
  --network host \
  ghcr.io/anthropics/claude-code:latest \
  claude --dangerously-skip-permissions

Si l’agent a besoin d’identifiants cloud, utilisez des clés distinctes aux autorisations limitées, pas vos clés principales (règle 6).

Comment configurer des alertes de budget cloud avec un coupe-circuit dans AWS, GCP et Yandex Cloud (règle 5)#

Configuration pour chaque cloud :

AWS Budgets (documentation). Créez un budget mensuel avec des seuils (50 %, 80 %, 100 %). Au seuil de 100 %, SNS peut appeler une Lambda de réponse. L’exemple désactive seulement les clés IAM de l’utilisateur nommé ; il n’arrête pas les ressources et ne constitue pas un plafond de dépenses :

import boto3

def lambda_handler(event, context):
    iam = boto3.client('iam')
    # Désactive toutes les clés de l’utilisateur « claude-agent »
    keys = iam.list_access_keys(UserName='claude-agent')['AccessKeyMetadata']
    for key in keys:
        iam.update_access_key(
            UserName='claude-agent',
            AccessKeyId=key['AccessKeyId'],
            Status='Inactive'
        )
    return {'statusCode': 200, 'body': 'Clés IAM désactivées ; ressources existantes inchangées'}

Arrêt borné de ressources : Dans un bac à sable dédié contenant les instances EC2 EBS approuvées, relevez compte, régions et identifiants exacts avant exécution. Dans Console EC2, sélectionnez seulement ces instances → Instance state → Stop instance → confirmation, puis vérifiez stopped pour chacune. Préservez d’abord les données instance-store nécessaires : l’arrêt les efface. Vérifiez qu’aucun planificateur ou système de mise à l’échelle ne les remplace. Cela arrête ce calcul, pas toute facture : examinez stockage conservé et autres services. Suivez la procédure EC2 officielle.

La documentation AWS Budgets précise le retard des notifications et les coûts encore possibles avant et après alerte. Un déclenchement à 100 % n’impose donc pas de plafond monétaire exact.

GCP Budget Alerts. Créez un budget → sujet Pub/Sub → Cloud Function qui désactive le Service Account. Un conseil important de la documentation : les alertes notifient, elles n’arrêtent rien, d’où le rôle essentiel de la Cloud Function.

Yandex Cloud (documentation). Définissez des budgets sous Billing → Budgets et des quotas de ressources comme plafond strict. Vous pouvez relier les notifications à un bot Telegram par l’intermédiaire de Cloud Functions.

OpenAI API. Les limites de dépenses souple et stricte sont directement dans le tableau de bord : la limite stricte arrête automatiquement l’API ; aucune Lambda n’est nécessaire.

Utilisez un plafond fournisseur vérifié lorsqu’il existe, alertes budgétaires différées, identifiants limités et réponse testée pour les ressources précises créables par l’agent. Révoquer un identifiant bloque certaines nouvelles opérations ; vérifiez aussi l’arrêt de l’usage actif. Ni alerte ni succès de la Lambda ne prouve l’arrêt de toute facturation.

Pourquoi un agent a besoin d’une clé API sandbox distincte aux autorisations limitées (règle 6)#

Configuration AWS minimale :

1. Créez l’utilisateur IAM claude-agent-scan
2. Politique : uniquement les actions requises (par exemple ec2:RunInstances dans une région avec une taille t3.micro, sans adresse IP élastique VPC)
3. Rattachez-le à un compte AWS distinct (via Organizations) doté d’un budget mensuel de 100 $
4. Générez des clés d’accès et donnez-les uniquement à l’agent ; ne les placez pas dans votre propre ~/.aws/credentials
5. Après la session, faites tourner les clés ou supprimez l’utilisateur

Même principe pour les autres fournisseurs :

• OpenAI / Anthropic : une clé API distincte pour chaque agent, un plafond strict par clé dans le tableau de bord et des balises agent_id dans les métadonnées des requêtes
• Stripe / YooKassa : une clé API restreinte à une action (par exemple, uniquement charges:read) et un commerçant distinct si possible
• Telegram Bot API : un jeton de bot distinct, et non le principal

Le vieux principe de sécurité s’applique ici : moindre privilège — l’agent reçoit exactement ce dont la tâche a besoin, pas un octet de plus. Si la tâche consiste à « analyser le réseau », ne lui donnez pas ec2:* et s3:* ; donnez-lui uniquement ec2:DescribeInstances.

Quand utiliser une simulation préalable et une limite d’itérations (règle 7)#

Plan Mode (/plan) s’active au début d’une session. L’agent prépare un plan, l’affiche dans le chat, attend votre approbation et ne commence à travailler qu’ensuite. C’est gratuit et cela évite 70 % des cas de « oups, je pensais qu’il demanderait d’abord ».

--max-turns est une option de lancement. Chaque tour correspond à un cycle « l’agent réfléchit + appel d’outil + résultat ». Pour les tâches autonomes :

• petite modification : 5 à 10 tours
• tâche moyenne : 15 à 30 tours
• grande tâche autonome : 50 à 80 tours

Techniques supplémentaires :

• Délai maximal avec la commande Linux timeout :

timeout 1800 claude --dangerously-skip-permissions --max-turns 30 -p "scan task"
# 1800 seconds = 30 minutes. Stop the process gracefully.

• Consignez chaque appel d’outil dans un fichier à l’aide d’un hook PostToolUse, afin de pouvoir consulter les événements ensuite
• Surveillance Cron : toutes les 5 minutes, vérifiez que 10 processus Claude ne tournent pas simultanément (signe typique d’un problème)

Liste de contrôle prête à l’emploi en 5 minutes avant de lancer Claude Code en mode autonome#

Liste à vérifier avant claude --dangerously-skip-permissions :

[ ] 1. Plafond strict chez le fournisseur d’API (Anthropic Console → Limits → Monthly spend limit)
[ ] 2. Task Budget dans le payload de la requête (si vous utilisez Opus 4.7+/Fable/Mythos)
[ ] 3. Hook PreToolUse pour bloquer rm -rf, aws s3 rb, terraform destroy
[ ] 4. Liste d’autorisation allowedTools dans settings.json ou travail dans un conteneur Docker
[ ] 5. Alertes cloud différées + révocation de clés testée et arrêt des ressources approuvées
[ ] 6. Clés API sandbox (une clé distincte pour l’agent, pas la principale)
[ ] 7. --max-turns N + timeout NNN secondes + surveillance Cron des processus

Si les sept éléments sont en place, lancez-vous. S’il en manque un seul, arrêtez-vous et configurez-le. Trente minutes maintenant peuvent vous éviter de perdre 6 000 à 500 000 $ plus tard.

Un exemple pour donner du contexte : un vibe coder a lancé une application de boutique en ligne avec le mot de passe par défaut de la base de données postgres. En quelques jours, quelqu’un l’a trouvée, a installé des mineurs et déployé ses propres portes dérobées. Il a fallu arrêter le serveur, et la facture du mois a augmenté à cause du minage de cryptomonnaies effectué par quelqu’un d’autre.

Cette histoire relève de la catégorie 3 de la section 1 (des tiers exécutant des tâches sur votre infrastructure), mais le principe reste le même : les contrôles de dépenses ne doivent pas dépendre de la personne ou de l’entité qui les a déclenchées — votre agent, votre employé ou un mineur au Nigeria.

Pour aller plus loin :

• Comment protéger Claude Code contre les dégâts — à propos de --dangerously-skip-permissions et des autorisations sous un autre angle
• Sécurité du vibe coding — le pilier de la sécurité
• Comment éviter d’épuiser les limites de Claude Code en une journée — à propos des jetons d’abonnement (ne confondez pas ce guide avec celui-ci, qui porte sur les factures cloud)

Découvrez Ailoot.