Claude Code: 7 regole per limitare la spesa degli agenti

Scopri come usare il servizio nella documentazione di Ailoot.

Dove finiscono i soldi: 3 categorie di spesa per un agente autonomo#

Non confondere questi tre canali: funzionano in modo indipendente e richiedono impostazioni diverse:

1. Token LLM. Claude, OpenAI o Gemini addebitano i token del contesto di input e output di ogni richiesta. I Task Budgets di Anthropic (vedi Regola 2) e un abbonamento al posto del pagamento a consumo tramite API possono essere d’aiuto.
2. Infrastruttura cloud. Tramite MCP o uno strumento Bash, l’agente crea risorse EC2, RDS, S3 o distribuisce funzioni Lambda. AWS Budgets, GCP o Yandex Cloud con un interruttore di emergenza possono essere d’aiuto (Regola 5).
3. API di terze parti. L’agente effettua un addebito con Stripe, invia 100 SMS tramite un gateway o attiva mille abbonamenti Telegram. Chiavi sandbox con ambiti limitati e un limite massimo effettivo nella dashboard del fornitore possono essere d’aiuto (Regola 6).

Seguono 7 regole. Ognuna riguarda uno o due canali.

Come impostare un limite massimo effettivo alle spese API (Regola 1)#

Dove attivarlo (considera almeno 2 minuti per ogni fornitore):

Anthropic Console. console.anthropic.com → Settings → Limits → Monthly spend limit. Imposta un importo che sei disposto a spendere nel mese peggiore. Quando viene raggiunto, l’API restituisce 429 e registra l’evento. Niente «ci riprovo tra un minuto»: l’accesso è bloccato fino alla fine del mese.

OpenAI Platform. platform.openai.com → Billing → Usage limits. Analogamente, c’è un limite flessibile (avviso via email) e un limite rigido (arresto dell’API). Impostali entrambi; imposta il limite rigido a 1,5 volte quello flessibile per lasciare tempo di reagire.

AWS Bedrock / Google Vertex. Se accedi a Claude/Anthropic tramite un intermediario cloud, il limite massimo effettivo deve essere sul lato cloud, non su Anthropic. Questa è la Regola 5.

Cosa non costituisce un limite massimo effettivo: gli avvisi via email («hai consumato l’80% del tuo budget»). Arrivano in ritardo e di notte nessuno legge le email. Solo una barriera sincrona lato fornitore.

Come funzionano gli Anthropic Task Budgets e dove impostarli (Regola 2)#

Per i dettagli, consulta la documentazione ufficiale di Anthropic. Il punto chiave: è un limite flessibile, non rigido. Se l’agente ha già creato un’istanza EC2, Task Budget non la annullerà.

Come funziona in pratica: passi il campo task_budget nel payload della richiesta (per esempio, 100.000 token di input per l’intera attività). Claude riceve informazioni sul budget e ridimensiona autonomamente i propri piani, semplificando i passaggi o saltando sottoattività. Quando il budget si avvicina allo zero, conclude e restituisce un riepilogo provvisorio invece di «grazie per l’ascolto».

Limitazioni:

• Solo API Anthropic. Non funziona su Bedrock/Vertex, che hanno una propria fatturazione
• Solo modelli beta (Opus 4.7, 4.8, Fable 5, Mythos 5). Non su Sonnet 4.6 o Haiku
• Non copre le spese cloud né le API di terze parti. Se Claude avvia un’istanza EC2, Task Budget non interviene

Usalo insieme alla Regola 1 (limite massimo effettivo), non al suo posto.

I limiti ai costi fanno parte del context engineering: decidi cosa può e non può fare l’agente e dove si trova il suo arresto di emergenza.

Cosa bloccare con gli hook PreToolUse in Claude Code (Regola 3)#

In Claude Code (al 1° giugno 2026), i permessi vengono valutati nell’ordine deny → ask → allow. Questo significa che:

• verifica separatamente la modalità dei permessi selezionata; una regola deny provata in modalità normale non dimostra protezione in bypass
• se un hook restituisce exit 2, la chiamata allo strumento viene bloccata
• allowedTools si applica solo quando le regole di negazione e gli hook non intervengono

Un hook PreToolUse minimo che controlla alcune forme testuali di comandi pericolosi. È un filtro di testo, non un parser shell completo o un confine di accesso: comandi equivalenti, script, altri strumenti e risorse cloud esistenti richiedono controlli separati.

#!/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 "Blocked: invalid Bash hook input" >&2
  exit 2
