controlar costos de agentes IA en un VPS

Cómo evitar que un agente de IA siempre activo aumente los costos

El control de costos de un agente de IA en un VPS (servidor privado virtual) consiste en establecer límites antes de iniciar el agente, ya que nadie supervisa el consumo mientras se ejecuta. Limite cada respuesta con max_tokens, restrinja las iteraciones del bucle en su propio código, almacene en caché la parte del prompt que no cambia y registre las métricas de uso de cada respuesta para identificar qué tarea genera gastos. El alquiler del servidor tiene un precio mensual fijo. La API del modelo se factura por token, y un bucle sin supervisión consume tokens rápidamente de forma silenciosa.

Esto asume que el agente ya existe y llama a la Messages API desde un servidor propio. Construcción de un agente de IA con Claude en un VPS cubre el funcionamiento del sistema.

Por qué un agente no supervisado tiene una estructura de costos distinta

Una sesión interactiva requiere la presencia de un humano. Si el modelo sigue un camino incorrecto o lee un log de 40,000 líneas, la persona que supervisa puede detenerlo. Un agente no supervisado no tiene ese freno: se ejecuta hasta que el bucle termina y luego un temporizador lo reinicia.

La frecuencia es el multiplicador que suele pasarse por alto. Un trabajo con un intervalo de cinco minutos se ejecuta 288 veces al día y aproximadamente 8,640 veces al mes. El costo total es el resultado de multiplicar el costo de una ejecución por ese número. Muchos agentes "siempre activos" no necesitan estar activos permanentemente. Solo necesitan responder dentro de un número determinado de minutos, lo cual es un horario programado.

Un agente también genera costos por elementos que una ventana de chat no genera.

• Las definiciones de herramientas se incluyen en cada solicitud. El prompt de sistema para el uso de herramientas cuesta 290 tokens en Claude Opus 4.8 con tool_choice de auto o none, y 410 con any o tool. La herramienta bash añade 325 tokens adicionales. Cada servidor MCP que conectes añade sus esquemas a ese peso; MCP es el Model Context Protocol.
• Los resultados de las herramientas son tokens de entrada. Un comando que imprime 8,000 líneas añade esas 8,000 líneas a la siguiente solicitud, y a cada una de las solicitudes posteriores de ese turno.
• Las páginas obtenidas son tokens de entrada. Una página web promedio de 10 kB equivale aproximadamente a 2,500 tokens y un PDF de investigación de 500 kB equivale aproximadamente a 125,000. max_content_tokens solo trunca los archivos de texto, porque "se aplica al contenido de texto, no al contenido binario como los PDFs". Utilice max_uses y allowed_domains para archivos PDF.
• La búsqueda web se cobra por búsqueda, a $10 por cada 1,000 búsquedas, independientemente del número de resultados obtenidos. Las búsquedas que fallan no se cobran.

Nada de esto es costoso en una sola ejecución. Todo esto es costoso cuando se repite 8,640 veces.

Los límites rígidos y los límites flexibles resuelven problemas distintos

Se aplica max_tokens. Es un tope máximo para la salida total de una solicitud, sumando el texto de pensamiento y el de respuesta. Claude nunca genera más allá de este límite y el modelo no puede ver el número. Alcanzarlo produce stop_reason: "max_tokens" y una respuesta truncada. El problema para los agentes: cada solicitud en un bucle de uso de herramientas tiene su propio max_tokens, por lo que limita una respuesta y no la tarea completa. Diez llamadas a herramientas de 4,000 tokens implican un límite de 40,000 tokens por turno.

Un presupuesto de tarea es consultivo. task_budget se encuentra dentro de output_config e indica al modelo cuántos tokens tiene para todo el bucle de agente, contando el pensamiento, las llamadas a herramientas, los resultados de las herramientas y la salida.

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

"Los presupuestos de tarea son una indicación flexible, no un límite rígido". Claude puede exceder uno durante una acción, y el límite aplicado a la salida sigue siendo max_tokens. "La cuenta regresiva es visible solo para el modelo" y las respuestas no incluyen un campo de presupuesto restante. El task_budget.total mínimo aceptado es de 20,000 tokens; un valor menor devuelve un error 400. Un presupuesto demasiado pequeño para el trabajo produce un comportamiento similar al de una negativa, por lo que el modelo reduce el alcance de la tarea o se detiene antes.

