Cómo poner un límite al gasto de tu API de IA

Una función de IA sin límite de gasto es una función que puede facturarte una cantidad ilimitada. Un bucle de agente descontrolado, un usuario que pega una novela en el chat, un prompt que hace divagar al modelo durante 4.000 tokens — cualquiera de estos multiplica tu factura en silencio. La solución son dos controles baratos y aburridos: acotar cada llamada con max_tokens y llevar el gasto por usuario desde el objeto usage para poder cortar a alguien antes de que cueste más de lo que vale.

Nada de esto es difícil. Lo difícil es confiar en las cifras contra las que pones el límite. Un presupuesto vale tanto como los conteos de tokens que lo alimentan — si tu gateway rellena usage o te cobra por llamadas fallidas, tu techo cuidadosamente calculado de $1/usuario/día es en realidad $1,40 y nunca lo sabrías. Así que esta entrada hace dos cosas: te muestra la mecánica y explica por qué la facturación honesta es lo que hace que esa mecánica funcione siquiera.

Paso 1 — acota cada llamada con max_tokens

El output es la mitad cara de casi todas las facturas. En Claude Sonnet 4.6, el output cuesta $12,75 por 1M de tokens — cinco veces la tarifa de input de $2,55. Una respuesta que esperabas de tres frases y que en cambio vuelve como doce párrafos no es un problema de calidad; es un problema de coste. max_tokens es el techo fijo que hace que el peor caso sea conocido de antemano.

# Limita el coste de cada llamada con max_tokens.
# Acota el *output* — la mitad cara de casi todas las facturas — a un
# techo fijo. El modelo se detiene en el límite en lugar de extenderse.
from openai import OpenAI

client = OpenAI(
    api_key="sk-brievio-...",
    base_url="https://api.brievio.com/v1",
)

# Claude Sonnet 4.6: $2.55 in / $12.75 out por 1M de tokens.
# Sin límite, una respuesta locuaz puede superar los 4.000 tokens de output.
# Con max_tokens=500 acotas el coste de output de ESTA llamada a:
#   500 × $12.75 / 1M = $0.0064 — pase lo que pase con lo que el modelo "quiera" decir.
resp = client.chat.completions.create(
    model="claude-sonnet-4-6",
    max_tokens=500,                 # respetado de forma nativa — un corte real
    messages=[
        {"role": "system", "content": "Answer in at most 3 sentences."},
        {"role": "user", "content": user_question},
    ],
)

# Comprueba siempre por qué se detuvo. "length" significa que llegaste al techo
# y la respuesta puede estar truncada — la señal para subir el límite en ESTA
# clase de tarea, no de forma global.
if resp.choices[0].finish_reason == "length":
    print("Truncado en el límite — considera un max_tokens mayor aquí.")

print(resp.choices[0].message.content)
print(resp.usage)  # conteos honestos de input/output — ver la siguiente sección

Brievio respeta max_tokens de forma nativa contra el modelo genuino — es un corte real, no una sugerencia. Defínelo por clase de tarea, no una vez de forma global: un clasificador necesita quizá 5 tokens, una respuesta de chat 500, un resumen largo 2.000. La disciplina está en elegir un número para cada punto de llamada y vigilar finish_reason. Cuando vuelve como "length", recortaste una respuesta real y deberías subir el límite para esa ruta — no subirlo en todas partes y perder la protección.

Paso 2 — valora tú mismo el objeto usage

Cada respuesta de Brievio incluye un objeto usage con los conteos reales de tokens de input y output de esa llamada, y cada petición queda registrada con sus tokens y su coste reales. Eso significa que no tienes que esperar a una factura de fin de mes para saber lo que costó cualquier cosa — puedes valorar cada llamada en el instante en que vuelve:

• usage.prompt_tokens — tokens de input realmente enviados.
• usage.completion_tokens — tokens de output realmente generados (esto es lo que acota max_tokens).
• usage.total_tokens — la suma, para una comprobación rápida.

Multiplica cada conteo por la tarifa publicada de cada modelo y tienes el coste exacto de la llamada, en tu propio código, en tiempo real. Las tarifas por modelo se publican en la página de precios frente a la referencia oficial, de modo que las constantes de tu código son auditables — no un número que tengas que aceptar a ciegas.

Paso 3 — lleva el gasto por usuario y corta al llegar al presupuesto

Los límites por petición te protegen de una sola llamada mala. Los presupuestos por usuario te protegen de un solo actor malo — esa cuenta que ejecuta miles de llamadas al día, ya sea por entusiasmo, automatización o abuso. El patrón es un único número duradero por usuario que compruebas antes de la llamada e incrementas después:

# Lleva el gasto por usuario desde el objeto usage y corta al llegar al presupuesto.
# usage devuelve los conteos REALES de tokens de input/output de la llamada.
# Los valoras en local contra la tarifa publicada por modelo y los sumas a un
# acumulador asociado a cada usuario.
from decimal import Decimal

