Cuando se habla del costo de n8n, mucha gente compara solo el precio de la suscripción; un mes después de salir a producción descubre que la factura procede sobre todo de las llamadas al modelo. n8n se encarga de la orquestación del flujo, pero quien procesa el contenido suele ser la API del modelo que va detrás: la primera se factura por plan o por servidor y la segunda por tokens o por volumen de peticiones, dos estructuras de costo completamente distintas.

Este artículo divide el costo relacionado con n8n en cuatro bloques calculables y propone pasos de estimación y medidas de control. Las cifras concretas cambian con el plan, el modelo y el tipo de cambio; aquí no se fijan importes, así que toma como referencia la página de precios de n8n y la página de precios de modelos de este sitio.

Nota: n8n es una marca de su titular. Este artículo no guarda relación de afiliación con n8n y se limita a un análisis técnico y de costos.

1. De qué se compone el costo

Conviene empezar con un mapa de costos para no mirar únicamente la cuota del software.

Concepto Base de facturación Lo que suele olvidarse
Suscripción a n8n Cloud Por plan y número de ejecuciones mensuales Tamaño del equipo, ejecuciones extra, cambio de plan
API de modelos Por tokens de entrada y de salida Reintentos, contexto repetido, salidas largas
Infraestructura autoalojada Servidor, base de datos, copias, ancho de banda Personal de operación, monitoreo, actualizaciones y seguridad
Operación de los flujos Depuración, repetición de fallos, almacenamiento de registros Ejecuciones repetidas de flujos sin supervisión

De los cuatro bloques, la suscripción a Cloud es el más visible, la API de modelos el más impredecible, la infraestructura autoalojada el más subestimado y la operación de flujos el que casi nunca aparece en el presupuesto. A la hora de calcular el total hay que sumarlos todos.

2. Cloud y autoalojamiento: no cuentes solo el software

El valor de n8n Cloud está en ahorrarse el despliegue, las actualizaciones, las copias de seguridad y el mantenimiento de la disponibilidad. Los planes suelen escalonarse por número de ejecuciones y, al superarlo, hay que subir de plan o comprar capacidad adicional. Encaja en equipos pequeños sin personal dedicado a operación que quieren salir rápido.

La edición Community autoalojada puede desplegarse por cuenta propia y no cobra suscripción por asiento, pero «gratis» se refiere solo a la licencia del software. Servidor, PostgreSQL, Redis en modo cola, almacenamiento de objetos, copias de seguridad, monitoreo, registros, parches de seguridad y ventanas de actualización son costos reales. n8n usa la Sustainable Use License (modelo fair-code), que impone restricciones adicionales a la redistribución y a la prestación de servicios alojados a terceros; antes de un uso comercial hay que leer la licencia original. Si el equipo no tiene capacidad de operación, el costo total del autoalojamiento suele superar lo previsto.

Una regla sencilla: si el valor mensual del tiempo dedicado a mantener la instancia supera la diferencia de precio con el plan Cloud, elige Cloud; si los datos deben quedarse en la red propia, el volumen de flujos es alto y el equipo tiene capacidad de operación, entonces considera el autoalojamiento.

3. Número de ejecuciones: la variable más subestimada

Los planes de n8n suelen girar en torno al «número de ejecuciones». Una ejecución de flujo cuenta normalmente como una ejecución, pero el consumo real se multiplica por estos factores:

  • Disparadores por sondeo: una comprobación periódica sin datos nuevos también puede generar un registro de ejecución; consulta las reglas de tu versión.
  • Bucles y subflujos: procesar datos en lote uno por uno o dividir la lógica en subflujos aumenta el número de ejecuciones.
  • Reintentos por fallo: los reintentos de nodo y la repetición de flujos suelen volver a contar como ejecución.
  • Ejecuciones de depuración: ejecutar a mano varias veces en el editor también consume cuota.

La forma de reducir ejecuciones es directa: usa Webhook en lugar de sondeo cuando sea posible; agrupa en lote en vez de disparar por registro; deduplica en la entrada; define intervalos razonables para las tareas programadas; y depura primero con una sola muestra.

En un nodo Code de n8n puedes resumir el consumo de cada llamada para verificarlo después:

// Resume el consumo de tokens de una ejecución (los nombres de campo dependen de la respuesta real)
const usage = $json.usage ?? {};
const input = usage.prompt_tokens ?? 0;
const output = usage.completion_tokens ?? 0;

return [{ json: {
  input_tokens: input,
  output_tokens: output,
  total_tokens: input + output
  // El precio unitario se rige por la página de precios; aquí solo se registra el consumo
}}];

4. Pago por uso de API: dónde se gastan los tokens

La factura de la API de modelos depende de la entrada y de la salida. La entrada no es solo la frase del usuario: también incluye el prompt de sistema, el historial de conversación, los documentos recuperados, las definiciones de herramientas y las instrucciones de formato. La salida se factura según la longitud generada. Tres factores habituales que multiplican el consumo:

  1. Contexto repetido: cada turno de una conversación arrastra el historial y el costo de entrada se acumula en los diálogos largos.
  2. Documentos largos insertados enteros: meter un contrato completo o una página web entera en el prompt encarece cada llamada y, si se repite, mucho más.
  3. Reintentos y múltiples versiones: reenviar una petición fallida o pedir a varios modelos que respondan lo mismo multiplica el consumo.

El orden de optimización suele ser: primero escalona los modelos (modelos económicos para clasificar, limpiar y resumir; modelos potentes para la generación compleja); después comprime el contexto y envía solo los campos necesarios; luego limita la longitud de salida y pide respuestas estructuradas y breves; por último, considera el caché. Algunos proveedores ofrecen caché de prompts que reduce el costo de entrada de prefijos repetidos; la disponibilidad y el descuento dependen de la documentación de cada proveedor.

