7 reglas de Claude Code para limitar el gasto de los agentes autónomos en 2026

Aprende a trabajar con el servicio en la documentación de Ailoot.

¿En qué gasta dinero un agente de inteligencia artificial autónomo?#

No confundas estos tres canales: funcionan de manera independiente y requieren ajustes distintos:

1. Tokens de LLM. Claude, OpenAI o Gemini cobran por el contexto de entrada y salida de cada solicitud. Anthropic Task Budgets (consulta la regla 2) y una suscripción en lugar del pago por uso de la API pueden ayudar aquí.
2. Infraestructura en la nube. A través de MCP o una herramienta Bash, el agente crea recursos EC2, RDS y S3, o despliega lambdas. AWS Budgets, GCP o Yandex Cloud con un interruptor de emergencia pueden ayudar aquí (regla 5).
3. API de terceros. El agente realiza un cargo de Stripe, envía 100 SMS mediante una pasarela o configura mil suscripciones de Telegram. Las claves sandbox con permisos limitados y un límite estricto en el panel del proveedor pueden ayudar aquí (regla 6).

A continuación, 7 reglas. Cada una cubre uno o dos canales.

¿Cómo establecer un límite de gasto en la API para un agente de Claude Code?#

Dónde activarlo (reserva al menos 2 minutos por proveedor):

Anthropic Console. console.anthropic.com → Settings → Limits → Monthly spend limit. Establece el importe que estarías dispuesto a perder en el peor mes. Cuando se alcance, la API devolverá 429 y registrará el evento. No hay «lo intento otra vez dentro de un minuto»: queda bloqueado hasta fin de mes.

OpenAI Platform. platform.openai.com → Billing → Usage limits. Del mismo modo, hay un límite flexible (alerta por correo electrónico) y un límite estricto (apagado de la API). Configura ambos; establece el límite estricto en 1,5 veces el flexible para dejar margen de reacción.

AWS Bedrock / Google Vertex. Si accedes a Claude/Anthropic a través de un intermediario en la nube, el límite estricto debe estar en el lado de la nube, no en Anthropic. Esa es la regla 5.

Lo que no cuenta como límite estricto: las alertas por correo electrónico («has gastado el 80 % de tu presupuesto»). Llegan con retraso y nadie lee el correo por la noche. Solo sirve una barrera síncrona del lado del proveedor.

Cómo funcionan Anthropic Task Budgets y dónde configurarlos (regla 2)#

Consulta la documentación oficial de Anthropic para obtener más detalles. Lo importante: es un límite flexible, no uno estricto. Si el agente ya ha creado una instancia EC2, Task Budget no la deshará.

Cómo funciona en la práctica: pasas el campo task_budget en el payload de la solicitud (por ejemplo, 100.000 tokens de entrada para toda la tarea). Claude recibe información sobre el presupuesto y reduce sus propios planes, simplifica pasos o se salta subtareas. A medida que el presupuesto se acerca a cero, va terminando y devuelve un resumen provisional en lugar de un «gracias por escuchar».

Limitaciones:

• Solo API de Anthropic. No funciona en Bedrock/Vertex, que tienen su propia facturación
• Solo modelos beta (Opus 4.7, 4.8, Fable 5, Mythos 5). No está disponible en Sonnet 4.6 ni Haiku
• No cubre el gasto en la nube ni las API de terceros. Si Claude inicia una instancia EC2, Task Budget no hace nada

Úsalo junto con la regla 1 (límite estricto), no en lugar de ella.

Los límites de costos forman parte de la ingeniería de contexto: decides qué puede y qué no puede hacer el agente y dónde está su parada de emergencia.

Qué bloquear con los hooks PreToolUse en Claude Code (regla 3)#

A fecha del 1 de junio de 2026, los permisos en Claude Code se evalúan en este orden: deny → ask → allow. Esto significa que:

• comprueba por separado el modo de permisos seleccionado; una prueba de deny en modo normal no demuestra protección en un modo que omite permisos
• si un hook devuelve exit 2, la llamada a la herramienta queda bloqueada
• allowedTools solo se aplica cuando las reglas deny y los hooks no intervienen

Un hook PreToolUse mínimo que comprueba algunas formas de escribir comandos peligrosos. Es un filtro de texto, no un intérprete completo del shell ni un límite de acceso: los comandos equivalentes, scripts, otras herramientas y recursos de nube existentes necesitan controles 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

# Comprueba los patrones de texto enumerados; no cubre todas las operaciones 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