Un detalle genera costes en lugar de ahorros. Si su cliente decrementa task_budget.remaining en cada solicitud de seguimiento, el valor modificado invalida cualquier prefijo en caché que lo contenga. Defínalo una sola vez, en la primera solicitud.

Los presupuestos de tarea están en beta en Claude Fable 5, Claude Opus 4.8 y Claude Opus 4.7. Claude Sonnet 5 y Claude Haiku 4.5 figuran como Not supported, y los presupuestos de tarea no se aplican a Claude Code, por lo que una sesión de Claude Code desvinculada en tmux depende de la gestión de la sesión.

El tercer límite se encuentra en Claude Console: asigne al agente su propio workspace y luego establezca un límite de gasto mensual y límites de tasa por minuto. "No puede establecer límites en el Default Workspace" y "Los límites de toda la organización siempre se aplican, incluso si los límites del workspace suman más". Añada notificaciones de gasto para que un umbral le alerte antes de que se alcance el tope.

Elección de modelo por tarea y qué factores afectan el esfuerzo

La elección del modelo se decide por cada tarea. A partir de julio de 2026, el coste por millón de tokens (entrada y luego salida) es: Claude Fable 5 a $10 y $50, Claude Opus 4.8 y Opus 4.7 a $5 y $25, Claude Sonnet 5 a $3 y $15, Claude Haiku 4.5 a $1 y $5. Sonnet 5 tiene un precio inferior al oficial actualmente, debido a que "la tarifa de introducción de $2/$10 por millón de tokens de entrada/salida estará vigente hasta el 31 de agosto de 2026". Un proceso que solo clasifique líneas de log no requiere Opus.

El esfuerzo es el segundo factor de ajuste. output_config.effort acepta low, medium, high, xhigh y max, siendo high el valor por defecto; por tanto, configurar high explícitamente es equivalente a omitirlo. Reducir el esfuerzo ahorra más que solo acortar la longitud del razonamiento: la documentación indica que hace que Claude realice menos llamadas a herramientas y combine operaciones en una sola. En un agente, este es el ahorro principal, ya que evitar una llamada a una herramienta elimina una solicitud completa.

El problema es que el esfuerzo entra en conflicto con la caché. Cambiar el valor entre solicitudes invalida el prompt caching. En el ejemplo documentado, la solicitud 2 reportó cache_read_input_tokens: 3546; la solicitud 3, con el esfuerzo cambiado de high a medium, reportó cache_creation_input_tokens de 3546 y cache_read_input_tokens de 0. Por tanto, varíe el esfuerzo entre cargas de trabajo, nunca dentro de una misma conversación con caché. Para controlar la profundidad sin romper la caché, hágalo en el prompt: una línea como "Responde directamente sin deliberar" en el mensaje de usuario más reciente mantiene intactos los breakpoints anteriores.

Los tokens de pensamiento se cobran a tarifa de salida y cuentan para max_tokens, razón por la cual una respuesta truncada suele significar que el pensamiento agotó el presupuesto. Consulte usage.output_tokens_details.thinking_tokens para ver la cifra. Qué llena realmente una factura de tokens de Claude analiza el detalle del consumo.

Cachee el prefix estable y evite romperlo accidentalmente

Una escritura en caché cuesta 1.25 veces el precio base de entrada en la caché de cinco minutos y 2 veces en la caché de una hora. Una lectura en caché cuesta 0.1 veces, por lo que "el uso de caché es rentable tras solo una lectura para la duración de 5 minutos (1.25x escritura), o tras dos lecturas para la duración de 1 hora (2x escritura)".

Una frase explica por qué esto es ideal para un agente siempre activo: "La caché se actualiza sin coste adicional cada vez que se utiliza el contenido almacenado". Un proceso que se ejecute cada dos minutos contra la caché de cinco minutos mantiene su prefix activo todo el día con una sola escritura.

Tres formas de perder la caché sin darse cuenta.

Un prefix que cambia. "Los prefix de caché se crean en el siguiente orden: tools, system, y luego messages." Cualquier cambio de byte en un orden anterior invalida todo lo posterior, y editar las definiciones de las herramientas invalida la caché completa. El error clásico es incluir un timestamp o un run id en el system prompt: cada petición tendrá un prefix distinto, realizará una escritura nueva a 1.25x y no recuperará nada de la caché. El indicador es un valor de usage.cache_read_input_tokens en 0 en llamadas que parecen idénticas. Mueva el texto volátil al mensaje de usuario más reciente.

Un prefix demasiado corto. Cada modelo tiene una longitud mínima para ser cacheable; por debajo de ese límite, la petición se procesa sin caché y "no se devuelve ningún error". Las cifras incluyen 1,024 tokens en Claude Opus 4.8 y Claude Sonnet 5, y 4,096 en Claude Haiku 4.5, por lo que cambiar un proceso de Sonnet a Haiku puede desactivar la caché silenciosamente.

Una conversación que supera el periodo de retención. "La ventana de retención es de 20 bloques." El sistema comprueba como máximo 20 posiciones por breakpoint y luego se detiene. En el ejemplo documentado, un turno con 35 bloques y un breakpoint en el bloque 35 comprueba desde el bloque 35 hasta el 16; la entrada del turno anterior en el bloque 15 queda fuera de la ventana y no hay acierto (hit). Un agente que añada varios bloques de tool-use y tool-result por turno superará los 20 bloques en dos o tres turnos. Usted tiene cuatro breakpoints por petición, así que asigne uno a los mensajes recientes.

Envíe cualquier tarea diferible a la Batches API

"Todo el uso se factura al 50% de los precios estándar de la API", tanto para la entrada como para la salida. El procesamiento por lotes es asíncrono; "la mayoría de los lotes finalizan en menos de 1 hora". Los resultados estarán disponibles cuando todas las solicitudes hayan terminado o después de 24 horas, lo que ocurra primero. Esto es lo habitual, no una garantía.

Consulte processing_status hasta que el valor sea ended. Las solicitudes que devuelvan errored, canceled o expired no se facturan. Una advertencia si utiliza un límite de gasto: "los lotes pueden exceder ligeramente el límite de gasto configurado para su Workspace."

Los descuentos son acumulables. Debido a que un lote puede tardar más de cinco minutos, la documentación recomienda el uso de caché de una hora para lotes que compartan contexto. Por tanto, divida el trabajo: cualquier tarea de la que dependa una persona o un webhook debe permanecer en el flujo principal, mientras que un resumen nocturno o la clasificación de logs del día anterior debe enviarse a un lote a mitad de precio.

Registre los campos de uso de cada respuesta en su propio almacén

No puede atribuir gastos que no haya registrado. Cada respuesta indica su coste.

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

Añada una fila por cada llamada a la API en un archivo JSON-lines, etiquetada con el nombre de su tarea. Una semana después podrá identificar qué tareas generan gastos y cuáles solo parecen tener actividad. Vigile cache_read: una columna de ceros es el error de coste más común en un agente auto-alojado.

Un campo es fácil de interpretar erróneamente. input_tokens solo cuenta los tokens después del último punto de interrupción de la caché, por lo que el tamaño real del prompt es total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Un agente que reporte input_tokens: 400 en un prompt extenso no es económico: el resto provino de la caché.

Cuente antes de enviar. El conteo de tokens es gratuito y sus límites de tasa son independientes de la creación de mensajes; use count_tokens para rechazar un archivo adjunto demasiado grande en lugar de pagar para descubrirlo. El resultado es una estimación, así que vuelva a medir por modelo y nunca reutilice un conteo de un tokenizador de otro proveedor. Claude Opus 4.7 y modelos Opus posteriores, Claude Fable 5 y Claude Sonnet 5 utilizan un tokenizador más nuevo que "produce aproximadamente un 30% más de tokens para el mismo texto". Claude Sonnet 4.6 y anteriores, incluyendo Claude Haiku 4.5, utilizan el anterior.

Para obtener la información oficial, la Admin API reporta el uso en https://api.anthropic.com/v1/organizations/usage_report/messages y el coste en https://api.anthropic.com/v1/organizations/cost_report. Ambos requieren una clave de administrador (sk-ant-admin01-...) como x-api-key: $ANTHROPIC_ADMIN_KEY con anthropic-version: 2023-06-01, y aceptan bucket_width=1d, group_by[]=model y api_key_ids[]=. Una limitación: "La Admin API no está disponible para cuentas individuales".

Ese último parámetro es un truco de atribución económico: asigne a cada tarea su propia clave de API, filtre con api_key_ids[] y divida el reporte por clave con group_by[]=api_key_id. El filtro es plural, la dimensión de agrupación es singular. Mantenga las claves en el entorno en lugar de en el código, de la misma forma que las gestiona una primera aplicación de Claude API en un VPS.

Limite el bucle, porque nada más lo hará

Un recuento de iteraciones limitado es obligatorio en este caso. El bucle es suyo, por lo tanto, el contador también es suyo:

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

Ninguno de los límites anteriores lo hace por usted: max_tokens limita una respuesta, y el modelo solo recibe un presupuesto de tareas.

Implemente un segundo freno fuera del proceso. Ejecute el trabajo mediante un timer de systemd en lugar de un proceso permanente, y configure RuntimeMaxSec= en su unidad de servicio. Con RuntimeMaxSec=600, un proceso bloqueado se detiene tras diez minutos en lugar de ejecutarse indefinidamente hasta que usted lo detecte. Ejecutar un programa como un servicio y un timer de systemd explica los archivos de unidad. Consulte qué hizo una ejecución con journalctl -u triage-agent.service --since "1 hour ago".

Limite también los reintentos, ya que un manejador que reintenta infinitamente genera costes en cada intento. Un error 429 o un 500 justifica algunos reintentos con backoff. Un error 400 no justifica ninguno, ya que la misma petición fallará de la misma manera.

El control de costos de un agente de IA comienza con el análisis de sus propios datos

Nadie puede determinar el costo de un agente que funciona continuamente. El costo es el resultado de multiplicar los tokens por ejecución por las ejecuciones diarias; ambos valores dependen de usted. Ejecute el agente una vez, revise la fila de uso registrada y multiplique por su frecuencia de ejecución. Compare el informe de costos dos días después con ese cálculo. Si los valores no coinciden, la diferencia suele deberse a un caché fallido o a un bucle que duró más de lo previsto.

Esto asume el uso de una API key, ya que el agente es su propio programa llamando a la Messages API. Para su trabajo interactivo, qué plan de Claude se adapta a su forma de trabajar cubre la parte de la suscripción. Todos los precios y límites aquí presentados se verificaron con la documentación de Anthropic en julio de 2026; revise la página de precios antes de elaborar un presupuesto.

FAQ

¿Cuál es el coste de ejecutar un agente de IA siempre activo en un VPS?

Hay dos facturas y solo una es predecible. El servidor tiene un precio mensual fijo. La API del modelo se factura por token, por lo que el coste es el consumo de una ejecución multiplicado por la frecuencia de ejecución. Anthropic no publica cifras para agentes siempre activos alojados localmente, así que cualquier cifra citada es una estimación. Registre usage de una ejecución real y multiplíquelo por su programación.

¿Cuál es la diferencia entre max_tokens y un presupuesto de tarea (task budget)?

max_tokens es obligatorio e invisible para el modelo. Limita la salida de una solicitud, incluyendo el razonamiento, y alcanzarlo produce stop_reason: "max_tokens". Un presupuesto de tarea es lo opuesto: se le indica el número al modelo y este ajusta el ciclo del agente según este valor, pero "Los presupuestos de tarea son una indicación suave, no un límite estricto" y el límite obligatorio sigue siendo max_tokens.

¿Por qué cache_read_input_tokens siempre es cero para mi agente?

Porque el prefijo cambia entre llamadas o es demasiado corto para ser almacenado en caché. La causa habitual es un timestamp o un run id interpolado en el system prompt: la caché se basa en el prefijo, por lo que cualquier cambio de byte invalida todo lo posterior. Cambiar las definiciones de las herramientas o el valor effort produce el mismo efecto. Por lo demás, puede ser el tamaño, ya que los prompts cortos no se almacenan en caché y no se devuelve ningún error.

¿Cómo evito que un agente de IA entre en un bucle infinito?

Cuente las iteraciones en su código de bucle y deténgase en un máximo fijo, porque max_tokens limita una respuesta y un agente realiza muchas. Añada un límite de tiempo real fuera del proceso: inicie el trabajo desde un timer de systemd con RuntimeMaxSec= configurado, para que una ejecución bloqueada se detenga según el cronograma. Limite también los reintentos, ya que un bucle de reintentos factura cada intento.

¿Puedo establecer un límite de gasto en una única clave de API de Claude?

El límite de gasto documentado es por workspace en lugar de por clave, así que asigne al agente un workspace propio y limite su gasto mensual allí. "No puede establecer límites en el Default Workspace". Añada notificaciones de gasto para que un umbral le avise primero. Para la atribución, asigne a cada trabajo su propia clave y luego agrupe el informe de uso con group_by[]=api_key_id.