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 respuesta. Claude nunca lo supera y el modelo no puede ver su valor. Al alcanzarlo, devuelve stop_reason: "max_tokens" y una respuesta truncada. Para los agentes, el detalle importante es que cada solicitud de un ciclo de uso de herramientas tiene su propio max_tokens. Por tanto, limita una respuesta y no la tarea completa. Diez llamadas a herramientas con un límite de 4,000 establecen un máximo de 40,000 tokens para el turno.

El presupuesto de una 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 tareas son una indicación flexible, no un límite estricto." Claude puede superar uno durante una acción, mientras que 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 de task_budget.total es de 20,000 tokens; un valor inferior devuelve un error 400. Un presupuesto demasiado pequeño para el trabajo provoca un comportamiento similar a una negativa, por lo que el modelo reduce el alcance de la tarea o se detiene antes de completarla.

Un detalle genera un coste en lugar de ahorrarlo. 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 tareas están en beta en Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5.5 y Claude Haiku 5.5. Claude Sonnet 5 y Claude Haiku 4.5 aparecen como Not supported, y los presupuestos de tareas 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 configura en Claude Console: asigne al agente su propio espacio de trabajo y establezca un límite de gasto mensual y límites de tasa por minuto para ese espacio. "No puede establecer límites en el espacio de trabajo Default", y "los límites de 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 con el esfuerzo

La elección del modelo se hace para cada trabajo. En octubre de 2026, por millón de tokens, primero la entrada y después la salida: Claude Fable 5.1 y Fable 5 cuestan $10 y $50, Claude Opus 5.5 cuesta $4 y $20, Claude Opus 5, Opus 4.8 y Opus 4.7 cuestan $5 y $25, Claude Sonnet 5.5 y Sonnet 5 cuestan $2 y $10, Claude Haiku 5.5 cuesta $0.10 y $0.50 para prompts de hasta 100,000 tokens ($0.50 y $2.50 por encima de ese límite; los tokens en caché se incluyen en el recuento), y Claude Haiku 4.5 cuesta $1 y $5. Anthropic vendió inicialmente Sonnet 5 a ese precio como tarifa introductoria. Después lo convirtió en el precio estándar y canceló la subida prevista a $3 y $15. Un paso que sólo clasifica líneas de log no necesita Opus.

Tampoco debe contar con el uso gratuito para cubrir un calendario intenso. Aparte de el pequeño crédito que Claude API concede al registrarse, la única asignación recurrente es el crédito mensual de API incluido en los planes Claude Max y Team: $100 en Max 5x, $200 en Max 20x y hasta $500 compartidos en Team, que se renueva en cada ciclo de facturación. Puede solicitarlo después de 7 días en un plan elegible y no se necesita ningún método de pago. Cubre Claude API, Managed Agents, Agent SDK y el playground, pero no Claude Code. Caduca al final de cada ciclo y no se acumula. Su consumo cuenta para el límite de gasto. Cuando se agota, las solicitudes se detienen, salvo que la organización también tenga créditos comprados.

El esfuerzo es la segunda palanca. output_config.effort acepta low, medium, high, xhigh y max, aunque no todos los modelos admiten todos los niveles. El valor predeterminado es high en la mayoría de los modelos y medium en Claude Opus 5.5 y Claude Haiku 5.5. Establecer explícitamente el valor predeterminado de un modelo equivale a omitirlo. Reducir el esfuerzo no sólo acorta el razonamiento: la documentación indica que hace que Claude realice menos llamadas a herramientas y combine varias operaciones en menos llamadas. En un agente, ese es el ahorro más importante, porque evitar una llamada a una herramienta evita una solicitud completa.

El problema es que el esfuerzo entra en conflicto con la caché. Cambiar el valor de nivel superior entre solicitudes invalida la caché de prompts. En el ejemplo documentado con Claude Opus 5.5, la solicitud 2 informó cache_read_input_tokens: 3546. La solicitud 3 cambió el esfuerzo de medium, el valor predeterminado de ese modelo, a low, e informó cache_creation_input_tokens de 3546 y cache_read_input_tokens de 0. Por tanto, varíe el esfuerzo de nivel superior entre cargas de trabajo, nunca dentro de una conversación almacenada en caché. Hay dos formas de cambiar la profundidad sin romper la caché. En Claude Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 y Haiku 5.5, un cambio de esfuerzo por mensaje (beta, encabezado mid-conversation-output-config-2026-07-01) establece un nivel nuevo y mantiene intacto el prefijo almacenado en caché. En cualquier modelo también puede indicarlo en el prompt: una línea como "Answer directly without deliberating." en el mensaje de usuario más reciente mantiene intactos los puntos de interrupción anteriores. Sin embargo, en Claude Haiku 5.5 esa frase no reduce el razonamiento de forma fiable.

Los tokens de razonamiento se facturan con las tarifas de salida y cuentan para max_tokens. Por eso, 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 el contador.

