7 regras do Claude Code para limitar os gastos de agentes autónomos em 2026

Saiba como trabalhar com o serviço na documentação da Ailoot.

Para onde vai o dinheiro: 3 categorias de despesas de um agente autónomo#

Não confunda estes três canais—funcionam de forma independente e exigem configurações diferentes:

1. Tokens de LLM. Claude, OpenAI ou Gemini cobram pelo contexto de entrada e de saída de cada pedido. Os Anthropic Task Budgets (ver Regra 2) e uma subscrição em vez do pagamento por utilização da API podem ajudar neste caso.
2. Infraestrutura na cloud. Através do MCP ou de uma ferramenta Bash, o agente cria recursos EC2, RDS e S3, ou implementa lambdas. AWS Budgets, GCP ou Yandex Cloud com um interruptor de emergência podem ajudar aqui (Regra 5).
3. APIs de terceiros. O agente inicia uma cobrança Stripe, envia 100 SMS através de um gateway ou configura mil subscrições de Telegram. Chaves de sandbox com permissões restritas e um limite rígido no painel do fornecedor podem ajudar aqui (Regra 6).

Seguem-se 7 regras. Cada uma abrange um ou dois canais.

Como definir um limite rígido para as despesas da API (Regra 1)#

Onde o ativar (conte com pelo menos 2 minutos para cada fornecedor):

Anthropic Console. console.anthropic.com → Settings → Limits → Monthly spend limit. Defina um montante que esteja disposto a gastar no pior mês. Quando o atingir, a API devolve 429 e regista o evento. Não há «vou tentar novamente daqui a um minuto»—fica bloqueado até ao fim do mês.

OpenAI Platform. platform.openai.com → Billing → Usage limits. De forma semelhante, existe um limite flexível (alerta por e-mail) e um limite rígido (encerramento da API). Defina ambos; coloque o limite rígido em 1,5x o limite flexível para ter tempo de reagir.

AWS Bedrock / Google Vertex. Se aceder ao Claude/Anthropic através de um intermediário de cloud, o limite rígido tem de ser configurado do lado da cloud, não na Anthropic. Esta é a Regra 5.

O que não conta como limite rígido: alertas por e-mail («já gastou 80% do seu orçamento»). Chegam com atraso e ninguém lê o e-mail durante a noite. Só uma barreira síncrona do lado do fornecedor.

Como funcionam os Anthropic Task Budgets e onde os configurar (Regra 2)#

Consulte a documentação oficial da Anthropic para obter detalhes. O essencial é que se trata de uma fronteira flexível, não de um limite rígido. Se o agente já tiver criado uma instância EC2, o Task Budget não a elimina.

Na prática, passa o campo task_budget no payload do pedido (por exemplo, 100 000 tokens de entrada para a tarefa completa). O Claude recebe informação sobre o orçamento e reduz os seus planos por iniciativa própria, simplificando etapas ou saltando subtarefas. À medida que o orçamento se aproxima de zero, vai concluindo o trabalho e devolve um resumo provisório em vez de um «obrigado pela atenção».

Limitações:

• Apenas na API da Anthropic. Não funciona no Bedrock/Vertex, que têm faturação própria
• Apenas modelos beta (Opus 4.7, 4.8, Fable 5, Mythos 5). Não está disponível no Sonnet 4.6 nem no Haiku
• Não abrange despesas de cloud nem APIs de terceiros. Se o Claude iniciar uma instância EC2, o Task Budget não reage

Use-o em conjunto com a Regra 1 (limite rígido), não em substituição dela.

As proteções de custos fazem parte da engenharia de contexto: decide o que o agente pode e não pode fazer e onde fica o seu botão de paragem de emergência.

O que bloquear com hooks PreToolUse no Claude Code (Regra 3)#

As permissões no Claude Code (a 1 de junho de 2026) são avaliadas pela ordem deny → ask → allow. Isto significa que:

• verifique separadamente o modo de permissões escolhido; um teste de regra deny no modo normal não prova proteção no modo de bypass
• se um hook devolver exit 2, a chamada à ferramenta é bloqueada
• allowedTools só se aplica quando as regras deny e os hooks não se pronunciam

Um hook PreToolUse mínimo que verifica algumas formas de escrever comandos perigosos. É um filtro de texto, não um analisador completo da shell nem um limite de acesso: comandos equivalentes, scripts, outras ferramentas e recursos na nuvem já existentes exigem controlos separados.

