Cost Monitoring para agentes

Idea en 30 segundos

El cost monitoring para agentes de IA muestra no solo el gasto total, sino tambien donde crece: en tokens LLM, APIs externas y pasos repetidos del agente.

Sin esto, es facil perder el momento en que el sistema todavia "funciona", pero ya es demasiado caro para production.

Problema principal

Un run puede terminar con exito, pero costar 2-3 veces mas de lo normal.

Dos solicitudes con la misma respuesta final pueden tener costo unitario distinto por pasos extra de reasoning, retries o llamadas innecesarias a tools. Sin cost monitoring, esto suele verse solo despues de exceder presupuesto.

Ahora veamos como leer estas senales y encontrar que vuelve caro a un run.

En production esto suele verse asi:

• los tokens suben en olas despues de una release;
• una tool empieza a consumir gran parte del presupuesto sin notarse;
• retries aumentan el gasto incluso sin crecer el trafico;
• el equipo ve el problema solo despues de explosion de presupuesto.

Por eso la cost-layer conviene monitorearla por separado, no solo con metricas generales de run.

Como funciona

El cost monitoring se construye alrededor de dos tipos de senales:

• usage signals (prompt_tokens, completion_tokens, tool_calls, retries);
• cost signals (llm_cost_usd, tool_cost_usd, total_cost_per_run).

Estas metricas responden "donde y por que el sistema se encarece con el tiempo". Logs y tracing se necesitan para explicar un run caro concreto.

Los costos no suben solo por volumen de trafico, sino tambien por comportamiento del agente. Usage != cost. Un agente puede resolver la misma tarea con el mismo resultado, pero costar mucho mas por retries, cadenas de reasoning mas largas o tools caras.

Metricas de costo tipicas en production

budget_burn_rate normalmente se calcula en dashboard (gasto por unidad de tiempo), no como counter separado en runtime.

Para que las metricas sean practicas, normalmente se segmentan por release, model, tool y tipo de solicitud.

Importante: no agregues campos de alta cardinalidad (run_id, request_id, user_id) en labels, o el storage de metricas se sobrecarga rapido.

Como leer la cost-layer

Que se consume -> como se comporta el agente -> cuanto cuesta de verdad. Son tres niveles que siempre hay que ver juntos.

Es clave mirar tendencias en el tiempo y diferencias entre releases, no valores aislados.

Ahora mira combinaciones de senales:

• token_usage_per_run ↑ + llm_cost_per_run ↑ -> el agente gasta mas tokens por run;
• tool_cost_per_run ↑ + total_cost_per_run ↑ -> over-tooling o ruta de tools cara;
• llm_cost_per_run ↑ + tool_cost_per_run ~= estable -> problema en prompt o reasoning, no en tools;
• budget_burn_rate ↑ + run_count ~= estable -> regresion de costo unitario;
• cost_p95 ↑ + budget_burn_rate ↑ -> runs anomalamente caros aceleran el gasto.

Cuando usar

Cost monitoring completo no siempre es necesario.

Para un prototipo simple, puede bastar con token_usage base y un limite diario de gasto.

Pero monitoreo detallado de costos se vuelve critico cuando:

• el sistema ya esta en production con restricciones de presupuesto;
• el agente usa varias tools con APIs pagas;
• hay releases frecuentes y hay que ver regresiones de costo;
• hay que escalar trafico sin perder control de presupuesto.

Ejemplo de implementacion

Abajo hay un ejemplo simplificado de instrumentacion de cost metrics estilo Prometheus. Muestra control base de costo LLM, costo de tools y precio total por run.

import time
from prometheus_client import Counter, Histogram

RUN_TOTAL = Counter(
    "agent_run_total",
    "Total number of agent runs",
    ["status", "stop_reason", "release"],
)

LLM_COST_USD_TOTAL = Counter(
    "agent_llm_cost_usd_total",
    "Total LLM cost in USD",
    ["model", "release"],
)

TOOL_COST_USD_TOTAL = Counter(
    "agent_tool_cost_usd_total",
    "Total tool/API cost in USD",
    ["tool", "release"],
)

TOKEN_USAGE_TOTAL = Counter(
    "agent_token_usage_total",
    "Total LLM tokens",
    ["model", "token_type", "release"],
)

RUN_COST_USD = Histogram(
    "agent_run_cost_usd",
    "Cost per run in USD",
    ["release"],
    buckets=(0.001, 0.003, 0.01, 0.03, 0.1, 0.3, 1, 3),
)

BUDGET_BREACH_TOTAL = Counter(
    "agent_budget_breach_total",
    "Total runs that crossed cost budget",
    ["release"],
)

LLM_PRICING = {
    # WARNING: ejemplo de tarifa (puede estar desactualizada).
    # En production, estos valores deben venir de config o API del proveedor.
    "gpt-4.1": {
        "prompt": 0.0000015,
        "completion": 0.0000020,
    }
}


