Clawy / Guías / Poner precio a una API de IA de pago
Si revendes o envuelves GPT o Claude a un precio fijo por llamada, un solo prompt grande puede costarte más de lo que cobras. Aquí están las cuentas y dos formas de arreglarlo.
Envolviste un LLM, lo pusiste detrás de un endpoint y cobras un precio fijo y limpio — digamos $0,15 por llamada. Claro para tus clientes, fácil de razonar. El problema: el modelo de abajo no factura por llamada. Factura por token, y los tokens escalan con el tamaño del prompt y de la respuesta. En una petición pequeña te embolsas un buen margen. En una grande puedes pagar más de lo que cobraste — y no lo notarás hasta que llegue la factura del proveedor.
Los modelos facturados por token cobran por separado el input (el prompt que envías) y el output (lo que genera el modelo). Según las tarifas oficiales de Claude:
| Modelo | Input / 1M tokens | Output / 1M tokens |
|---|---|---|
| Claude Haiku 4.5 | $1.00 | $5.00 |
| Claude Sonnet 4.6 | $3.00 | $15.00 |
| Claude Opus 4.8 | $5.00 | $25.00 |
Tu coste por una llamada es simplemente:
cost = (input_tokens × input_price + output_tokens × output_price) / 1,000,000
Toma Opus 4.8 a un precio fijo de $0,15/llamada. Solo el output cuesta $25 por millón de tokens — así que apenas 6.000 tokens de output cuestan $0,15, comiéndose todo tu precio antes de contar un solo token de input. Deja que un cliente envíe un documento de 100.000 tokens como contexto y pida una respuesta larga, y esa única llamada puede costarte varias veces lo que cobraste. Multiplícalo por unos pocos usuarios intensivos y el producto "rentable" opera con pérdidas.
El número que importa es el prompt más grande que puedes servir antes de que una llamada cueste más de lo que cobras. Con el tamaño de output fijo, el tamaño de input de equilibrio es:
break_even_input_tokens = (price × 1,000,000 − output_tokens × output_price) / input_price
Para Opus a $0,15 con una respuesta de 800 tokens: (0.15 × 1,000,000 − 800 × 25) / 5 = 26,000 tokens de input. Pasados ~26k tokens de prompt, cada llamada pierde dinero. Si tu tráfico real lo supera con regularidad, la tarifa plana es el modelo equivocado — o tu precio es demasiado bajo.
Si quieres mantener la tarifa plana (a los clientes les encanta su previsibilidad), acota ambos lados para que la llamada en el peor caso no supere tu precio:
max_tokens). Un valor por defecto generoso aún acota el lado caro. A $25/1M, cada 1.000 tokens de output son $0,025.worst-case cost < price con margen de sobra para reintentos, fallbacks y fallos de caché de prompts (presupuesta ~25–40% de holgura).Así es exactamente como un endpoint de precio fijo se mantiene solvente: el precio es fijo, pero el trabajo detrás está acotado para que nunca opere bajo el agua.
La alternativa es dejar de fingir que las llamadas son uniformes y facturar por lo que realmente consumen: medir tokens (a menudo con un múltiplo de margen sobre tu coste) o cobrar precios escalonados por tamaño de petición. Renuncias a la simplicidad de un número redondo, pero nunca pierdes dinero en una petición grande porque el precio se mueve con el coste. Por uso es lo correcto cuando los tamaños de prompt varían mucho o sirves cargas de contexto grande.
Sea cual sea el modelo que elijas, la disciplina es la misma: conoce tu coste por llamada, conoce tu punto de equilibrio y acota el peor caso antes de que llegue a un cliente que paga.
→ ¿Quieres saltarte la facturación por completo? Las APIs con cobro por llamada sobre el protocolo x402 cobran en USDC por petición — sin claves API, sin suscripciones. Mira el inicio rápido de 5 minutos con un cliente para copiar y pegar. → Consigue el Kit de precios de API de IA (19 €). Todo esto, listo para usar: un modelo de coste/margen en Excel, una calculadora offline, códigomargin-guard listo que limita prompts demasiado grandes antes de que te cuesten, y un inicio rápido.