Las matemáticas ocultas del pricing LLM
Por qué tu factura es 3× más salada de lo que crees

Aquí va una cifra que debería preocuparte: el precio anunciado en las páginas de pricing de las APIs LLM casi nunca es lo que pagas realmente por output útil.

Claude Sonnet 4.6 está listado a 3 $ por millón de tokens de entrada. El mes pasado instrumentamos una app RAG de tamaño medio y medimos el coste efectivo: 8,40 $ por millón de tokens de input realmente visibles para el usuario. Es decir, 2,8× el precio anunciado. Y era una app bien escrita por un equipo que pensaba que sabía lo que hacía.

Si construyes con LLMs y no has lanzado este cálculo sobre tu propio stack, tu factura es casi seguro más grande de lo que crees. Aquí tienes exactamente dónde se fuga el dinero.

La mentira del precio anunciado

Cuando un proveedor te dice "3 $ por millón de tokens de entrada", la cifra es exacta para la llamada API en bruto. El problema es que "tokens consumidos" y "tokens que han producido valor de usuario" son dos números totalmente distintos.

Seis multiplicadores se componen en silencio entre los dos:

1. La repetición del system prompt
2. La acumulación del context en conversación multi-turn
3. Los reasoning tokens invisibles
4. El prompt caching que falla
5. Los retry loops sobre errores transitorios
6. La explosión del tool use

Cada uno parece pequeño aislado. Apilados, obtienes 2-5× tu factura "prevista". Vamos a descomponerlos.

1. La tasa system prompt

Cada llamada que haces reenvía tu system prompt cada vez. Si tu system prompt mide 2 000 tokens (realista, una persona carefully-engineered más las instrucciones más algunos ejemplos few-shot), y el mensaje de usuario mide 50 tokens, el 97,5 % de tu input es el system prompt.

El usuario ha enviado 50 tokens. Te facturan 2 050.

Una app de chat con un system prompt de 2K tokens y un turno de usuario medio de 100 tokens gasta el 95 % de su budget input en el system prompt. En cada turno. Para siempre.

El prompt caching resuelve esto, pero solo si lo usas correctamente (ver sección 4).

2. El acumulador de conversación

El chat multi-turn es un problema de interés compuesto. Turno 1 cuesta X. Turno 2 cuesta X + (turno 1). Turno 3 cuesta X + (turno 1) + (turno 2). En el turno 10 de una conversación modesta, pagas diez veces por los mismos tokens del principio.

Cifras reales de uno de nuestros chatbots:

El turno 30 cuesta 45× lo que costó el turno 1. Mismo usuario. Mismo tipo de pregunta. Los primeros turnos de la conversación se pagan 30 veces cuando llegas al turno 30.

La mayoría de equipos no ponen tope a la longitud de las conversaciones, porque la penalización UX es visible y la penalización de coste es invisible hasta la factura mensual.

3. Los reasoning tokens invisibles

Este nos hizo más daño.

El extended thinking de Claude y los modelos razonadores estilo o1 de OpenAI producen tokens que nunca ves pero que siempre pagas. Es el borrador interno del modelo, su "reflexión" antes de escribir la respuesta.

Para un prompt complejo con extended thinking activado, los reasoning tokens pueden ser 3-5× los tokens de output visibles. Haces una pregunta de 200 tokens, el modelo produce 400 tokens de respuesta, y acabas de pagar por 2 000 tokens de razonamiento que nunca has leído.

# Lo que muestra tu dashboard
input_tokens = 200
output_tokens = 400
# "Coste: 0,018 $"

# Lo que has pagado realmente
input_tokens = 200
reasoning_tokens = 1 800   # invisibles
output_tokens = 400
# "Coste real: 0,045 $"

Los reasoning tokens se facturan al precio output (15 $/M para Opus). Se componen con todo lo demás de esta lista. Si activas el extended thinking sin medir el delta, tu factura se duplica en silencio.

4. El prompt caching que no cachea

El prompt caching es la mayor palanca de coste que la mayoría de equipos no usa correctamente. Las lecturas de cache en Anthropic están al 10 % del precio input normal. Un descuento del 90 %, ignorado.

¿Por qué? Tres razones que vemos constantemente:

• Cache miss por drift. Cambia un carácter en el system prompt, un bump de versión, un timestamp, un campo user-specific inyectado al principio, y el cache se invalida. Los equipos no se dan cuenta de que su tasa de cache hit está al 20 % en lugar del 95 % que suponían.
• TTL demasiado corto. El cache expira a los 5 minutos. Un chatbot de uso esporádico nunca toca un hit.
• Cache breakpoints mal colocados. Puedes colocar los cache markers manualmente, pero la mayoría de equipos no lo hace, así que el SDK elige defaults no óptimos para su workload.

