# 7 regras do Claude Code para limitar os gastos de agentes autónomos em 2026
> 7 regras para definir limites no Claude Code, para que um agente autónomo não o deixe sem dinheiro: limites do fornecedor, Task Budgets, hooks, listas de permissões, interruptores de emergência, chaves sandbox e limites de iterações.
Source: https://ailoot.ai/blog/pt-pt/ai-agent-burned-budget-claude-code/
Canonical: https://ailoot.ai/blog/pt-pt/ai-agent-burned-budget-claude-code/
Language: pt-PT
Publisher: Ailoot (https://ailoot.ai/)
Translation: guide-122
Revision: sha256-2f1428797aeebe11103ba66a7f90ade490c43ad9b43bfb06352f1bc9ace4a315
Pontos principais
Um agente autónomo com acesso ilimitado à cloud pode acumular uma fatura elevada numa só noite. Explico 7 regras para o Claude Code que pode implementar numa noite para evitar este tipo de falha.
Saiba como trabalhar com o serviço na [documentação da Ailoot](https://ailoot.ai/docs/).
## Para onde vai o dinheiro: 3 categorias de despesas de um agente autónomo
Pontos principais
Em que gasta o seu dinheiro um agente autónomo? Através de três canais distintos: tokens na Anthropic/OpenAI, recursos na cloud (AWS/GCP/Yandex Cloud) e ações pagas em APIs de terceiros (cobranças Stripe, gateways de SMS, Twilio, bots de Telegram com subscrições). Cada canal tem faturação própria e a sua própria forma de travar a onda de despesas.
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)
Pontos principais
Como se define um limite rígido para as despesas da API? A Anthropic e a OpenAI têm um limite de despesas da organização integrado que restringe automaticamente a conta quando esta atinge o montante definido. Não o confunda com alertas, que apenas enviam um e-mail. Um limite rígido é uma barreira; os alertas são uma luz indicadora. Configure ambos, começando pela barreira.
Onde o ativar (conte com pelo menos 2 minutos para cada fornecedor):
**Anthropic Console.** [console.anthropic.com](https://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](https://platform.openai.com/account/billing/limits) → 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)
Pontos principais
O que são os Anthropic Task Budgets e contra o que o protegem? É uma funcionalidade beta no Opus 4.7/4.8 e na linha Fable/Mythos: define um orçamento para um fluxo de trabalho autónomo e o Claude reduz a profundidade do raciocínio à medida que o orçamento diminui, terminando com um resumo em vez de dizer «pronto, fiquei sem orçamento» a meio da tarefa. Não resolve todas as despesas de cloud, mas evita 80% dos casos em que o agente «fica preso num ciclo e não se apercebe».
Consulte a [documentação oficial](https://platform.claude.com/docs/en/build-with-claude/task-budgets) 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)
Pontos principais
O que são hooks PreToolUse no Claude Code e porque precisa deles? São scripts que são executados **antes** de o Claude executar uma chamada a uma ferramenta. Pode bloquear um pedido (`exit 2`), exigir confirmação do utilizador ou deixá-lo passar sem perguntar. O essencial: os hooks são executados antes de `--dangerously-skip-permissions`. Isso significa que pode bloquear ações perigosas mesmo no modo de bypass.
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.
```bash
#!/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`:
```json
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [{ "type": "command", "command": "~/.claude/hooks/block-dangerous-bash.sh" }]
}
]
}
}
```
Consulte a [documentação oficial](https://code.claude.com/docs/en/permissions).
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](https://code.claude.com/docs/en/hooks-guide#read-input-and-return-output).
## 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)
Pontos principais
Onde se coloca a lista de ferramentas permitidas e porque é a máquina anfitriã um mau local para o modo de bypass? `allowedTools` em settings.json é uma lista de comandos específicos que o agente pode executar sem confirmação; para tudo o resto, pede autorização. `--dangerously-skip-permissions` desativa por completo esses pedidos, por isso não o execute na máquina anfitriã—use apenas um contentor ou uma VM.
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:
```json
{
"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:
```bash
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)
Pontos principais
Um alerta de orçamento informa sobre despesa observada ou prevista e pode chegar tarde. Uma função de resposta pode bloquear novas operações do agente ou parar recursos específicos; são ações diferentes. Desativar uma chave IAM não interrompe a cobrança de recursos já em execução. Defina e teste a paragem de recursos separadamente.
Como configurar em cada cloud:
**AWS Budgets** ([documentação](https://aws.amazon.com/aws-cost-management/aws-budgets/)). 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:
```python
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](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/Stop_Start.html).
A [documentação de AWS Budgets](https://docs.aws.amazon.com/cost-management/latest/userguide/budgets-managing-costs.html) 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](https://yandex.cloud/ru/docs/billing/concepts/budget)). 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)
Pontos principais
Porque precisa um agente de uma chave API separada? Para conter as consequências de uma falha. Crie um utilizador IAM ou Service Account exclusivamente para um agente, dê-lhe permissões mínimas (EC2, não *) e associe-o a um projeto de faturação separado com um limite rígido. Se o agente esgotar o orçamento, gasta os seus próprios 50 $ numa hora, não todo o dinheiro da empresa.
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)
Pontos principais
Porque deixar o agente mostrar-lhe o plano antes do arranque e quantas iterações deve permitir, no máximo? Plan Mode é uma funcionalidade integrada no Claude Code: primeiro, o agente descreve o que pretende fazer e você aprova. É uma verificação prévia gratuita. E `--max-turns N` limita o número de passos numa sessão, impedindo que o agente fique num ciclo interminável. Para o modo autónomo, defina 10–30 ciclos, no máximo.
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`:
```bash
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
Pontos principais
O que deve estar preparado antes de premir Enter numa tarefa autónoma? Sete caixas de verificação, cada uma demora cerca de um minuto. Se alguma estiver vazia, não inicie o agente.
**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](https://ailoot.ai/blog/pt-pt/claude-code-safe-overnight-setup/)—sobre `--dangerously-skip-permissions` e permissões, de outra perspetiva
- [Segurança no vibe coding](https://ailoot.ai/blog/pt-pt/vibe-coding-security/)—o pilar de segurança
- [Como não esgotar os limites do Claude Code num dia](https://ailoot.ai/blog/pt-pt/claude-code-token-limits-saving/)—sobre tokens de subscrição (não confunda este guia com o das faturas de cloud)
### Fontes
- [Documentação da Anthropic: Task Budgets](https://platform.claude.com/docs/en/build-with-claude/task-budgets)
- [Documentação do Claude Code: configurar permissões](https://code.claude.com/docs/en/permissions)
- [AWS Budgets—configurar orçamentos personalizados de custos e utilização](https://aws.amazon.com/aws-cost-management/aws-budgets/)
- [Yandex Cloud: orçamentos](https://yandex.cloud/ru/docs/billing/concepts/budget)
Conheça a [Ailoot](https://ailoot.ai/).
## Perguntas frequentes
### Revogar as chaves IAM do agente interrompe a fatura da nuvem?
Não. Impede a utilização dessas chaves em novos pedidos autenticados, mas os recursos existentes podem continuar a gerar custos. Mantenha uma lista dos recursos sob o seu controlo, pare as instâncias aprovadas, verifique o estado e reveja separadamente o armazenamento retido e os outros serviços.
### A expressão regular de comandos do exemplo impõe um limite completo de segurança?
Não. Examina apenas chamadas à ferramenta Bash abrangidas e certos padrões de texto. Teste a interpretação de JSON e os códigos de saída, mas use permissões restritas na nuvem e isolamento do ambiente para o limite efetivo de acesso. Operações equivalentes e outras ferramentas podem escapar ao filtro.
## Ailoot · A empresa e a sua carteira de projetos
A Ailoot assenta numa experiência operacional consolidada, numa ampla base de clientes, num serviço estável e no acompanhamento contínuo dos KPI.
A empresa e a sua carteira de projetos: milhões de clientes; vendas mensais na ordem dos milhares de milhões.
A Ailoot aplica essa experiência operacional ao acesso por API a funcionalidades de IA nos produtos dos clientes, agentes, aplicações e automatizações.