Almacene en caché el prefijo estable y no lo rompa 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. En la mayoría de los modelos, una lectura de caché cuesta 0.1 veces, por lo que «la caché resulta rentable después de una lectura en caché para la duración de 5 minutos (escritura a 1.25x), o después de dos lecturas en caché para la duración de 1 hora (escritura a 2x)». En los modelos más recientes, las lecturas son aún más baratas: 0.05 veces en Claude Opus 5.5 y Claude Sonnet 5.5, y 0.025 veces en Claude Fable 5.1.

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 usa el contenido almacenado en caché». 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 siguiente orden: tools, system y después messages». Cualquier cambio de un 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 autoinfligido es incluir una marca de tiempo o un identificador de ejecución en el mensaje del sistema: cada petición lleva entonces un prefijo diferente, escribe una entrada nueva a 1.25x y no obtiene ninguna lectura. La señal es usage.cache_read_input_tokens en 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 petición se procesa sin caché y «no se devuelve ningún error». Las cifras incluyen 512 tokens en Claude Fable 5.1, Fable 5, Opus 5.5, Opus 5, Sonnet 5.5 y Haiku 5.5; 1,024 en Claude Opus 4.8 y Claude Sonnet 5; y 4,096 en Claude Haiku 4.5. Por tanto, mover un trabajo de Sonnet 5 a Haiku 4.5 puede desactivar la caché silenciosamente.

Una conversación que supera la ventana de búsqueda retrospectiva. «La ventana de búsqueda retrospectiva es de 20 bloques». El sistema comprueba como máximo 20 posiciones en cada punto de interrupción y después se detiene. En el ejemplo documentado, un turno que contiene 35 bloques y tiene un punto de interrupción 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, por tanto, no hay coincidencia. Una aplicación de agente que añade varios bloques de uso de herramientas y de resultados de herramientas en cada turno supera 20 bloques en dos o tres turnos. Tiene cuatro puntos de interrupción por petición, 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 su propio almacenamiento 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 en 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. Supervise cache_read: una columna llena de ceros es el error de costes más frecuente en un agente autohospedado.

Un campo se puede interpretar mal fácilmente. input_tokens cuenta sólo los tokens posteriores al último punto de almacenamiento en 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 input_tokens: 400 con un prompt grande no es barato: el resto procedía de la caché.

Cuente antes de enviar. El recuento de tokens es gratuito y sus límites de frecuencia son independientes de la creación de mensajes, por lo que debe usar 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 medirlo para cada modelo y no reutilice un recuento de otro tokenizador de otro proveedor. Los modelos Claude 4.7 y posteriores, incluidos Claude Fable 5 y Claude Sonnet 5, usan un tokenizador 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. El informe de uso acepta bucket_width=1d, group_by[]=model y api_key_ids[]=. El informe de costes sólo es diario y agrupa por workspace_id o description. Una limitación: «La Admin API no está disponible para cuentas individuales».

Ese parámetro api_key_ids[] es un método sencillo para atribuir costes: asigne a cada trabajo su propia clave de API, filtre el informe de uso con api_key_ids[] y divídalo 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 en lugar de incluirlas en el código, como hace una primera aplicación de Claude API en un VPS al gestionarlas.

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 al modelo sólo se le informa de un presupuesto de tareas. Un producto alojado detendría la ejecución en este punto, igual que el límite de Claude para las llamadas a herramientas en un solo turno detiene una sesión que ha realizado demasiadas, pero un bucle escrito por usted no incluye ese mecanismo de protección hasta que añade uno.

Añada un segundo mecanismo de control fuera del proceso. Ejecute el trabajo mediante un temporizador de systemd en lugar de usar un proceso permanente, y establezca un límite de tiempo real para su unidad de servicio. Un trabajo de temporizador suele ser Type=oneshot, y RuntimeMaxSec= «no tiene ningún efecto en los servicios Type=oneshot», así que establezca TimeoutStartSec=600 allí. Use RuntimeMaxSec=600 sólo en una unidad Type=simple. De cualquier forma, una ejecución bloqueada finalizará después de diez minutos en lugar de seguir ejecutándose hasta que 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 retroceso. Un 400 no justifica ninguno, porque la misma solicitud volverá a fallar de la misma forma.

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

Nadie puede decirte cuánto cuesta un agente que se ejecuta de forma permanente, porque el coste es el número de tokens por ejecución multiplicado por el número de ejecuciones diarias, y ambas cifras dependen de ti. Ejecútalo una vez, lee la fila de uso que registraste y multiplícala por la frecuencia programada. Comprueba el informe de costes dos días después y compáralo con ese cálculo. Si 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 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 indicados aquí se comprobaron con la documentación de Anthropic en octubre de 2026, así que vuelve a leer la página de precios antes de preparar un presupuesto.

FAQ

¿Cuánto cuesta ejecutar un agente de IA activo permanentemente 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 según los tokens, 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 activo permanentemente y alojado por el usuario, así que debe tratar cualquier cifra citada como 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 el presupuesto de una tarea?

max_tokens se aplica de forma obligatoria y no es visible para el modelo. Limita la salida de una solicitud, incluido el razonamiento, y alcanzarlo produce stop_reason: "max_tokens". Un presupuesto de tarea funciona al 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 es 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 bytes invalida todo lo que aparece después. Cambiar las definiciones de herramientas o el valor de nivel superior effort produce el mismo efecto. De lo contrario, el problema es el tamaño, ya que los prompts más 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 el código del bucle y deténgalo en un máximo fijo, porque max_tokens limita una respuesta y un agente genera muchas. Añada un límite de tiempo de reloj externo al proceso: inicie el trabajo desde un temporizador de systemd y establezca TimeoutStartSec= en una unidad oneshot, o RuntimeMaxSec= en una unidad simple, para que una ejecución bloqueada termine según lo previsto. Limite también los reintentos, ya que 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 espacio de trabajo y no a cada clave, por lo que debe asignar al agente un espacio de trabajo propio y limitar allí su gasto mensual. «No puede establecer límites en el espacio de trabajo predeterminado». Añada notificaciones de gasto para recibir primero una alerta cuando se alcance 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.