5. Reintentos, caché y costos ocultos

Los reintentos son necesarios en automatización, pero tienen dos consecuencias en la factura: aumentan las ejecuciones y pueden volver a facturar la misma petición al modelo. Si una petición fallida se cobra o no depende del proveedor upstream, así que no des por hecho que es gratuita. Se recomienda limitar los reintentos a 2 o 3, usar retroceso exponencial y aplicar idempotencia en las operaciones de escritura para no duplicar mensajes ni asientos.

El caché debe analizarse en dos capas. La capa del flujo guarda «resultados»: si un registro ya se procesó, se omite. La capa del modelo guarda «prefijos»: el prompt de sistema fijo y los documentos largos. La primera se implementa con base de datos o Redis; la segunda depende de las capacidades del proveedor del modelo. No son intercambiables.

Hay otros puntos que suelen pasarse por alto: el historial de ejecuciones y los registros de flujo ocupan espacio en la base de datos; las llamadas de imagen, audio y transcripción tienen facturación propia; y ejecutar todo el conjunto de datos durante la depuración puede generar de golpe una gran cantidad de ejecuciones y tokens.

6. Control del presupuesto: límites, alertas y revisión

Define los límites de antemano:

  • Asigna una clave de API independiente por proyecto o flujo, para poder atribuir el gasto y desactivarla.
  • Configura un presupuesto mensual o un límite de consumo en la pasarela y activa alertas al acercarse al umbral.
  • Guarda el campo usage de cada llamada en una hoja de cálculo o base de datos y agrégalo por flujo.
  • Fija límites de concurrencia y reintentos específicos para los flujos de alto consumo.
  • Revisa cada mes los tres flujos que más consumen y comprueba si hay llamadas repetidas.
  • Reserva un margen para el crecimiento del negocio y los ajustes de precio.

Usar una pasarela compatible con OpenAI unificada permite concentrar en un solo lugar las claves, el consumo y los límites de varios proveedores de modelos, y cambiar de modelo sin tocar los flujos. Si quieres probar, puedes registrarte; los modelos y precios concretos están en precios de modelos.

7. Un método de estimación reutilizable

No presupuestes a ojo; sigue este orden:

  1. Elige un flujo representativo y toma entre 20 y 50 muestras reales, no datos de prueba inventados.
  2. Cuenta los disparos mensuales, incluidos los programados, los Webhook, los sondeos sin datos y las ejecuciones manuales.
  3. Registra los tokens de entrada y salida de cada llamada a partir de la respuesta y calcula la media.
  4. Multiplica por un coeficiente de reintentos, por ejemplo un 20 % a 50 % adicional según la tasa de fallos histórica.
  5. Suma el costo mensual de la suscripción Cloud o del servidor, la base de datos, las copias y el almacenamiento de registros.
  6. Añade la conversión a costo del tiempo de mantenimiento de la instancia y de diagnóstico de fallos.
  7. Revisa cada trimestre: las reglas de los planes, los precios de los modelos y los procesos de negocio pueden cambiar.

Por ejemplo, si un flujo se dispara diez mil veces al mes, un treinta por ciento de esas ejecuciones llama al modelo y cada llamada consume en promedio dos mil tokens de entrada y quinientos de salida, primero multiplica tres mil por dos mil quinientos para obtener unos siete millones y medio de tokens mensuales y después conviértelo al precio vigente del modelo elegido. Consulta el precio en precios de modelos y no reutilices cifras de artículos antiguos.

Preguntas frecuentes

¿Cómo se calculan las ejecuciones de n8n Cloud?

Normalmente cada ejecución de un flujo cuenta como una ejecución; que los sondeos, los reintentos y las ejecuciones manuales cuenten depende de las reglas del plan vigente. Lo más prudente es observar durante una semana la página de consumo de la cuenta y compararla con la frecuencia real de tus disparadores.

¿n8n autoalojado es realmente gratis?

La edición Community no cobra suscripción por asiento, pero el servidor, la base de datos, las copias de seguridad, el monitoreo y el personal de operación corren por tu cuenta. Las funciones empresariales requieren una licencia aparte y, antes de un uso comercial, conviene revisar las restricciones de la Sustainable Use License.

¿Por qué la factura del modelo supera tanto la estimación?

Las causas habituales son el contexto repetido, los bucles que llaman al modelo registro por registro, los reintentos fallidos y las ejecuciones sobre todos los datos durante la depuración. Revisa primero la proporción entre entrada y salida en el detalle de consumo y después comprueba si algún flujo está procesando el mismo registro varias veces.

¿Los reintentos fallidos también se facturan?

El número de ejecuciones suele aumentar; que la petición al modelo se cobre o no depende de las reglas del proveedor upstream. Se recomienda limitar los reintentos, registrar el resultado de cada petición y aplicar idempotencia en las operaciones de escritura.

¿Cómo se fija un límite de presupuesto para el equipo?

Divide las claves de API por proyecto, configura cuotas mensuales y alertas en la pasarela y conecta los registros de consumo al informe interno. Ante una anomalía, desactiva primero la clave correspondiente y después localiza el flujo concreto.

Siguiente paso

La optimización de costos de n8n se reduce a dos cosas: reducir las ejecuciones innecesarias y controlar los tokens de cada llamada al modelo. Cuantifica primero ambos factores y después decide entre Cloud y autoalojamiento. Si necesitas gestionar claves de modelos, consumo y presupuesto en un solo lugar, puedes empezar por registrarte en ZSQH AI Gateway; los precios se rigen por la página de precios de modelos.

Lecturas relacionadas: