Cómo controlar el coste de un agente de IA en un VPS

Cómo evitar que un agente de IA siempre activo dispare los costes

El control de costes de un agente de IA en un VPS (servidor privado virtual) consiste en establecer límites antes de iniciar el agente, porque nadie supervisa el contador mientras se ejecuta. Limite cada respuesta con max_tokens, establezca un máximo de iteraciones para el bucle en su propio código, almacene en caché la parte de la solicitud que no cambia y registre los datos de uso de cada respuesta para identificar qué tarea consume más. El alquiler del servidor tiene un precio mensual fijo. La API del modelo factura por token, y un bucle sin supervisión puede consumir tokens silenciosamente con mucha facilidad.

Se presupone que ya dispone de un agente que llama a la Messages API desde un servidor bajo su control. Crear un agente de IA con Claude en un VPS explica cómo configurar el agente.

Por qué un agente desatendido tiene una estructura de costes diferente

Una sesión interactiva tiene a una persona al otro lado. Si el modelo toma un camino equivocado o lee un registro de 40,000 líneas, la persona que lo supervisa lo detiene. Un agente desatendido no tiene ese freno: se ejecuta hasta que termina el bucle y, después, un temporizador lo inicia de nuevo.

La frecuencia es el multiplicador que suele pasarse por alto. Un trabajo programado cada cinco minutos se ejecuta 288 veces al día y unas 8,640 veces al mes. Multiplique el coste de una ejecución por esa cifra. Muchos agentes «siempre activos» no necesitan estar activos todo el tiempo. Necesitan responder en un plazo de ciertos minutos. Eso se resuelve con una programación.

Un agente también consume recursos que una ventana de chat no consume.

• Las definiciones de herramientas se incluyen en cada solicitud. El prompt de sistema para usar 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 otros 325. Cada servidor MCP que conecte añade sus esquemas a ese volumen; MCP es el protocolo de contexto del modelo.
• Los resultados de las herramientas son tokens de entrada. Un comando que imprime 8,000 líneas introduce 8,000 líneas en la siguiente solicitud y en todas las solicitudes posteriores de ese turno.
• Las páginas obtenidas son tokens de entrada. Una página web media de 10 kB equivale aproximadamente a 2,500 tokens y un PDF de investigación de 500 kB, a unos 125,000. max_content_tokens trunca sólo el texto porque «se aplica al contenido de texto, no al contenido binario, como los PDF». Limite un PDF con max_uses y allowed_domains.
• La búsqueda web se factura por búsqueda, a $10 por cada 1,000 búsquedas, independientemente del número de resultados. Las búsquedas que producen un error no se facturan.

Nada de esto resulta caro una sola vez. Todo resulta caro 8,640 veces.

Los límites estrictos y los límites flexibles resuelven problemas distintos

max_tokens se aplica de forma estricta. Es el límite máximo total de una solicitud, incluidos el razonamiento y el texto de la respuesta. Claude nunca lo supera y el modelo no puede ver ese número. Al alcanzarlo, se devuelve stop_reason: "max_tokens" y la respuesta queda truncada. El aspecto importante para los agentes es que cada solicitud de un ciclo de uso de herramientas tiene su propio max_tokens. Por tanto, limita una respuesta, no la tarea completa. Diez llamadas a herramientas de 4,000 tokens establecen un límite de 40,000 tokens para el turno.

El presupuesto de la tarea es orientativo. task_budget se encuentra dentro de output_config e indica al modelo cuántos tokens tiene para todo el ciclo agéntico, incluidos el razonamiento, 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 estricto." Claude puede superar uno durante una acción, y el límite aplicado a la salida sigue siendo max_tokens. "La cuenta atrás sólo es visible para el modelo", y las respuestas no incluyen un campo con el presupuesto restante. El valor mínimo aceptado para task_budget.total es de 20,000 tokens; un valor inferior devuelve un error 400. Un presupuesto demasiado pequeño para el trabajo produce un comportamiento similar a una negativa, por lo que el modelo reduce el alcance de la tarea o se detiene antes.