Guarda el script en la ruta indicada, comprueba que jq esté disponible y dale permiso de ejecución con chmod +x ~/.claude/hooks/block-dangerous-bash.sh. Vincúlalo en ~/.claude/settings.json:

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

Consulta la documentación oficial.

Comprueba en /hooks que esté registrado y pásale al script ejemplos JSON inocuos sin ejecutar su campo de comando. Una forma destructiva incluida en la lista debe devolver 2; un comando inocuo debe devolver 0. Prueba también una entrada malformada. La expresión regular solo comprueba las llamadas Bash coincidentes; usa credenciales limitadas y aislamiento del entorno para el límite real de autoridad. Consulta el ejemplo oficial de entrada y salida de hooks.

Por qué usar una lista de permitidos allowedTools y por qué --dangerously-skip-permissions no debe usarse en el host (regla 4)#

Una lista de permitidos aplica el principio de mínimo privilegio. En lugar de «permitir todo» (--dangerously-skip-permissions), añade solo lo que la tarea necesita:

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

Lo que debes saber sobre el modo de omisión:

• Linux/macOS se niegan a iniciar Claude Code en modo de omisión como root o con sudo: protección integrada
• En tu propia máquina, el modo de omisión desactiva todas las solicitudes de confirmación; el agente puede ejecutar rm -rf sobre lo que quiera, abrir claves SSH y subir datos a la nube
• Nunca ejecutes --dangerously-skip-permissions en el host; úsalo solo en:
  • un contenedor Docker con un montaje de volumen limitado (solo la carpeta necesaria)
  • una VM aislada (Multipass, Lima, Orbstack)
  • GitHub Codespaces / Replit / otro entorno aislado

Un comando docker run mínimo para el modo de omisión:

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

Si el agente necesita credenciales de la nube, usa claves separadas con permisos limitados, no las principales (regla 6).

Cómo configurar alertas de presupuesto en la nube con un interruptor de emergencia en AWS, GCP y Yandex Cloud (regla 5)#

Cómo configurarlo en cada nube:

AWS Budgets (documentación). Crea un presupuesto mensual con umbrales (50 %, 80 %, 100 %). Al llegar al umbral del 100 %, un tema SNS puede invocar una Lambda de respuesta. El ejemplo siguiente solo desactiva las claves de acceso IAM del usuario indicado; no detiene recursos ni establece un límite estricto de gasto:

import boto3

def lambda_handler(event, context):
    iam = boto3.client('iam')
    # Desactiva todas las claves del usuario «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': 'IAM keys deactivated; existing resources unchanged'}

Procedimiento acotado para detener recursos: en un sandbox dedicado con instancias EC2 aprobadas respaldadas por EBS, registra antes de ejecutarlo la cuenta, las regiones y los ID exactos de instancias. En la consola EC2, selecciona solo esas instancias → Instance state → Stop instance → confirma y verifica que cada una alcance stopped. Conserva antes los datos necesarios del almacenamiento de instancia; detenerla los elimina. Comprueba que un programador o sistema de escalado aprobado no pueda sustituirlas. Esto detiene ese uso de cómputo, no todos los cargos de la cuenta: revisa por separado el almacenamiento conservado y otros servicios. Sigue el procedimiento oficial de detención de EC2.

La documentación de AWS Budgets advierte de que las notificaciones van por detrás del uso de recursos y de que pueden generarse costes antes y después de una alerta. Por tanto, activar la respuesta al 100 % no impone un techo monetario exacto.

GCP Budget Alerts. Crea un presupuesto → tema Pub/Sub → Cloud Function que desactive la Service Account. Un consejo importante de la documentación: las alertas solo notifican, no apagan nada, por eso la Cloud Function es esencial.

Yandex Cloud (documentación). Establece presupuestos en Billing → Budgets, además de cuotas de recursos como límite estricto. Puedes conectar las notificaciones a un bot de Telegram mediante Cloud Functions.

OpenAI API. Los límites de gasto flexible y estricto están directamente en el panel: el límite estricto detiene automáticamente la API; no se necesita ninguna Lambda.

Utiliza un límite estricto verificado del proveedor donde exista, alertas de presupuesto sujetas a retrasos, credenciales limitadas y una respuesta probada para los recursos concretos que el agente pueda crear. Revocar credenciales bloquea algunas operaciones nuevas; para el uso continuado de recursos hay que verificar su apagado. Ni una alerta ni el mensaje de éxito de la Lambda de revocación demuestran que toda la facturación se haya detenido.