# Tarifas publicadas de Brievio, USD por 1M de tokens (≈15% por debajo del precio oficial).
RATES = {
    "claude-sonnet-4-6": {"in": Decimal("2.55"), "out": Decimal("12.75")},
    "claude-haiku-4-5":  {"in": Decimal("0.85"), "out": Decimal("4.25")},
}

def cost_usd(model: str, usage) -> Decimal:
    r = RATES[model]
    million = Decimal("1000000")
    return (usage.prompt_tokens     * r["in"]  / million +
            usage.completion_tokens * r["out"] / million)

# El almacén que prefieras — un contador en Redis, una columna SQL, lo que sea.
# La clave es un único número duradero por usuario. Las llamadas 4xx/5xx fallidas
# son gratuitas en Brievio, así que solo sumas coste por llamadas que de verdad
# devolvieron un resultado.
DAILY_BUDGET = Decimal("1.00")  # $1/usuario/día

def chat_for_user(user_id: str, question: str, model="claude-sonnet-4-6"):
    spent = get_spent_today(user_id)            # Decimal, por defecto 0
    if spent >= DAILY_BUDGET:
        raise BudgetExceeded(f"{user_id} hit ${DAILY_BUDGET}/day")

    resp = client.chat.completions.create(
        model=model,
        max_tokens=500,
        messages=[{"role": "user", "content": question}],
    )

    add_spent_today(user_id, cost_usd(model, resp.usage))  # suma el coste real
    return resp.choices[0].message.content

Elige el umbral a partir de tu economía unitaria: si un asiento de pago cuesta $20/mes y quieres que la IA se mantenga por debajo de, digamos, el 20% de los ingresos, eso es un presupuesto de aproximadamente $0,13/usuario/día. Avisa de forma suave al 80% (un banner, un correo) y corta de forma tajante al 100% (la ruta BudgetExceeded de arriba). Para los usuarios del plan gratuito, pon el límite bajo y baja de gama el modelo — mover tráfico no crítico de Sonnet a Haiku 4.5 a $0,85 in / $4,25 out recorta el coste por token en torno a dos tercios manteniendo la misma medición honesta.

Por qué la facturación honesta hace que las cuentas sean fiables

Aquí está la parte que casi todas las guías de control de costes se saltan. Ambos controles de arriba — el techo por llamada y el presupuesto por usuario — son aritmética sobre conteos de tokens. Si esos conteos están inflados, cada cifra que viene después está mal por el mismo factor, en silencio. Dos comportamientos de facturación deciden si tus límites significan lo que dicen:

• Las llamadas fallidas son gratuitas. En Brievio, una respuesta 4xx o 5xx no cuesta nada — te facturamos por resultados, no por intentos. Eso importa para los presupuestos en concreto: una tormenta de reintentos contra un servicio inestable no debería vaciar el cupo diario de un usuario. Como solo sumas coste por llamadas que devolvieron un resultado, tu curva de gasto sigue el valor entregado, no los errores absorbidos.
• Los conteos no están inflados. El objeto usage refleja los tokens que el modelo genuino procesó de verdad — sin prompt rellenado, sin output fantasma añadido al contador. Lo honesto no es aceptarlo a ciegas: envía un prompt fijo y conocido, lee de vuelta prompt_tokens y confirma que coincide con lo que el tokenizador dice que debería ser. Escribimos una autoprueba de inflación de tokens de 20 líneas que hace exactamente esto — ejecútala contra cualquier gateway, incluido el nuestro, antes de fiarte de sus cifras.

La conexión es directa: un presupuesto calculado a partir de conteos rellenados corta a los usuarios demasiado pronto y sobreestima tu coste; uno que incluye llamadas fallidas castiga a los usuarios por los días malos de tu infraestructura. La medición honesta es lo que permite que un techo de $1/día signifique de verdad un dólar. Brievio cobra el chat en torno a un 15% por debajo del precio oficial, de pago por uso, con un saldo que nunca caduca — así que el límite que pones es el límite que obtienes, y el presupuesto sin usar sigue siendo tuyo.

Poniéndolo todo junto

Una postura de gasto lista para producción son cuatro pequeños hábitos, ninguno de los cuales lleva más de una tarde:

• Cada punto de llamada define max_tokens dimensionado a su tarea. Sin outputs ilimitados, en ningún sitio.
• Cada respuesta se valora desde usage a la tarifa publicada y se suma a un acumulador por usuario.
• Cada usuario tiene un presupuesto con un aviso suave y un corte tajante derivados de tu economía unitaria.
• El tráfico más barato baja de gama a un modelo más pequeño (Haiku, clase mini) en lugar de pagar tarifas de buque insignia por trabajo que no las necesita.

Haz esas cuatro cosas y tu factura en el peor caso es un número que elegiste, no un número que descubres. Para las palancas más profundas — caché de prompts, procesamiento por lotes, selección de modelo, recorte de prompts — consulta el manual de optimización de costes, y la documentación para el esquema completo de usage y los parámetros compatibles con OpenAI que admite Brievio. El control de costes no es una función que añades después de que la factura te asuste — son dos líneas y un contador, y funciona mejor sobre un medidor en el que puedes confiar.