Un detalle genera costes en lugar de reducirlos. Si el cliente reduce task_budget.remaining en cada solicitud posterior, el valor modificado invalida cualquier prefijo almacenado en caché que lo contenga. Establézcalo 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 aparecen como Not supported, y los presupuestos de tarea no se aplican a Claude Code. Por tanto, una sesión de Claude Code separada en tmux depende de una gestión adecuada de la sesión.

El tercer límite se encuentra en Claude Console: asigne al agente su propio espacio de trabajo y establezca en él un límite de gasto mensual y límites de tasa por minuto. "No puede establecer límites en el espacio de trabajo predeterminado", y "los límites para toda la organización siempre se aplican, aunque la suma de los límites de los espacios de trabajo sea superior". Añada notificaciones de gasto para recibir una alerta al alcanzar un umbral, antes de llegar al límite.

Elección del modelo por trabajo y qué cambia realmente el nivel de esfuerzo

La elección del modelo depende de cada trabajo. En julio de 2026, el precio por millón de tokens, primero de entrada y después de salida, es el siguiente: Claude Fable 5 cuesta $10 y $50; Claude Opus 4.8 y Opus 4.7, $5 y $25; Claude Sonnet 5, $3 y $15; Claude Haiku 4.5, $1 y $5. Sonnet 5 se ofrece temporalmente por debajo de su precio habitual porque está vigente la «tarifa introductoria de $2/$10 por millón de tokens de entrada/salida hasta el 31 de agosto de 2026». Un paso que sólo clasifica líneas de registro no necesita Opus. Tampoco hay una asignación gratuita que absorba una carga de trabajo intensa, porque la API de Claude no tiene un nivel gratuito aparte del pequeño crédito concedido al registrarse.

El nivel de esfuerzo es la segunda palanca. output_config.effort acepta low, medium, high, xhigh y max, y el valor predeterminado es high, por lo que establecer high explícitamente equivale a omitirlo. Un nivel de esfuerzo menor reduce algo más que la longitud del razonamiento: la documentación indica que hace que Claude realice menos llamadas a herramientas y combine varias operaciones en una sola. En un agente, ese ahorro es mayor, porque evitar una llamada a una herramienta evita una solicitud completa.

El problema es que el nivel de esfuerzo entra en conflicto con la caché. Cambiar su valor entre solicitudes invalida la caché de prompts. En el ejemplo documentado, la solicitud 2 informó cache_read_input_tokens: 3546; la solicitud 3, cuyo nivel de esfuerzo cambió de alto a medio, informó cache_creation_input_tokens de 3546 y cache_read_input_tokens de 0. Por tanto, varíe el nivel de esfuerzo entre cargas de trabajo, nunca dentro de una misma conversación almacenada en caché. Para ajustar 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 puntos de interrupción anteriores.

Los tokens de razonamiento se facturan a las tarifas de salida y cuentan para max_tokens, por lo que una respuesta truncada suele indicar que el razonamiento consumió el presupuesto. Consulte usage.output_tokens_details.thinking_tokens para conocer la cantidad. Qué llena realmente una factura de tokens de Claude desglosa ese consumo.

Almacene en caché el prefijo estable y evite modificarlo por accidente

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 de caché cuesta 0.1 veces ese precio. Por tanto, «la caché resulta rentable después de una sola lectura para la duración de 5 minutos (escritura a 1.25x), o después de dos lecturas para la duración de 1 hora (escritura a 2x)».

Una línea explica por qué esto resulta adecuado para un agente siempre activo: «La caché se actualiza sin coste adicional cada vez que se utiliza el contenido almacenado». Un trabajo que se ejecuta cada dos minutos contra la caché de cinco minutos mantiene caliente su prefijo durante todo el día con una sola escritura.

Hay tres formas de perder la caché sin darse cuenta.

Un prefijo que cambia. «Los prefijos de caché se crean en el orden siguiente: tools, system y después messages». Cualquier cambio de byte anterior en ese orden invalida todo lo que viene después, y editar las definiciones de herramientas invalida toda la caché. El error clásico provocado por el propio usuario consiste en incluir una marca de tiempo o un identificador de ejecución en el mensaje del sistema: cada solicitud lleva entonces un prefijo diferente, escribe una entrada nueva a 1.25x y no obtiene ninguna lectura de vuelta. La señal es usage.cache_read_input_tokens con valor 0 en llamadas que parecen idénticas. Mueva el texto variable al mensaje de usuario más reciente.