Por qué un agente necesita una clave API sandbox independiente con permisos limitados (regla 6)#

Configuración mínima de AWS:

1. Crea el usuario IAM claude-agent-scan
2. Política: solo las acciones necesarias (por ejemplo, ec2:RunInstances en una región con tamaño t3.micro, sin una IP elástica de VPC)
3. Asígnalo a una cuenta AWS separada (mediante Organizations) con un presupuesto mensual de 100 $
4. Genera claves de acceso y dáselas solo al agente; no las pongas en tu propio ~/.aws/credentials
5. Tras la sesión, rota las claves o elimina el usuario

Lo mismo para otros proveedores:

• OpenAI / Anthropic: una clave API separada para cada agente, un límite estricto para cada clave en el panel y etiquetas agent_id en los metadatos de las solicitudes
• Stripe / YooKassa: una clave API restringida a una acción (por ejemplo, solo charges:read) y un comercio separado si es posible
• Telegram Bot API: un token de bot separado, no el principal

Aquí se aplica el antiguo principio de seguridad: mínimo privilegio; el agente obtiene exactamente lo que necesita la tarea, ni un byte más. Si la tarea es «analizar la red», no le des ec2:* ni s3:*; dale solo ec2:DescribeInstances y nada más.

Cuándo usar una ejecución de prueba previa y un límite de iteraciones (regla 7)#

Plan Mode (/plan) se activa al inicio de una sesión. El agente prepara un plan, lo muestra en el chat, espera tu aprobación y solo entonces empieza a trabajar. Es gratis y evita el 70 % de los casos de «vaya, pensaba que preguntaría primero».

--max-turns es una opción de lanzamiento. Cada turno es un ciclo de «el agente piensa + llamada a herramienta + resultado». Para tareas autónomas:

• cambio pequeño: 5–10 turnos
• tarea mediana: 15–30 turnos
• tarea autónoma grande: 50–80 turnos

Técnicas adicionales:

• Tiempo límite con el comando Linux timeout:

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

• Registra cada llamada a herramienta en un archivo con un hook PostToolUse para que puedas ver después lo que ocurrió
• Supervisión con Cron: cada 5 minutos, comprueba que no haya 10 procesos de Claude ejecutándose a la vez (una señal típica de que algo ha ido mal)

Lista de comprobación lista para usar en 5 minutos antes de iniciar Claude Code autónomo#

Lista de comprobación antes de claude --dangerously-skip-permissions:

[ ] 1. Límite estricto en el proveedor de API (Anthropic Console → Limits → Monthly spend limit)
[ ] 2. Task Budget en el payload de la solicitud (si usas Opus 4.7+/Fable/Mythos)
[ ] 3. Hook PreToolUse para bloquear rm -rf, aws s3 rb, terraform destroy
[ ] 4. Lista de permitidos allowedTools en settings.json o trabajo dentro de un contenedor Docker
[ ] 5. Alertas de presupuesto de nube sujetas a retrasos + revocación de claves y apagado de recursos aprobados probados
[ ] 6. Claves API sandbox (una clave separada para el agente, no la principal)
[ ] 7. --max-turns N + timeout de NNN segundos + supervisión de procesos con Cron

Si están los siete, adelante. Si falta aunque sea uno, detente y configúralo. Treinta minutos ahora pueden ahorrarte entre 6.000 y 500.000 $ más adelante.

Un ejemplo para ponerlo en contexto: un creador de código por intuición lanzó una aplicación para una tienda en línea con la contraseña predeterminada de la base de datos postgres. En un par de días, alguien la encontró, instaló mineros y desplegó sus propias puertas traseras. Hubo que apagar el servidor y la factura del mes aumentó por la minería de criptomonedas de otra persona.

Esta historia corresponde a la categoría 3 de la sección 1 (terceros que ejecutan cosas en tu infraestructura), pero la lógica es la misma: los controles de gasto no deben depender de quién lo inició, ya sea tu agente, un empleado o un minero en Nigeria.

Lecturas adicionales:

• Cómo proteger Claude Code de los daños: sobre --dangerously-skip-permissions y los permisos desde otro ángulo
• Seguridad en el vibe coding: el pilar de seguridad
• Cómo no agotar los límites de Claude Code en un día: sobre los tokens de suscripción (no lo confundas con esta guía sobre facturas de la nube)

Conoce Ailoot.