Cobrar por token parece resolver el problema de los precios: el uso sube, el ingreso sube, en sincronía perfecta con el coste. En la práctica esa sincronía se rompe casi de inmediato, porque el coste por token no es un número único. Una pregunta corta y factual y un borrador de documento largo pueden llevar la misma etiqueta de “petición” y un coste completamente distinto, y una página de precios construida alrededor de una única tarifa por token pierde dinero en silencio en el segundo caso, siempre.
¿Cómo deben fijar precio por token los productos de IA de forma rentable?
Una tarifa fija por token ignora que los tokens de entrada, los tokens de salida, el contexto en caché y las llamadas de recuperación tienen costes distintos, y que los usuarios intensivos se concentran de forma desproporcionada en las peticiones de coste más alto. Un precio rentable separa estos drivers de coste, cobra más por los tokens de salida que por los de entrada donde la diferencia es real, y comprueba el margen bruto por escalón de plan frente a los datos reales de uso - no frente a la petición media que asumió el modelo de precios.
Por qué “por token” no es un precio único
Los proveedores de modelos ya cobran de forma distinta los tokens de entrada y de salida, a menudo por un factor de tres a cinco, porque generar un token cuesta más cómputo que leer uno. Los productos que revenden el acceso a una única tarifa combinada heredan esa asimetría sin fijarle precio: un usuario que hace preguntas cortas y recibe respuestas largas cuesta más por petición que la media sobre la que se construyó la tarifa, y un usuario que pega un documento largo y pide una respuesta de una palabra cuesta menos. Sin seguir la división entrada/salida por cliente, el modelo de precios está asumiendo una media que pocos usuarios reales cumplen de verdad.
El contexto y la recuperación forman parte de la factura, no son gastos indirectos
Cada token de contexto enviado al modelo - historial de la conversación, documentos recuperados, instrucciones de sistema - se factura como token de entrada, aunque el usuario nunca lo haya escrito. Una función que mantiene un historial de conversación largo o recupera varios documentos por petición puede gastar más tokens en contexto que en las propias palabras del usuario, y ese coste escala con decisiones de diseño del producto, no con nada que el cliente controle. El caché de contexto repetido lo reduce, pero el caché tiene su propio coste de infraestructura que una tarifa por token rara vez contabiliza por separado.
Los usuarios intensivos no son solo más uso, son un uso distinto
Los precios fijos por usuario o por token asumen que el uso escala de forma uniforme en la base de clientes, y eso nunca ocurre. Una pequeña parte de las cuentas suele generar una parte desproporcionada de los tokens, y esas cuentas suelen ejecutar los tipos de petición más caros: ventanas de contexto largas, cadenas de agentes con varios pasos, tareas con muchos tokens de salida. Un modelo de precios que era rentable en el cliente medio puede estar en pérdidas notables en el decil más intensivo, y ese decil suele ser precisamente el que un producto en crecimiento necesita retener.
Construir un margen bruto que pueda defender
Fijar el precio de un producto de IA con base en la economía unitaria real empieza igual que cualquier ejercicio TDABC: defina la actividad - un turno de chat, un resumen de documento, una tarea de agente - y siga los drivers de coste que una unidad de esa actividad consume realmente, por separado para tokens de entrada, tokens de salida, llamadas de recuperación y cualquier descuento de contexto en caché. Una vez separados, el margen bruto puede probarse por escalón de plan frente a la mezcla de uso que generan los clientes reales, no la mezcla que asumió la lista de precios. Eso es lo que convierte “cobramos por token” en un número que finanzas puede defender.
Una única tarifa por token cobra por la petición media. Su margen lo deciden las peticiones que no son medias.
Qué comprobar antes de la próxima actualización de precios
Antes de ajustar un precio por token o por usuario, confirme que la división entre tokens de entrada y de salida se mide por segmento de cliente, no se asume. Confirme que los costes de contexto y recuperación se asignan a la función que los causa, en lugar de quedar diluidos en una partida de infraestructura compartida. Y confirme que el margen bruto se comprueba tanto frente al decil de mayor uso como frente a la media - un precio que funciona en promedio y falla con sus mejores clientes es un precio que pronto necesitará cambiar otra vez.
Reserve una demostración en directo de CostCtrl y vea cómo los costes de tokens de entrada, tokens de salida, recuperación y revisión se juntan en un único margen real por plan.
Lectura relacionada: margen bruto de IA y cuánto cuesta realmente servir una función de IA.