El coste de inferencia IA se ha convertido en la métrica más engañosa del sector, y Paul Graham ha lanzado la advertencia: cobrar por token distorsiona el unit economics de cualquier startup que construya sobre modelos.
La advertencia de Graham: el token ya no mide el valor que entrega el modelo
Vamos a los números, aunque aquí el número es justamente el problema. Paul Graham, cofundador de Y Combinator, sostiene —en declaraciones recogidas por Yahoo Finance— que el coste por token ha dejado de medir el valor: los modelos actuales resuelven más trabajo en cada token que los de generaciones anteriores. La misma cifra que hace un par de años describía un coste, hoy describe otra cosa.
La segunda capa del razonamiento es la que interesa a quien factura. Si una única llamada al modelo resuelve lo que antes exigía cuatro, tu coste por tarea se desploma, pero tu precio por token no se mueve. Sigues cobrando por la unidad vieja. Sigues midiendo un mundo que ya no existe.
Ahí nace la distorsión. Un negocio que ancla su precio a un insumo —el token— y no al resultado que entrega —la tarea resuelta— pierde visibilidad sobre su propio margen: no sabe qué cliente le deja dinero, ni qué funcionalidad le cuesta cara, ni si crecer le acerca a la rentabilidad o le aleja de ella.
El unit economics que sí funciona en una startup de IA
La unidad correcta no es el token, es la tarea: un ticket resuelto, un contrato revisado, un informe generado, una llamada clasificada. Define esa unidad, calcula su coste marginal real —inferencia, orquestación y minutos de revisión humana— y fija el precio sobre el valor que tiene para el cliente. Es la misma disciplina que separa un negocio de márgenes sanos de otro que crece directamente hacia la quiebra.
Un precio que sigue al coste de un insumo no describe tu negocio: describe la factura de tu proveedor.
Ojo, porque el coste de inferencia sigue siendo una palanca de ingeniería, y ahí se gana o se pierde el margen bruto. Enrutar las peticiones simples a modelos pequeños, cachear respuestas repetidas, reducir el número de llamadas por tarea y reservar los modelos grandes para el trabajo que de verdad los necesita. Cuatro decisiones técnicas que mueven el margen más que cualquier ajuste de tarifa.
El founder que no sabe cuánto le cuesta resolver una tarea no tiene un negocio de IA: tiene un producto brillante y una factura creciente.
Y la cosa se complica con el uso agéntico. Una tarea que encadena diez llamadas puede consumir más tokens que veinte consultas sencillas, de modo que el coste por token tampoco sirve como atajo de presupuesto: en unos flujos sobrevalora el trabajo y en otros lo infravalora. La métrica no falla por poco; falla en las dos direcciones.
Traducido a tareas concretas, la revisión se hace en una tarde:
- Lista tus unidades de valor: escribe las tres tareas que tu producto resuelve y cuántas veces al mes las ejecuta un cliente medio.
- Calcula el coste marginal por unidad: suma inferencia, orquestación, almacenamiento y minutos humanos. Sin ese número, tu MRR es una cifra decorativa.
- Compara precio y valor: pregunta al cliente cuánto le ahorra cada tarea resuelta y contrástalo con lo que le cobras.
- Revisa la arquitectura antes que la tarifa: si el margen no cierra, el problema suele estar en el enrutado de modelos, no en el precio.
📦 Caso de estudio: Y Combinator y la doctrina del margen por unidad
- El reto: Startups de IA que celebran el crecimiento de ingresos sin saber si cada usuario les deja dinero o les cuesta dinero.
- La jugada: Graham aplica el ejercicio que popularizó con su tesis del default alive: comprobar si la empresa sobrevive con sus propios ingresos antes de salir a levantar capital.
- El resultado: Los equipos que hacen ese cálculo antes de la ronda corrigen arquitectura o precio cuando todavía es barato hacerlo, no cuando el burn rate aprieta.
- La lección: Si no puedes explicar cuánto te cuesta resolver una tarea, no tienes pricing: tienes una intuición.
La analogía que lo aclara: cómo fijan precios los negocios tangibles
Un paralelismo ayuda más que cualquier hoja de cálculo. Nadie que dirija una fábrica de chocolate artesanal fija el precio de una tableta contando solo el kilo de cacao: pesa la receta, el tiempo de templado, la merma, el envasado, el local y lo que el cliente está dispuesto a pagar por esa tableta concreta. El cacao es un insumo, no el producto. Con la inferencia ocurre exactamente lo mismo.
Pasa algo parecido en un negocio de eventos que ha rehabilitado un edificio histórico: la luz y el alquiler del espacio son entradas del cálculo, pero el precio de una boda se fija por la experiencia completa, la fecha y la demanda de esa temporada. Los negocios tangibles llevan décadas conviviendo con insumos volátiles y rara vez confunden el coste del insumo con el precio del servicio. El software de IA ha tardado menos de tres años en cometer ese error.
Lo que este caso enseña a un ecosistema hipnotizado por la IA
El sector ya ha vivido este guion. Cuando el software pasó de la licencia a la suscripción, muchas compañías tardaron años en entender que servir a un cliente no cuesta lo mismo con diez usuarios que con diez mil; las que lo entendieron antes fijaron precio por valor y aguantaron mejor los ciclos malos. Hoy el equivalente es el coste por token: una métrica de laboratorio que se ha colado en el consejo de administración.
Mi lectura, con el dato delante: el precio por token es una forma cómoda de no decidir, porque deja que sea el proveedor del modelo quien determine la estructura de ingresos de tu empresa. Y esa falta de criterio se detecta rápido en una due diligence: un inversor pregunta por margen bruto, por coste de servir al cliente y por runway, no por la tarifa de la API. En España, donde buena parte del capital semilla pasa por business angels y por programas tipo Lanzadera o Wayra, esa conversación llega antes de lo que muchos founders esperan.
La lección para quien levanta ahora mismo es concreta: si tu pitch explica el crecimiento de usuarios y no explica cuánto cuesta atender a cada uno, la conversación se rompe en la primera ronda de preguntas. La mayoría de los founders que levanta capital en IA mira el margen por unidad con la misma lupa con la que el inversor de SaaS clásico miraba el CAC y el payback. Prepáralo tú antes de que lo haga él.
🚀 Hoja de Ruta para Emprender
- Define tu unidad de valor: elige la tarea que resuelves y mide todo contra ella; el token es un insumo, no una unidad de negocio.
- Calcula el coste marginal por tarea: inferencia, orquestación y minutos humanos. Sin ese número, tu precio es una apuesta.
- Optimiza antes de subir precios: enrutado de modelos, caché y menos llamadas por tarea mueven más margen que un aumento de tarifa.
- Llévalo a tus OKR: pon el margen por unidad como métrica trimestral y explícala en cada revisión con inversores.