Un fix simple, colocar los campos user-specific al final del prompt en lugar del principio, puede llevarte del 20 % al 90 % de cache hit. Es 4-5× de reducción de coste por sí solo, sin reescritura de código más allá del orden de las secciones.

5. La tasa retry

Las APIs LLM fallan. Rate limits, 529, timeouts, content filter. La mayoría de SDKs hacen retry automático con backoff exponencial.

Cada retry se factura.

Una llamada que tiene éxito en el 3.er intento te cuesta 3× lo que cuesta una llamada limpia. La mayoría de equipos no trackean la tasa de retry por endpoint. En un caso que diagnosticamos, los "outages ocasionales de Anthropic" de un equipo eran en realidad el 8 % de sus llamadas haciendo retry dos veces, un sobrecoste silencioso del 16 % que nunca veían en los logs, solo en la factura.

6. La explosión tool use

El function calling, "tool use" en Claude, es donde los costes se vuelven realmente raros. Cada llamada de tool es un round-trip: el modelo genera una request de tool, tú la ejecutas, devuelves el resultado como nuevo mensaje, el modelo lo lee y genera el siguiente paso.

Cada round-trip reenvía toda la conversación. Un agente que hace 5 llamadas de tools para responder a una pregunta paga por su contexto completo 5 veces, más los resultados de los tools.

Pregunta del usuario (200 tok)
  → LLM piensa + pide tool A (400 tok output, 200 tok input)
  → Resultado tool A añadido (300 tok)
  → LLM relee todo + pide tool B (700 tok input, 200 tok output)
  → Resultado tool B añadido (500 tok)
  → LLM relee todo + escribe la respuesta (1 400 tok input, 300 tok output)

Lo que el usuario ve: una pregunta, una respuesta. Lo que has pagado: 2 300 tokens en input + 900 tokens en output sobre una pregunta que medía 200 tokens originalmente.

El cálculo real

Apliquemos los seis multiplicadores a un escenario realista: un chatbot de soporte cliente, Claude Sonnet 4.6, 10 000 conversaciones al día.

Cálculo naïve:

• Conversación media: 4 turnos, 500 tokens cada uno → 2 000 tokens input, 400 output
• Coste diario: 10 000 × (2 000 × 3 $/M + 400 × 15 $/M) = 120 $/día

Coste real con todos los multiplicadores:

• System prompt: 1 500 tokens × 4 turnos = 6 000 tokens repetidos
• Acumulación conversación: +40 % de tokens input en el turno 4
• Tasa de cache hit: 30 % (no optimizado) → precio efectivo 2,40 $/M en la parte cacheada, 3 $/M en el resto
• Tasa de retry: 5 % de las llamadas hacen retry una vez
• Tool use (2 tools de media por conversación): +60 % de tokens input

Coste diario revisado: 312 $/día. Es decir, 2,6× la estimación naïve.

Delta mensual: 5 760 $ más de lo presupuestado. Para un equipo que pensaba que controlaba el tema.

Cómo medir esto de verdad

No puedes arreglar lo que no mides. Tres instrumentaciones que defendería para cualquier app LLM-heavy:

1. Coste efectivo por conversación, no por token. Divide tu gasto total por el número de conversaciones de usuario terminadas. Esa es tu cifra real.

2. Tasa de cache hit, desglosada por endpoint. Si está por debajo del 80 % en un endpoint de mucho tráfico, tienes una fuga de coste de 3-5× fácil de arreglar con un reordenamiento de prompt.

3. Tasa de retry por código de error. 529 y 429 son problemas distintos, y a menudo indican que estás en el tier equivocado, no que el proveedor sea inestable.

Si no trackeas esas cifras, tu factura la deciden patrones que no ves.

El ángulo routing

Una vez que puedes ver el coste real por conversación, la siguiente pregunta es: ¿el modelo que he usado era realmente necesario?

Aquí es donde el smart routing paga. La mayoría de conversaciones, saludos, preguntas factuales cortas, lookups simples, no necesitan el modelo top-tier. Un router que envíe esas a Haiku mientras mantiene el razonamiento complejo en Sonnet/Opus puede dividir entre 2-3 la factura efectiva sin que el usuario lo note.

Las matemáticas ocultas no son inevitables. Solo están ocultas.

Próximo en la serie: por qué aportar tus propias claves API (BYOK) es el remedio más limpio al problema de opacidad del pricing.