7 Claude Code rules for limiting autonomous agent spending in 2026

Learn how to work with the service in the Ailoot documentation.

Where the money goes: 3 spending categories for an autonomous agent#

Don’t confuse these three channels—they work independently and require different settings:

1. LLM tokens. Claude, OpenAI, or Gemini charges for the input and output context of every request. Anthropic Task Budgets (see Rule 2) and a subscription instead of API pay-as-you-go can help here.
2. Cloud infrastructure. Through MCP or a Bash tool, the agent creates EC2, RDS, S3 resources, or deploys lambdas. AWS Budgets, GCP, or Yandex Cloud with a kill switch can help here (Rule 5).
3. Third-party APIs. The agent calls a Stripe charge, sends 100 SMS messages through a gateway, or sets up a thousand Telegram subscriptions. Sandbox keys with narrow scopes and a hard cap in the provider’s dashboard can help here (Rule 6).

Next are 7 rules. Each covers one or two channels.

How to set a hard cap on API spending (Rule 1)#

Where to enable it (allow at least 2 minutes per provider):

Anthropic Console. console.anthropic.com → Settings → Limits → Monthly spend limit. Set an amount you’re willing to burn in the worst month. When it’s reached, the API returns 429 and logs the event. No “I’ll try again in a minute”—it’s blocked until the end of the month.

OpenAI Platform. platform.openai.com → Billing → Usage limits. Similarly, there’s a soft limit (email alert) and a hard limit (API shutdown). Set both; set the hard limit at 1.5x the soft limit to leave room for reaction time.

AWS Bedrock / Google Vertex. If you access Claude/Anthropic through a cloud intermediary, the hard cap needs to be on the cloud side, not Anthropic’s. That’s Rule 5.

What doesn’t count as a hard cap: email alerts (“you’ve burned through 80% of your budget”). They arrive with a delay, and nobody reads email at night. Only a synchronous provider-side barrier.

How Anthropic Task Budgets work and where to set them (Rule 2)#

See Anthropic’s official documentation for details. The key point: this is a soft boundary, not a hard one. If the agent has already created an EC2 instance, Task Budget won’t undo that.

How it works in practice: you pass the task_budget field in the request payload (for example, 100,000 input tokens for the entire task). Claude gets information about the budget and cuts back its plans on its own, simplifying steps or skipping subtasks. As the budget approaches zero, it winds down and returns an interim summary instead of a “thanks for listening.”

Limitations:

• Anthropic API only. It doesn’t work on Bedrock/Vertex, which have their own billing
• Beta models only (Opus 4.7, 4.8, Fable 5, Mythos 5). Not on Sonnet 4.6 or Haiku
• Doesn’t cover cloud spending or third-party APIs. If Claude spins up an EC2 instance, Task Budget stays silent

Use it together with Rule 1 (hard cap), not instead of it.

Cost guardrails are part of context engineering: you decide what the agent can and can’t do and where its emergency stop is.

Claude Code hooks: what should PreToolUse block? (Rule 3)#

Permissions in Claude Code (as of June 1, 2026) are evaluated in the order deny → ask → allow. That means:

• check the selected permission mode separately; do not infer bypass-mode protection from a normal-mode deny-rule test
• if a hook returns exit 2, the tool call is blocked
• allowedTools applies only when deny rules and hooks are silent

A minimal PreToolUse hook that checks a few dangerous command spellings. It is a text filter, not a complete shell parser or an access boundary: equivalent commands, scripts, other tools, and existing cloud resources need separate controls.

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

# Checks the listed text patterns; does not cover every equivalent operation
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

Save the script at the indicated path, ensure jq is available, and make it executable with chmod +x ~/.claude/hooks/block-dangerous-bash.sh. Bind it in ~/.claude/settings.json:

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

See the official documentation.

Check /hooks to confirm registration, then pass harmless sample JSON to the script without executing its command field. A listed destructive spelling should return 2; a benign command should return 0. Test malformed input too. The regex checks only matched Bash calls; use narrow credentials and environment isolation for the actual authority boundary. See the official hook input and output example.

Why use an allowedTools whitelist and why --dangerously-skip-permissions isn’t for the host (Rule 4)#

A whitelist is the principle of least privilege. Instead of “allow everything” (--dangerously-skip-permissions), add only what the task needs:

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

What you need to know about bypass mode:

• Linux/macOS refuse to start Claude Code in bypass mode as root or with sudo—built-in protection
• On your own machine, bypass disables all confirmation prompts, and the agent can rm -rf whatever it wants, open SSH keys, and upload data to the cloud
• Never run --dangerously-skip-permissions on the host, only in:
  • a Docker container with a limited volume mount (only the required folder)
  • an isolated VM (Multipass, Lima, Orbstack)
  • GitHub Codespaces / Replit / another sandbox

A minimal docker run for bypass mode:

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

If the agent needs cloud credentials, use separate keys with narrow scopes, not your main ones (Rule 6).

How to set up cloud budget alerts with a kill switch in AWS, GCP, and Yandex Cloud (Rule 5)#

