Los tokens son la unidad equivocada
Alegato por un pricing por conversación

Imagina que entras en un restaurante y la carta lista los precios al gramo de comida. No por plato. No por ración. Por gramo.

No sabes cuánto pesa un filete. No sabes cuánto añade la salsa. El camarero no puede decirte cuánto costará la cena hasta que hayas comido, cuando pesa tus restos y hace la resta.

Así es el pricing LLM. Los tokens son los gramos. Tú eres el cliente. Y la factura siempre es una sorpresa.

El problema de unidad

Cada proveedor LLM importante factura por token: 3 $ por millón de tokens input, 15 $ por millón de tokens output, recargos variables sobre los reasoning tokens. Así funciona la API, así que así funciona el pricing.

El problema es que a nadie que builde una app le importan los tokens. Lo que les interesa:

• ¿Cuánto cuesta una conversación?
• ¿Cuánto cuesta un usuario al mes?
• ¿Cuánto cuesta hacer correr mi producto por transacción?

Convertir el pricing por token en estas respuestas pide unas matemáticas que dependen de:

• La forma exacta de tus prompts (apps distintas = shapes per-token radicalmente distintas)
• Tu cache hit rate (que varía cada semana según los cambios de prompt)
• Tu tasa de retry (que varía según la salud del proveedor)
• Tus patrones de tool use (que inflan los token counts de forma no lineal)
• Tu uso de extended thinking (tokens de razonamiento invisibles que pagas igualmente)

Ninguno de estos elementos es predecible al darte de alta. Los descubres a lo largo de meses de tráfico en prod. Cuando puedes contestar a "¿cuánto cuesta una conversación?", ya has pagado por la respuesta.

Por qué los tokens persisten como unidad

La razón honesta: es práctico para el proveedor.

Los tokens son cómo el modelo procesa el texto. Los tokens son lo que las GPU facturan en compute. Desde el punto de vista de Anthropic o de OpenAI, facturar por token es la abstracción natural. Te repasan su unidad de entrada en bruto.

Pero las unidades de entrada en bruto rara vez son la unidad de pricing correcta para un cliente. Los proveedores de electricidad no facturan por número de electrones. Los proveedores cloud facturan por instancia-hora, no por ciclo de CPU. Stripe factura por transacción, no por byte de request API. En cada caso, la industria ha madurado hacia una unidad que se corresponde con el valor para el cliente, no con las operaciones internas del proveedor.

El pricing LLM está atascado en la fase "número de electrones". Va a madurar. La pregunta es si los clientes esperan o empujan.

Cómo sería un pricing por conversación

Imagina en cambio: "0,04 $ por conversación completada, para tráfico típico de soporte cliente".

De golpe:

• Puedes presupuestar. 10 000 conversaciones × 0,04 $ = 400 $. Listo.
• Puedes comparar proveedores en unidades apples-to-apples.
• Puedes construir el pricing de tu propio producto encima (factura a tu cliente por conversación, con el margen que quieras).
• Puedes detectar anomalías. Si una conversación cuesta de repente 0,40 $, algo va mal con esa conversación, y lo ves inmediatamente.

"Ah," dirás, "pero las conversaciones varían salvajemente, un chat de tres turnos cuesta diferente que un chat de 30 turnos". Exacto. Por eso haces tiering. El playbook SaaS para esto tiene treinta años:

• Conversación simple (0,02 $): <4 turnos, <5K tokens total
• Estándar (0,05 $): <10 turnos, <20K tokens
• Compleja (0,15 $): <30 turnos, <80K tokens
• Enterprise (0,50 $): más allá

Stripe no te factura por byte. Stripe clasifica las transacciones por tipo y tarifica en consecuencia. Está resuelto.

Las objeciones

Cuando hablo de esto con founders técnicos, vuelven tres objeciones:

"Las conversaciones tienen costes salvajemente distintos." Sí, y por eso tienes tiers. Stripe factura una tasa distinta en tarjetas internacionales vs domésticas. AWS factura una tasa distinta en instancias compute-optimized vs general-purpose. La variabilidad es la feature, no un bug.

"El pricing por token es más transparente." Esa está al revés. El pricing por token es transparente para el proveedor, no para ti. Puedes ver exactamente cuántos tokens ha procesado el proveedor, pero no puedes traducir eso fácilmente a "cuánto ha costado esta sesión de usuario". El pricing por conversación es opaco a nivel token pero transparente al nivel que de verdad te interesa.

"Mi app es un edge case raro y no encajaría en los tiers." Quizá. Entonces negocia un tier custom. Cada vendor de infra tiene deals enterprise para workloads inusuales. Es normal.

Dónde está pasando ya

Algunos proveedores avanzan hacia este modelo. Replicate factura por generación para los modelos image. Perplexity tiene pricing API tiered para las requests de búsqueda. Algunos productos recientes de asistencia código (Cursor, Aider) tarifan efectivamente por sesión, bundleando el compute por debajo.

El patrón siempre es: la API commodity factura a la unidad bruta, la capa de encima factura a la unidad significativa para el cliente. Por eso existe la capa infra.

El ángulo BYOK

Por eso también BYOK + infra a fee fijo es un match tan bueno. El proveedor sigue facturándote por token (porque es su modelo). Pero tu middleware puede abstraer eso a un fee por conversación o por seat que de verdad tiene sentido para tu producto.

Tu capa infra carga con la predicción. Dice: "la mayoría de tus conversaciones encaja en el tier B, que facturaremos a 0,05 $ cada una. Nosotros nos comemos la varianza; tú tienes la predictibilidad". Es un servicio de verdad. Es lo que te compra una suscripción a fee fijo.

Los proveedores nunca lo ofrecerán ellos mismos porque predecir un coste variable por conversación contra su propio revenue variable por token es un hedge que no pueden tomar. Solo una capa por encima puede.

El futuro

Apuesto a que en tres años, las APIs LLM serias ofrecerán pricing por conversación o por sesión como opción principal, con el per-token como fallback para los usuarios batch/pipeline. Las capas infra lo ofrecerán cada vez más por defecto. El modelo de facturación gramos-de-comida parecerá tan primitivo en 2030 como la larga distancia al minuto parece en 2026.

Mientras tanto, la unidad que te interesa, conversaciones, usuarios, sesiones, tiene que reconstituirse a partir de la unidad por la que te facturan. Esa reconstitución es un trabajo a tiempo completo, y es el trabajo que una capa de infra BYOK hace por ti.

Los tokens son la unidad del proveedor. Las conversaciones son la tuya. Mientras el pricing no converja a la unidad del cliente, necesitas una capa que haga la conversión.

---

Para leer también: Las matemáticas ocultas del pricing LLM muestra por qué la conversión coste-por-token a coste-por-conversación es más dura de lo que parece.