Coste de tokens en funciones de IA: gestiónalo antes de perder margen

El coste de tokens es la factura variable de inferencia que tu producto paga cada vez que un usuario activa una función de IA, y es la partida que convierte en silencio un margen de software del 80% en uno del 50%. Una función SaaS clásica se construye una vez y se sirve para siempre: el coste marginal del usuario diez mil es casi cero. Una función de IA es lo contrario. Cada llamada vuelve a ejecutar el modelo, consume cómputo y ata un coste real a esa transacción concreta. Si la presupuestas como si fuera software, el margen se vacía sin que una sola línea de la cuenta de resultados parezca mal.

No es un error de redondeo. El SaaS tradicional se asentó entre el 80% y el 90% de margen bruto en la última década. La foto de ICONIQ de enero de 2026 sitúa el margen bruto medio de los productos de IA en el 52%, arriba desde el 41% de 2024 pero aún lejos del techo del software. Bessemer, en su State of AI, coloca a las empresas LLM-native cerca del 65%. Martin Casado, de a16z, describe el viejo margen de software del 70-80% como una gravedad de mercado que la IA rompe, porque la inferencia es un coste variable que crece con cada uso, no un coste fijo que amortizas sobre una base que se ensancha.

Por qué las funciones de IA se comportan como infraestructura, no como software

El modelo mental que falla es tratar una llamada de IA como una lectura de base de datos. Una lectura de base de datos al margen es prácticamente gratis. Una llamada al modelo es de consumo, como la electricidad. En 2026 el contador marca más o menos así: Claude Sonnet 4.6 cuesta 3 dólares por millón de tokens de entrada y 15 por millón de salida, Opus 4.8 cuesta 5 y 25, Haiku 4.5 cuesta 1 y 5. GPT-5.5 de OpenAI está en 5 dólares de entrada y 30 de salida. Son cifras de céntimos por llamada, invisibles en una demo, que luego se suman hasta convertirse en tu mayor coste de ventas cuando llegan usuarios de verdad. La unidad que importa no es el precio por token. Es cuántos tokens consume una acción útil, multiplicado por cuántas veces la repiten tus usuarios más intensos.

Por qué subir el precio no lo arregla

El reflejo es cobrar más. No funciona, porque el coste no se reparte de forma uniforme. Los patrones de uso de 2026 muestran al 10% de usuarios más activos consumiendo cerca del 90% de la inferencia. Un plan plano de 29 dólares es rentable con un usuario ocasional y muy deficitario con un usuario intensivo que tiene la función encendida todo el día. Cuando GitHub Copilot movió todos sus planes a créditos por consumo a mediados de 2026, algunos usuarios intensivos vieron su factura saltar de 29 dólares hacia 750. Cursor recortó su cupo de solicitudes al mismo precio. Los desarrolladores llamaron al cambio tokenpocalypse. Un precio plano más alto sigue perdiendo dinero con el décimo más pesado y deja fuera al 90% que apenas toca la función. No puedes poner tarifa plana a un coste que se comporta como un suministro.

Cómo presupuestar una función de IA antes de lanzarla

El trabajo se hace antes del lanzamiento, no tras la primera factura sorpresa. Cuatro movimientos aportan casi todo el resultado.

Mide el coste por acción, no por usuario

Elige la unidad de valor más pequeña que entrega tu función: un hilo resumido, un borrador generado, una pregunta respondida. Cuenta los tokens que consume de verdad de principio a fin, incluidos el prompt de sistema, el contexto recuperado, el historial de conversación y la salida. Multiplica por las tarifas de entrada y salida del modelo. Ya tienes un coste por acción defendible. Una sola respuesta fundamentada con 10.000 tokens de contexto y 700 de réplica en Sonnet 4.6 cuesta unos 4 céntimos. Es esa cifra, no una estimación mensual vaga, la que usas para diseñar precio y límites.

Envía cada tarea al modelo más barato que supere el listón