Un prefijo demasiado corto. Cada modelo tiene una longitud mínima que se puede almacenar en caché. Por debajo de ese límite, la solicitud 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 tanto, mover un trabajo de Sonnet a Haiku puede desactivar la caché de forma silenciosa.

Una conversación que supera el historial disponible. «La ventana de historial es de 20 bloques». El sistema comprueba como máximo 20 posiciones en cada punto de ruptura y después se detiene. En el ejemplo documentado, un turno que contiene 35 bloques y tiene un punto de ruptura en el bloque 35 comprueba los bloques del 35 al 16. La entrada del turno anterior, en el bloque 15, queda fuera de la ventana y no se produce ningún acierto. Un agente que añade varios bloques de uso de herramientas y de resultados de herramientas en cada turno supera los 20 bloques en dos o tres turnos. Hay cuatro puntos de ruptura por solicitud, así que reserve uno para los mensajes recientes.

Envíe a la Batches API todo lo que pueda esperar

"Todo el uso se factura al 50% de los precios estándar de la API", tanto para las entradas como para las salidas. El procesamiento por lotes es asíncrono, "y la mayoría de los lotes finaliza en menos de 1 hora". Los resultados están disponibles cuando terminan todas las solicitudes o después de 24 horas, lo que ocurra primero. Es un comportamiento habitual, no una garantía.

Consulte processing_status periódicamente hasta que muestre ended. Las solicitudes que devuelven errored, canceled o expired no se facturan. Si depende de un límite de gasto, tenga en cuenta una excepción: "los lotes pueden superar ligeramente el límite de gasto configurado para su Workspace".

Los descuentos se acumulan. Además, como un lote puede tardar más de cinco minutos, la documentación recomienda la caché de una hora para los lotes que comparten contexto. Separe el trabajo: todo lo que una persona o un webhook deba esperar permanece en la ruta activa; un resumen nocturno o la clasificación de los registros del día anterior se envía a un lote por la mitad del precio.

Registrar en un almacén propio los campos de uso de cada respuesta

No puede atribuir un gasto que nunca registró. Cada respuesta indica cuánto costó.

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 a un archivo JSON Lines e identifíquela con el nombre del trabajo. Una semana después podrá saber qué trabajo genera gasto y cuál sólo parece ocupado. Vigile cache_read: una columna llena de ceros es el error de costes más habitual en un agente autohospedado.

Un campo se interpreta mal con facilidad. input_tokens sólo cuenta los tokens posteriores al último punto de 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 informa de input_tokens: 400 con un prompt grande no es barato: el resto procede de la caché.

Cuente antes de enviar. El recuento de tokens es gratuito y sus límites de tasa son independientes de la creación de mensajes, así que use count_tokens para rechazar un archivo adjunto demasiado grande en lugar de pagar para descubrirlo. El resultado es una estimación, por lo que debe volver a medir para cada modelo y nunca reutilizar un recuento obtenido con el tokenizer de otro proveedor. Claude Opus 4.7 y los modelos Opus posteriores, Claude Fable 5 y Claude Sonnet 5 usan un tokenizer más reciente que "produce aproximadamente un 30% más de tokens para el mismo texto". Claude Sonnet 4.6 y anteriores, incluido Claude Haiku 4.5, usan el anterior.

Para obtener la vista autorizada, la Admin API informa del uso en https://api.anthropic.com/v1/organizations/usage_report/messages y del 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[]=. Hay una limitación: "La Admin API no está disponible para cuentas individuales".

Ese último parámetro permite atribuir costes de forma sencilla: asigne a cada trabajo su propia clave de API, filtre con api_key_ids[] y divida el informe por clave con group_by[]=api_key_id. El filtro es plural y la dimensión de agrupación es singular. Mantenga las claves en el entorno y no en el código, como hace una primera aplicación de Claude API en un VPS con ellas.

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

Aquí el número de iteraciones debe estar limitado. El bucle es suyo, así que el contador también:

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 sólo recibe información sobre el presupuesto de la tarea. Un producto alojado detendría el proceso en este punto, del mismo modo que el límite de Claude para las llamadas a herramientas en un solo turno detiene una sesión que ha realizado demasiadas. Sin embargo, un bucle escrito por usted no incluye ningún mecanismo de seguridad hasta que añade uno.