fi

# Controlla gli schemi elencati; non copre ogni operazione equivalente
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

Salva lo script nel percorso indicato, verifica la disponibilità di jq e rendilo eseguibile con chmod +x ~/.claude/hooks/block-dangerous-bash.sh. Associalo a ~/.claude/settings.json:

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

Consulta la documentazione ufficiale.

Controlla /hooks per confermare la registrazione, poi passa allo script JSON di prova innocuo senza eseguirne il campo comando. Una forma distruttiva elencata deve restituire 2; un comando innocuo, 0. Prova anche input malformati. La regex controlla solo le chiamate Bash corrispondenti: usa credenziali ristrette e isolamento per il vero confine di autorità. Consulta l’esempio ufficiale di input e output degli hook.

Perché usare una whitelist allowedTools e perché --dangerously-skip-permissions non va usato sull’host (Regola 4)#

Una whitelist applica il principio del privilegio minimo. Invece di «consenti tutto» (--dangerously-skip-permissions), aggiungi solo ciò che serve all’attività:

{
  "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/**)"
    ]
  }
}

Cosa bisogna sapere sulla modalità di bypass:

• Linux/macOS rifiutano di avviare Claude Code in modalità di bypass come root o con sudo: è una protezione integrata
• Sulla tua macchina, la modalità di bypass disattiva tutte le richieste di conferma e l’agente può eseguire rm -rf su qualsiasi cosa, aprire chiavi SSH e caricare dati sul cloud
• Non eseguire mai --dangerously-skip-permissions sull’host, solo in:
  • un container Docker con un montaggio limitato del volume (solo la cartella necessaria)
  • una VM isolata (Multipass, Lima, Orbstack)
  • GitHub Codespaces / Replit / un’altra sandbox

Un comando docker run minimo per la modalità di bypass:

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

Se l’agente ha bisogno di credenziali cloud, usa chiavi separate con ambiti limitati, non quelle principali (Regola 6).

Come impostare avvisi sul budget cloud con un interruttore di emergenza in AWS, GCP e Yandex Cloud (Regola 5)#

Come configurarlo in ciascun servizio cloud:

AWS Budgets (documentazione). Crea un budget mensile con soglie (50%, 80%, 100%). Alla soglia del 100%, un argomento SNS può richiamare una Lambda di risposta. L’esempio seguente disattiva soltanto le chiavi IAM dell’utente nominato: non arresta risorse e non stabilisce un tetto rigido di spesa:

import boto3

def lambda_handler(event, context):
    iam = boto3.client('iam')
    # Deactivate all keys for the 'claude-agent' user
    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': 'IAM keys deactivated; existing resources unchanged'}

Procedura circoscritta di arresto delle risorse: per una sandbox dedicata con istanze EC2 approvate basate su EBS, registra prima account, regioni e ID esatti. Nella console EC2 seleziona solo quelle istanze → Instance state → Stop instance → conferma e verifica stopped per ciascuna. Conserva prima i dati necessari dell’instance store: l’arresto li cancella. Controlla che scheduler o sistemi di scaling approvati non le sostituiscano. Ferma quel consumo di calcolo, non ogni costo dell’account: esamina separatamente storage conservato e altri servizi. Segui la procedura EC2 ufficiale.

La documentazione AWS Budgets avverte che le notifiche sono in ritardo rispetto all’uso e altri costi possono maturare prima e dopo. Attivarsi al 100% non impone quindi un tetto monetario esatto.

GCP Budget Alerts. Crea un budget → argomento Pub/Sub → Cloud Function che disattiva il Service Account. Un consiglio importante tratto dalla documentazione: gli avvisi inviano solo notifiche, non arrestano i servizi, quindi la Cloud Function è essenziale.

Yandex Cloud (documentazione). Imposta i budget in Billing → Budgets e aggiungi quote delle risorse come limite massimo effettivo. Puoi collegare le notifiche a un bot Telegram tramite Cloud Functions.

OpenAI API. I limiti di spesa flessibile e rigido sono direttamente nella dashboard: il limite rigido arresta automaticamente l’API; non serve Lambda.

Usa un limite rigido del fornitore verificato dove disponibile, avvisi budget ritardati, credenziali ristrette e una risposta provata per le risorse specifiche creabili dall’agente. Revocare credenziali blocca alcune nuove operazioni; per il consumo in corso serve verificare l’arresto. Né un avviso né il successo della Lambda di revoca dimostrano che tutta la fatturazione sia ferma.