La diferencia de precio entre un modelo de frontera y uno pequeño es de 5x o más. La mayor parte del tráfico en producción no necesita el modelo de frontera. Clasificación, extracción, reescrituras breves y decisiones de enrutado corren bien en modelos clase Haiku a una quinta parte del coste. Reserva el modelo caro para el razonamiento realmente difícil. Enviar todo al modelo top es la forma más común en que los equipos pagan de más, y el enrutado entre modelos suele ser la mayor palanca que tienen.

Cachea las partes que se repiten

Casi todas las llamadas de IA reenvían el mismo prompt de sistema y el mismo contexto recuperado en cada turno. El prompt caching evita pagar a precio completo esa repetición: Anthropic descuenta la entrada en caché hasta un 90%, y OpenAI la cachea de forma automática con un 50% de descuento. El semantic caching va más allá, sirviendo preguntas casi idénticas desde un almacén en vez del modelo, y los sistemas en producción desvían habitualmente entre el 20% y el 45% del tráfico así. El procesamiento por lotes, para todo lo que no necesita ser en tiempo real, es otro 50% menos. Apilados, caching y enrutado recortan de forma habitual una factura de inferencia entre el 47% y el 80%.

Pon un techo al peor caso

Cada función de IA necesita un límite. Fija un presupuesto de tokens o solicitudes por usuario, degrada con elegancia cuando se alcanza (un modelo más pequeño, un contexto más corto, una cola) y haz del techo una decisión de producto, no un accidente descubierto en la factura. La regla que sostenemos: no lances nunca una función de IA a un precio por debajo del coste de su peor usuario, salvo que hayas elegido a propósito subvencionar ese nivel y sepas exactamente cuánto tiempo te lo puedes permitir.

Cómo poner precio alrededor de un coste variable

Una vez que conoces el coste por acción, el precio se sigue. La tarifa plana solo aguanta cuando el peor usuario sigue cabiendo dentro del precio, algo raro en cualquier cosa de consumo intenso. El precio por consumo alinea ingreso y coste pero añade fricción e imprevisibilidad para quien compra. La resolución común en 2026 es híbrida: una suscripción base que cubre un cupo generoso de acciones, y luego créditos por consumo por encima. Así el usuario ocasional se queda en un plan simple, el intensivo paga la carga que genera y el margen queda protegido en ambos extremos. Elijas el modelo que elijas, la capa de facturación tiene que medir el consumo con precisión: es una decisión de desarrollo que conviene tomar pronto, no injertar después bajo presión.

Cómo se ve en la práctica

Toma un asistente de soporte dentro de una herramienta B2B. Cada respuesta lleva un prompt de sistema de 4.000 tokens, 6.000 tokens de conocimiento recuperado y una réplica de 700 tokens. En Sonnet 4.6 son unos 4 céntimos por respuesta. Un usuario intensivo que hace 30 preguntas al día durante 20 días laborables genera 600 respuestas, unos 24 dólares de inferencia en un mes. En un plan de 29 dólares, esa sola función consume el 83% del ingreso antes de cualquier otro coste. Un usuario ocasional con 20 preguntas en todo el mes cuesta 80 céntimos. La misma función, una diferencia de 30 veces.

Ahora aplica el presupuesto. Cachea el prefijo estático de 9.500 tokens con el descuento del 90% y solo la entrada nueva y la salida pagan tarifa completa: el coste por respuesta baja a unos 1,4 céntimos. La inferencia mensual del usuario intensivo cae de 24 dólares a unos 8,40, un recorte del 65% sin cambiar nada de lo que ve el usuario. Envía las preguntas más simples a un modelo clase Haiku y baja aún más. La función que parecía de margen negativo en un plan plano ahora cabe dentro con holgura, y la misma disciplina te dijo exactamente dónde poner el techo de consumo. De eso se trata: el coste de tokens no es una razón para evitar funciones de IA. Es una cifra alrededor de la cual diseñar, y los equipos que la miden antes de lanzar conservan el margen que los que lo dejan al azar pierden.