Añada un segundo mecanismo de protección fuera del proceso. Ejecute el trabajo desde un temporizador de systemd en lugar de mantener un proceso permanente, y establezca RuntimeMaxSec= en su unidad de servicio. Con RuntimeMaxSec=600, una ejecución bloqueada se termina después de diez minutos en lugar de seguir ejecutándose hasta que usted lo advierta. Ejecutar un programa como servicio y temporizador de systemd describe los propios archivos de unidad. Consulte qué hizo una ejecución con journalctl -u triage-agent.service --since "1 hour ago".

Limite también los reintentos, porque un controlador que reintenta indefinidamente factura cada intento. Un 429 o un 500 justifica varios intentos con espera incremental. Un 400 no justifica ninguno, porque la misma solicitud fallará de la misma manera.

El control de costes de un agente de IA empieza por leer tus propios datos

Nadie puede decirte cuánto cuesta un agente que está siempre activo, porque el coste es el número de tokens por ejecución multiplicado por las ejecuciones diarias, y ambos valores dependen de ti. Ejecútalo una vez, lee la fila de uso que registraste y multiplícala por tu programación. Dos días después, compara el informe de costes con ese cálculo. Si los dos valores no coinciden, la diferencia casi siempre se debe a una caché defectuosa o a un bucle que se ejecutó durante más tiempo del previsto.

Esto presupone una clave de API, porque el agente es tu propio programa y llama a la Messages API. Para tu trabajo interactivo, qué plan de Claude se adapta a tu forma de trabajar cubre la parte de la suscripción. Todos los precios y límites de esta página se comprobaron con la documentación de Anthropic en julio de 2026, así que vuelve a consultar la página de precios antes de preparar un presupuesto.

FAQ

¿Cuánto cuesta ejecutar un agente de IA permanente en un VPS?

Hay dos facturas y sólo una es predecible. El servidor tiene un precio mensual fijo. La API del modelo se factura por token, por lo que el coste es lo que consume una ejecución multiplicado por la frecuencia con la que se ejecuta. Anthropic no publica ninguna cifra para un agente permanente alojado por el usuario, así que considere cualquier cifra citada como una estimación. Registre usage de una ejecución real y multiplíquelo por la frecuencia programada.

¿Cuál es la diferencia entre max_tokens y el presupuesto de una tarea?

max_tokens se aplica de forma estricta y es invisible para el modelo. Limita la salida de una solicitud, incluido el razonamiento, y alcanzarlo produce stop_reason: "max_tokens". El presupuesto de una tarea es lo contrario: se comunica al modelo y este ajusta el bucle agéntico a ese valor, pero «Los presupuestos de tareas son una sugerencia flexible, no un límite estricto» y el límite aplicado sigue siendo max_tokens.

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

Porque el prefijo cambia entre llamadas o es demasiado corto para almacenarlo en caché. La causa habitual es una marca de tiempo o un identificador de ejecución interpolado en el prompt del sistema: la caché usa el prefijo como clave, por lo que cualquier cambio de un byte invalida todo lo que aparece después. Cambiar las definiciones de herramientas o el valor de effort produce el mismo efecto. De lo contrario, el problema es el tamaño, porque los prompts más cortos no se almacenan en caché y no se devuelve ningún error.

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

Cuente las iteraciones en el código del bucle y deténgalo al alcanzar un máximo fijo, porque max_tokens limita una respuesta y un agente genera muchas. Añada un límite de tiempo real fuera del proceso: inicie el trabajo desde un temporizador de systemd con RuntimeMaxSec= configurado, para que una ejecución bloqueada termine según lo programado. Limite también los reintentos, porque un bucle de reintentos factura cada intento.

¿Puedo establecer un límite de gasto para una sola clave de la API de Claude?

El límite de gasto documentado se aplica al workspace y no a cada clave, así que asigne al agente un workspace propio y limite allí el gasto mensual. «No puede establecer límites en el Default Workspace». Añada notificaciones de gasto para recibir primero una alerta al alcanzar un umbral. Para atribuir el consumo, asigne a cada trabajo su propia clave y agrupe después el informe de uso con group_by[]=api_key_id.