def estimate_llm_cost_usd(model, prompt_tokens, completion_tokens):
    # WARNING: replace with actual provider pricing
    pricing = LLM_PRICING.get(model)
    if not pricing:
        # WARNING: unknown model — cost will be reported as 0 (underestimated)
        return 0.0
    prompt_cost = prompt_tokens * pricing.get("prompt", 0)
    completion_cost = completion_tokens * pricing.get("completion", 0)
    return prompt_cost + completion_cost


def run_agent(agent, task, budget_limit_usd=0.25, release="2026-03-21"):
    run_status = "ok"
    stop_reason = "max_steps"
    run_cost_usd = 0.0

    try:
        for step in agent.iter(task):
            step_type = step.type
            try:
                result = step.execute()
            except Exception as error:
                run_status = "error"

                if step_type == "tool_call":
                    stop_reason = "tool_error"
                elif step_type == "llm_generate":
                    stop_reason = "llm_error"
                else:
                    stop_reason = "step_error"

                raise

            if step_type == "llm_generate":
                model = getattr(step, "model", "unknown")
                usage = getattr(result, "token_usage", {}) or {}
                prompt_tokens = usage.get("prompt_tokens", 0)
                completion_tokens = usage.get("completion_tokens", 0)

                TOKEN_USAGE_TOTAL.labels(model=model, token_type="prompt", release=release).inc(
                    prompt_tokens
                )
                TOKEN_USAGE_TOTAL.labels(
                    model=model, token_type="completion", release=release
                ).inc(completion_tokens)

                llm_cost = estimate_llm_cost_usd(model, prompt_tokens, completion_tokens)
                run_cost_usd += llm_cost
                LLM_COST_USD_TOTAL.labels(model=model, release=release).inc(llm_cost)

            if step_type == "tool_call":
                tool_name = getattr(step, "tool_name", "unknown")
                tool_cost = float(getattr(result, "cost_usd", 0.0) or 0.0)
                run_cost_usd += tool_cost
                TOOL_COST_USD_TOTAL.labels(tool=tool_name, release=release).inc(tool_cost)

            if result and result.is_final:
                stop_reason = "completed"
                break
    finally:
        RUN_COST_USD.labels(release=release).observe(run_cost_usd)
        if run_cost_usd > budget_limit_usd:
            BUDGET_BREACH_TOTAL.labels(release=release).inc()
        RUN_TOTAL.labels(status=run_status, stop_reason=stop_reason, release=release).inc()

# cost_per_1k_runs normalmente se calcula en dashboard:
# (sum(agent_run_cost_usd) / run_count) * 1000
# budget_burn_rate normalmente se calcula en dashboard:
# gasto por unidad de tiempo (por ejemplo USD/hour), no como counter separado en codigo.

Asi pueden verse estas metricas juntas en un dashboard real:

Investigation

Cuando dispara una alerta de costo:

1. encontrar el segmento con anomalia (model, tool, release);
2. revisar runs caros en tracing;
3. revisar en logs retries, stop_reason y tool-path;
4. encontrar root cause (prompt, logica del agente, API cara, routing incorrecto).

Errores tipicos

Incluso cuando ya hay cost metrics, muchas veces no ayudan por errores tipicos.

Solo hay una suma diaria total de costos

La suma diaria no muestra que run o segmento se encarecio. Sin cost_per_run y cost_p95, el problema suele detectarse tarde.

Solo se cuentan tokens y se ignora costo de tools

En muchos sistemas de agentes, lo caro son llamadas API externas. Sin tool_cost_per_run, es facil perder la fase temprana de explosion de presupuesto.

No hay desglose por release y model

Sin segmentacion, es dificil demostrar que una release o modelo nuevo empeoro costo unitario.

Labels de alta cardinalidad

Agregar run_id, request_id o session_id en labels sobrecarga rapido el backend de metricas. Es mejor dejar esos datos en logs y tracing.

No hay alertas para burn rate y cost_p95

Sin alertas, los problemas se acumulan en silencio hasta golpear el presupuesto. Esto suele aparecer junto con uso excesivo de tokens.

Autoevaluacion

Abajo tienes un checklist corto de cost monitoring base antes de release.

FAQ

P: En que se diferencia cost monitoring de monitoreo de tokens?
R: Tokens son solo parte del gasto. Cost monitoring incluye tokens LLM, llamadas tool/API pagas y costo unitario total por run.

P: Cual es el minimo de metricas de costo para empezar?
R: Empieza con token_usage_per_run, total_cost_per_run, cost_p95 y budget_burn_rate.

P: Como calcular cost_per_run con varios proveedores?
R: Normaliza todos los costos de pasos a una sola moneda (normalmente USD) y suma costos LLM + tools dentro de un run.

P: Como separar crecimiento de trafico de regresion de costo unitario?
R: Mira run_count y cost_per_run juntos. Si el trafico esta estable y cost_per_run sube, hay regresion de costo unitario.

Paginas relacionadas

Siguiente sobre el tema:

• Metricas de agentes — modelo general de metricas para sistemas de agentes.
• Metricas de uso de herramientas — control de costos y fiabilidad a nivel tools.
• Tracing de agente — como encontrar pasos caros dentro de un run.
• Logging de agentes — eventos para analizar incidentes de costo.
• Monitoreo de latencia de agentes — relacion entre latency y costo.