#!/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

# Verifica os padrões de texto indicados; não abrange todas as operações equivalentes
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

Guarde o script no caminho indicado, confirme que jq está disponível e torne-o executável com chmod +x ~/.claude/hooks/block-dangerous-bash.sh. Associe-o em ~/.claude/settings.json:

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

Consulte a documentação oficial.

Consulte /hooks para confirmar o registo e passe JSON de exemplo inofensivo ao script, sem executar o campo de comando. Uma forma destrutiva prevista deve devolver 2; um comando benigno, 0. Teste também entradas malformadas. A expressão regular só verifica chamadas Bash correspondentes; use credenciais restritas e isolamento do ambiente como limite efetivo de autoridade. Consulte o exemplo oficial de entrada e saída dos hooks.

Porque usar uma lista de permissões allowedTools e porque o --dangerously-skip-permissions não deve ser usado na máquina anfitriã (Regra 4)#

Uma lista de permissões segue o princípio do menor privilégio. Em vez de «permitir tudo» (--dangerously-skip-permissions), adicione apenas o que a tarefa exige:

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

O que precisa de saber sobre o modo de bypass:

• Linux/macOS recusam iniciar o Claude Code em modo de bypass como root ou com sudo—é uma proteção incorporada
• No seu próprio computador, o bypass desativa todos os pedidos de confirmação e o agente pode executar rm -rf à vontade, abrir chaves SSH e enviar dados para a cloud
• Nunca execute --dangerously-skip-permissions na máquina anfitriã; use-o apenas em:
  • um contentor Docker com uma montagem de volume limitada (apenas a pasta necessária)
  • uma VM isolada (Multipass, Lima, Orbstack)
  • GitHub Codespaces / Replit / outro ambiente isolado

Um comando docker run mínimo para o modo de bypass:

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

Se o agente precisar de credenciais de cloud, use chaves separadas com permissões restritas, não as suas chaves principais (Regra 6).

Como configurar alertas de orçamento na cloud com um interruptor de emergência na AWS, GCP e Yandex Cloud (Regra 5)#

Como configurar em cada cloud:

AWS Budgets (documentação). Crie um orçamento mensal e limites (50%, 80%, 100%). No limite de 100%, um tópico SNS pode invocar uma Lambda de resposta. O exemplo seguinte só desativa as chaves de acesso IAM do utilizador indicado; não para recursos nem estabelece um teto rígido de despesa:

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'}

Procedimento delimitado de paragem de recursos: num ambiente de testes dedicado com instâncias EC2 aprovadas e baseadas em EBS, registe previamente a conta, as Regiões e os IDs exatos das instâncias. Na consola EC2, selecione apenas essas instâncias → Instance state → Stop instance → confirme e verifique que cada uma chega ao estado stopped. Preserve primeiro os dados necessários do armazenamento de instância; a paragem apaga-os. Confirme que nenhum agendador ou sistema de escalabilidade aprovado as pode substituir. Isto interrompe esse consumo de computação, não todas as cobranças da conta: examine separadamente o armazenamento retido e os outros serviços. Siga o procedimento oficial de paragem EC2.

A documentação de AWS Budgets avisa que as notificações chegam depois da utilização dos recursos e que podem acumular-se custos antes e depois do alerta. Acionar a resposta aos 100% não impõe, por isso, um teto monetário exato.

Alertas de orçamento GCP. Crie um Budget → tópico Pub/Sub → Cloud Function que desative a Service Account. Uma dica importante da documentação: os alertas apenas notificam, não desligam nada, por isso a Cloud Function é essencial.

Yandex Cloud (documentação). Defina orçamentos em Billing → Budgets e também quotas de recursos como limite rígido. Pode ligar notificações a um bot de Telegram através de Cloud Functions.

OpenAI API. Os limites flexível e rígido de despesas estão diretamente no painel—a API é interrompida automaticamente pelo limite rígido; não é necessária nenhuma Lambda.

Use um limite rígido verificado no fornecedor quando disponível, alertas de orçamento sujeitos a atraso, credenciais restritas e uma resposta testada para os recursos específicos que o agente pode criar. Revogar credenciais bloqueia algumas operações novas; é preciso verificar a paragem para interromper o consumo de recursos. Nem um alerta nem uma mensagem de sucesso da Lambda de revogação provam que toda a faturação parou.