Perché un agente ha bisogno di una chiave API sandbox separata con ambito limitato (Regola 6)#

Configurazione AWS minima:

1. Crea l’utente IAM claude-agent-scan
2. Policy: solo le azioni richieste (per esempio, ec2:RunInstances in una regione con dimensione t3.micro, senza un indirizzo IP elastico VPC)
3. Collegalo a un account AWS separato (tramite Organizations) con un budget mensile di 100 $
4. Genera chiavi di accesso e consegnale solo all’agente; non inserirle nel tuo ~/.aws/credentials
5. Al termine della sessione, ruota le chiavi o elimina l’utente

Lo stesso vale per gli altri fornitori:

• OpenAI / Anthropic: una chiave API separata per ogni agente, un limite massimo effettivo per ogni chiave nella dashboard e tag agent_id nei metadati della richiesta
• Stripe / YooKassa: una chiave API con restrizioni per una sola azione (per esempio, solo charges:read) e, se possibile, un commerciante separato
• Telegram Bot API: un token bot separato, non quello principale

Qui vale il vecchio principio di sicurezza: privilegio minimo: l’agente ottiene esattamente ciò che serve all’attività, neanche un byte in più. Se l’attività consiste nello «scansionare la rete», non concedergli ec2:* e s3:*; concedigli solo ec2:DescribeInstances e basta.

Quando usare una simulazione preliminare e un limite alle iterazioni (Regola 7)#

Plan Mode (/plan) si attiva all’inizio di una sessione. L’agente prepara un piano, lo mostra nella chat, attende l’approvazione e solo dopo si mette al lavoro. È gratuito e previene il 70% dei casi in cui qualcuno dice «ops, pensavo che me lo avrebbe chiesto prima».

--max-turns è un’opzione di avvio. Ogni turno è un ciclo di «l’agente ragiona + chiamata allo strumento + risultato». Per le attività autonome:

• modifica piccola: 5–10 turni
• attività media: 15–30 turni
• attività autonoma grande: 50–80 turni

Tecniche aggiuntive:

• Timeout di tempo reale con il comando Linux timeout:

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

• Registra ogni chiamata agli strumenti in un file con un hook PostToolUse per poter vedere cos’è successo in seguito
• Monitoraggio cron: ogni 5 minuti controlla che non ci siano 10 processi Claude in esecuzione contemporaneamente (un segnale tipico che qualcosa è andato storto)

Una checklist pronta all’uso di 5 minuti prima di avviare Claude Code in modalità autonoma#

Checklist prima di claude --dangerously-skip-permissions:

[ ] 1. Limite massimo effettivo presso il fornitore API (Anthropic Console → Limits → Monthly spend limit)
[ ] 2. Task Budget nel payload della richiesta (se usi Opus 4.7+/Fable/Mythos)
[ ] 3. Hook PreToolUse per bloccare rm -rf, aws s3 rb, terraform destroy
[ ] 4. Whitelist allowedTools in settings.json oppure lavoro all’interno di un container Docker
[ ] 5. Avvisi budget cloud ritardati + revoca chiavi e arresto risorse approvato e verificato
[ ] 6. Chiavi API sandbox (una chiave separata per l’agente, non quella principale)
[ ] 7. --max-turns N + timeout di NNN secondi + monitoraggio cron dei processi

Se sono tutte e sette, avvia l’agente. Se ne manca anche una sola, fermalo e configuralo. Trenta minuti adesso possono farti risparmiare 6.000–500.000 $ più avanti.

Un esempio per contesto: un vibe coder ha avviato un’app di negozio online con la password predefinita del database postgres. Nel giro di un paio di giorni qualcuno l’ha trovata, ha installato miner e distribuito i propri backdoor. È stato necessario terminare il server e la fattura del mese è aumentata a causa del mining di criptovalute di qualcun altro.

Questa storia riguarda la categoria 3 della Sezione 1 (terze parti che eseguono attività sulla tua infrastruttura), ma la logica è la stessa: i controlli sulle spese non dovrebbero dipendere da chi le ha avviate: il tuo agente, un dipendente o un miner in Nigeria.

Approfondimenti:

• Come proteggere Claude Code dai danni: parla di --dangerously-skip-permissions e dei permessi da un’altra prospettiva
• Sicurezza nel vibe coding: il pilastro della sicurezza
• Come non esaurire i limiti di Claude Code in un giorno: parla dei token dell’abbonamento (non confonderla con questa guida alle fatture cloud)

Scopri Ailoot.