How to set it up in each cloud:

AWS Budgets (docs). Create a monthly budget plus thresholds (50%, 80%, 100%). At the 100% threshold, an SNS topic can invoke a response Lambda. The example below deactivates the named user’s IAM access keys only; it neither stops resources nor establishes a hard spending cap:

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

Bounded resource-stop procedure: For a dedicated sandbox containing approved EBS-backed EC2 instances, record the account, Regions, and exact instance IDs before the run. In the EC2 console, select only those instances → Instance state → Stop instance → confirm, then verify each reaches stopped. Preserve any needed instance-store data first; stopping erases it. Check that an approved scheduler or scaling system cannot replace them. This stops that compute use, not all account charges: review retained storage and other services separately. Follow the official EC2 stop procedure.

AWS Budgets documentation warns that notifications lag resource usage and further costs may accrue before and after an alert. Triggering at 100% therefore cannot enforce an exact monetary ceiling.

GCP Budget Alerts. Create a Budget → Pub/Sub topic → Cloud Function that disables the Service Account. An important tip from the docs: alerts only notify, they don’t shut things down, so the Cloud Function is essential.

Yandex Cloud (docs). Set budgets under Billing → Budgets, plus resource quotas as a hard cap. You can connect notifications to a Telegram bot through Cloud Functions.

OpenAI API. Soft and hard spending limits are right in the dashboard—the hard limit automatically stops the API; no Lambda is needed.

Use a verified provider-side hard limit where available, delayed budget alerts, narrow credentials, and a tested response for the specific resources the agent can create. Credential revocation blocks some new operations; shutdown verification is needed for ongoing resource use. Neither an alert nor a success message from the key-revocation Lambda proves that all billing stopped.

Why an agent needs a separate sandbox API key with a narrow scope (Rule 6)#

A minimal AWS setup:

1. Create the IAM user claude-agent-scan
2. Policy: only the required actions (for example, ec2:RunInstances in one region with t3.micro size, without a VPC elastic IP)
3. Attach it to a separate AWS account (through Organizations) with a $100 monthly budget
4. Generate access keys and give them only to the agent; don’t put them in your own ~/.aws/credentials
5. After the session, rotate the keys or delete the user

Likewise for other providers:

• OpenAI / Anthropic: a separate API key for each agent, a hard cap for each key in the dashboard, and agent_id tags in request metadata
• Stripe / YooKassa: a restricted API key for one action (for example, charges:read only), and a separate merchant if possible
• Telegram Bot API: a separate bot token, not the main one

The old security principle applies here: least privilege—the agent gets exactly what the task needs, not one byte more. If the task is “scan the network,” don’t give it ec2:* and s3:*; give it only ec2:DescribeInstances and that’s it.

When to use a pre-flight dry run and an iteration limit (Rule 7)#

Plan Mode (/plan) is enabled at the start of a session. The agent prepares a plan, shows it in chat, waits for approval, and only then gets to work. It’s free and prevents 70% of “oops, I thought it would ask first” cases.

--max-turns is a launch flag. Each turn is one cycle of “agent thinks + tool call + result.” For autonomous tasks:

• small change: 5–10 turns
• medium task: 15–30 turns
• large autonomous task: 50–80 turns

Additional techniques:

• Wall-clock timeout with the Linux timeout command:

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

• Log every tool call to a file with a PostToolUse hook so you can see what happened afterward
• Cron monitoring—every 5 minutes, check that you don’t have 10 Claude processes running at once (a typical sign that something has gone wrong)

A ready-to-use 5-minute checklist before launching autonomous Claude Code#

Checklist before claude --dangerously-skip-permissions:

[ ] 1. Hard cap at the API provider (Anthropic Console → Limits → Monthly spend limit)
[ ] 2. Task Budget in the request payload (if using Opus 4.7+/Fable/Mythos)
[ ] 3. PreToolUse hook to block rm -rf, aws s3 rb, terraform destroy
[ ] 4. allowedTools whitelist in settings.json or work inside a Docker container
[ ] 5. Delayed cloud budget alerts + tested key revocation and approved resource shutdown
[ ] 6. Sandbox API keys (a separate key for the agent, not the main one)
[ ] 7. --max-turns N + timeout NNN seconds + process cron monitoring

If all seven are in place, launch. If even one is missing, stop and set it up. Thirty minutes now can save $6,000–500,000 later.

An example for context: a vibe coder launched an online store app with the default postgres database password. Within a couple of days, someone found it, installed miners, and deployed their own backdoors. The server had to be killed, and the month’s bill went up because of someone else’s crypto mining.

This story is about category 3 from Section 1 (third parties running things on your infrastructure), but the logic is the same: spending controls shouldn’t depend on who initiated the spending—your agent, your employee, or a miner in Nigeria.

Further reading:

• How to protect Claude Code from breakage—about --dangerously-skip-permissions and permissions from another angle
• Vibe coding security—the security pillar
• How not to burn through Claude Code limits in one day—about subscription tokens (don’t confuse this with this guide to cloud bills)

Get to know Ailoot.