Porque um agente precisa de uma chave API de sandbox separada e com permissões restritas (Regra 6)#

Uma configuração AWS mínima:

1. Crie o utilizador IAM claude-agent-scan
2. Política: apenas as ações necessárias (por exemplo, ec2:RunInstances numa região, com o tamanho t3.micro, sem um endereço IP elástico de VPC)
3. Associe-o a uma conta AWS separada (através de Organizations) com um orçamento mensal de 100 $
4. Gere chaves de acesso e entregue-as apenas ao agente; não as coloque nas suas próprias ~/.aws/credentials
5. Depois da sessão, rode as chaves ou elimine o utilizador

Faça o mesmo com outros fornecedores:

• OpenAI / Anthropic: uma chave API separada para cada agente, um limite rígido para cada chave no painel e etiquetas agent_id nos metadados dos pedidos
• Stripe / YooKassa: uma chave API restrita a uma ação (por exemplo, apenas charges:read) e, se possível, um comerciante separado
• Telegram Bot API: um token de bot separado, não o principal

Aplica-se aqui o antigo princípio de segurança: menor privilégio—o agente recebe exatamente o que a tarefa exige, nem mais um byte. Se a tarefa for «analisar a rede», não lhe dê ec2:* nem s3:*; dê-lhe apenas ec2:DescribeInstances e pronto.

Quando usar uma simulação prévia e um limite de iterações (Regra 7)#

O Plan Mode (/plan) é ativado no início de uma sessão. O agente prepara um plano, mostra-o no chat, aguarda aprovação e só depois começa a trabalhar. É gratuito e evita 70% dos casos de «ups, pensei que ia perguntar primeiro».

--max-turns é uma opção de arranque. Cada ciclo corresponde a «o agente pensa + chamada de ferramenta + resultado». Para tarefas autónomas:

• alteração pequena: 5–10 ciclos
• tarefa média: 15–30 ciclos
• tarefa autónoma grande: 50–80 ciclos

Técnicas adicionais:

• Limite de tempo com o comando Linux timeout:

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

• Registe cada chamada a uma ferramenta num ficheiro com um hook PostToolUse, para poder ver mais tarde o que aconteceu
• Monitorização cron—a cada 5 minutos, verifique se não tem 10 processos Claude a funcionar em simultâneo (um sinal típico de que algo correu mal)

Lista de verificação pronta a usar em 5 minutos antes de lançar o Claude Code autónomo#

Lista de verificação antes de claude --dangerously-skip-permissions:

[ ] 1. Limite rígido no fornecedor da API (Anthropic Console → Limits → Monthly spend limit)
[ ] 2. Task Budget no payload do pedido (se usar Opus 4.7+/Fable/Mythos)
[ ] 3. Hook PreToolUse para bloquear rm -rf, aws s3 rb, terraform destroy
[ ] 4. Lista de permissões allowedTools em settings.json ou trabalho dentro de um contentor Docker
[ ] 5. Alertas de orçamento na nuvem sujeitos a atraso + revogação de chaves testada e paragem dos recursos aprovados
[ ] 6. Chaves API de sandbox (uma chave separada para o agente, não a principal)
[ ] 7. --max-turns N + timeout NNN seconds + monitorização dos processos por cron

Se as sete medidas estiverem implementadas, avance. Se faltar uma, pare e configure-a. Trinta minutos agora podem poupar-lhe 6 000–500 000 $ mais tarde.

Um exemplo para contextualizar: um vibe coder lançou uma aplicação de loja online com a palavra-passe predefinida da base de dados postgres. Em poucos dias, alguém a encontrou, instalou mineradores e implementou as suas próprias portas traseiras. Foi necessário desligar o servidor e a fatura do mês aumentou devido à mineração de criptomoedas de outra pessoa.

Esta história pertence à categoria 3 da Secção 1 (terceiros a executar coisas na sua infraestrutura), mas a lógica é a mesma: os controlos de despesas não devem depender de quem as iniciou—o seu agente, um funcionário ou um minerador na Nigéria.

Leitura adicional:

• Como proteger o Claude Code contra falhas—sobre --dangerously-skip-permissions e permissões, de outra perspetiva
• Segurança no vibe coding—o pilar de segurança
• Como não esgotar os limites do Claude Code num dia—sobre tokens de subscrição (não confunda este guia com o das faturas de cloud)

Conheça a Ailoot.