2. Control de costos: dónde se fuga el dinero

Descripción

Al terminar esta lección vas a poder explicar qué es un token sin recurrir a la palabra "token", vas a saber por qué el texto que el modelo escribe se cobra más caro que el texto que recibe, y vas a poder calcular el costo de una ejecución concreta y proyectarlo a un mes con el volumen real de tu instancia. Sobre todo, vas a salir con cost_log funcionando: un registro que escribe una fila por cada ejecución con IA, construido con un nodo Code que solo lee datos que ya vienen en el item.

Esto importa porque es el cimiento de todo lo demás. Las seis lecciones que siguen te van a pedir decisiones —¿subo o bajo Max Iterations?, ¿este modelo o aquel?, ¿local o API?, ¿expongo esto por MCP?— y ninguna de esas decisiones se puede tomar con opiniones. Se toman con números. Terra Market no puede responder por qué se triplicó su factura porque nunca midió, y ese es el problema real: no que el gasto haya subido, sino que subió sin que nadie pudiera verlo. Un sistema que gasta mucho pero se mide es un sistema que administras; uno que gasta poco pero no se mide es una sorpresa esperando su turno.

Conexión con el módulo: la lección 1 planteó el problema y te dio el caso. Esta lección construye el instrumento. Todo lo que viene después lo usa: la lección 3 mide el efecto de Max Iterations con estos números, la 4 compara modelos con estos números, la 5 calcula el punto de equilibrio con estos números, y el proyecto de la 8 le pone un tope y una alerta a este mismo registro. Una frontera importante: aquí construyes el registro de costo, pero la capa de observabilidad donde vive —logging estructurado, almacén de métricas, alertas— es el módulo 4 de esta guía. Si ya montaste esa capa, cost_log es una métrica más que se enchufa ahí. Si no, esta lección te da la versión mínima que funciona sola.

Qué se está cobrando, exactamente

Empecemos por el escalón de abajo, porque casi todo el mundo lo salta y después no entiende su factura.

Cuando tu workflow le habla a un modelo de lenguaje, no le manda "un mensaje". Le manda una pila de texto, y el modelo devuelve otra pila de texto. Lo que se cobra es la cantidad de texto que viaja en cada dirección, medida en una unidad que se llama token.

Un token es un pedacito de texto. No es una letra ni exactamente una palabra: es un fragmento del tamaño que el modelo usa internamente para trocear el idioma. Una palabra corta y común suele ser un token; una palabra larga o poco frecuente se parte en dos o tres; los espacios y signos también cuentan. Como regla mental para estimar en español, una palabra promedio ronda entre uno y dos tokens, y un párrafo de cien palabras anda por los 150 tokens. No lo tomes como fórmula exacta —cada proveedor trocea distinto y los números cambian entre modelos—; tómalo como la escala.

Piénsalo como la cuenta de un taller que cobra por pieza. No le pagas al taller "por arreglar el auto": le pagas por cada tornillo, cada tuerca y cada minuto. Si le mandas el auto con un manual de 300 páginas adjunto "por si acaso", el taller lo lee, y te cobra por leerlo. Da igual que no hiciera falta.

Ahora la parte importante, y es la que cambia cómo diseñas: el precio no es el mismo en las dos direcciones.

Por qué la salida cuesta más. Vale la pena entenderlo, porque explica varias decisiones de diseño que vas a tomar. Procesar la entrada es leer: el modelo puede mirar todo el texto de una vez, en paralelo. Producir la salida es escribir, y escribir es secuencial: cada pedacito de la respuesta se genera después del anterior, y para generarlo el modelo tiene que volver a considerar todo lo que hay hasta ahí. Un texto de entrada de mil tokens se procesa de una pasada; un texto de salida de mil tokens se produce en mil pasos. El precio refleja ese trabajo.

Piénsalo así: leer un contrato de veinte páginas te toma media hora. Escribir un contrato de veinte páginas te toma dos días. Es la misma cantidad de papel y no es el mismo trabajo.

De ahí sale un principio de diseño que vale para todo lo que hagas en producción:

Reducir la salida rinde más que reducir la entrada. Si tienes que elegir dónde recortar, empieza por lo que el modelo escribe, no por lo que lee.

Eso tiene una consecuencia inmediata para Terra Market. ticket-classify devuelve una categoría —tres o cuatro palabras—, así que su costo está dominado por la entrada. reply-draft devuelve un borrador de respuesta completo —doscientas o trescientas palabras—, así que su costo está dominado por la salida. Son dos problemas de optimización distintos y no se atacan igual. En ticket-classify vas a mirar el prompt y el historial; en reply-draft vas a mirar cuánto texto le pides que escriba.

La fórmula, y de dónde sacar los precios

El cálculo es aritmética simple. Lo único que cambia entre proveedores son los dos precios:

costo_de_una_llamada =
      (tokens_de_entrada  / 1.000.000) × precio_entrada_por_millón
    + (tokens_de_salida   / 1.000.000) × precio_salida_por_millón

Los precios se publican por millón de tokens, y por eso la división. Es una unidad grande a propósito: una llamada individual cuesta una fracción minúscula, y solo cuando multiplicas por miles de ejecuciones el número se vuelve legible.

No vas a encontrar en esta guía una tabla con esos dos precios. Es deliberado. Los precios de las APIs de IA cambian —bajan casi siempre, pero cambian—, hay descuentos por lotes, hay caché de prompt que abarata partes repetidas, y hay diferencias entre el proveedor directo y las nubes que lo revenden. Una tabla de precios impresa en un curso es una trampa: alguien la va a usar para presupuestar dentro de un año y va a presupuestar mal. Lo que sí te sirve para siempre es saber dónde buscarlos:

Cuando armes tu registro de costos, el precio va como una constante configurable, no incrustado en el código. Cuando el proveedor lo cambie —o cuando cambies de modelo— quieres tocar un solo lugar. En n8n eso significa una variable de entorno, un nodo Edit Fields al principio del workflow, o una fila en una tabla de datos. Cualquiera de los tres sirve; lo que no sirve es tenerlo escrito en cuatro nodos distintos.

Ejemplo trabajado: cuánto cuesta un ticket de Terra Market

Vamos a hacer el cálculo completo con la estructura correcta y con precios simbólicos, para que veas la mecánica. Sustituye P_IN y P_OUT por los precios vigentes del proveedor que uses el día que hagas esto.

Terra Market mide una ejecución típica de ticket-classify y encuentra esto:

Una ejecución de ticket-classify (caso típico, 1 sola llamada al modelo)

  Entrada
    system prompt (instrucciones de clasificación)   ≈  320 tokens
    descripciones de las 2 herramientas conectadas   ≈  180 tokens
    el ticket del cliente                            ≈  240 tokens
                                                      ───────────
    total de entrada                                 ≈  740 tokens

  Salida
    la categoría elegida + una línea de justificación ≈   35 tokens

El cálculo de esa ejecución:

costo = (740 / 1.000.000) × P_IN  +  (35 / 1.000.000) × P_OUT
      = 0,00074 × P_IN  +  0,000035 × P_OUT

Qué esperar al hacer este cálculo con precios reales. Vas a obtener un número con cinco o seis ceros después de la coma, y tu primera reacción va a ser "esto no puede ser el problema". Es la reacción correcta y es la trampa. El costo de una ejecución con IA es siempre imperceptible. El costo aparece en la multiplicación, y por eso el segundo paso no es opcional:

Proyección mensual de ticket-classify

  300 ejecuciones/día × 30 días = 9.000 ejecuciones/mes

  entrada mensual = 9.000 × 740  = 6.660.000 tokens  ≈  6,66 millones
  salida mensual  = 9.000 ×  35  =   315.000 tokens  ≈  0,32 millones

  costo mensual = 6,66 × P_IN  +  0,32 × P_OUT

Ahora el número es legible: 6,66 millones de tokens de entrada al mes, para un workflow que hace una sola cosa pequeña. Fíjate en la proporción, porque es la lección de este ejemplo: de esos 740 tokens de entrada, 500 son fijos —el system prompt y las descripciones de las herramientas viajan idénticos en cada una de las 9.000 llamadas— y solo 240 son el ticket real. Dos tercios de lo que pagas es texto que se repite.

Y aquí está la palanca que casi nadie usa: si recortas el system prompt de 320 a 160 tokens sin perder calidad de clasificación, ahorras 160 tokens × 9.000 ejecuciones = 1,44 millones de tokens al mes, todos los meses, sin tocar nada más. Es el tipo de optimización que no se ve en una ejecución individual y que se ve muchísimo en la factura.

Ahora repite el mismo cálculo para reply-draft y mira cómo cambia el perfil:

Una ejecución de reply-draft (caso típico)

  Entrada   ≈ 1.400 tokens   (system prompt más largo, con la política de devoluciones)
  Salida    ≈   380 tokens   (el borrador de respuesta)

  120 ejecuciones/día × 30 días = 3.600 ejecuciones/mes

  entrada mensual = 3.600 × 1.400 = 5,04 millones de tokens
  salida  mensual = 3.600 ×   380 = 1,37 millones de tokens

reply-draft corre menos de la mitad de veces que ticket-classify y consume una cantidad comparable de tokens de entrada — más una salida cuatro veces mayor, que además se cobra al precio caro. Si te preguntan "¿cuál de los dos optimizamos primero?", la respuesta ya no es una opinión.

Ojo con una tentación. Estos números son de Terra Market, que es una empresa inventada. No los copies a tu instancia. Mídelos en la tuya, que es exactamente lo que construyes en la sección siguiente.

Las cinco fugas

Con la aritmética clara, veamos por dónde se escapa el dinero en la práctica. Estas cinco explican la enorme mayoría de las facturas que se disparan, y conviene conocerlas por nombre para poder buscarlas.

Fuga 1 — El bucle agéntico sin techo razonable. Es la más cara y la más silenciosa. Un agente no hace una llamada al modelo: hace las que necesite. Cada vuelta manda de nuevo todo el contexto acumulado más lo nuevo, así que la vuelta número diez cuesta bastante más que la primera. Si el techo está alto, una ejecución mala puede costar diez o veinte veces lo que cuesta una normal, y salir en verde. Es el caso de Terra Market y es toda la lección 3.

Fuga 2 — El prompt que crece por acumulación. Nadie decide "voy a duplicar el system prompt". Lo que pasa es que cada vez que el agente se equivoca en un caso raro, alguien le agrega una frase de excepción para cubrirlo. Doce excepciones después, el prompt tiene 900 palabras y viaja completo en cada llamada, para siempre. Es un sumando constante multiplicado por todo tu volumen. Cómo detectarla: compara el prompt de hoy con el de hace tres meses. Si nunca lo has recortado, ha crecido.

Fuga 3 — El contexto que se arrastra. En conversaciones con memoria, cada turno vuelve a mandar los turnos anteriores. El turno diez paga por los nueve previos. En un chat de soporte que dura veinte mensajes, los últimos mensajes cuestan varias veces lo que costaron los primeros. Cómo detectarla: si tu agente tiene memoria conectada, mira el consumo de tokens del primer turno contra el del último de una conversación larga. La diferencia te dice si necesitas una ventana de memoria acotada.

Fuga 4 — El reintento que vuelve a pagar. En el módulo 2 aprendiste a poner Retry On Fail en los nodos frágiles, y es una buena práctica. Sobre un nodo de IA tiene un matiz que no tiene sobre un HTTP Request: cada reintento vuelve a pagar la llamada completa. Tres intentos sobre una llamada que falla dos veces cuestan tres llamadas. Si el proveedor tiene una mala tarde y tu tasa de fallo sube del 1% al 15%, ese renglón se multiplica sin que nadie cambie nada. Cómo detectarla: cruza tu tasa de error de nodos de IA con tu configuración de reintentos. Si tienes tres intentos y un 10% de fallo, estás pagando un 20% de más.

Fuga 5 — Las ejecuciones que nadie pidió. Workflows de prueba que quedaron publicados. Triggers programados cada cinco minutos cuando el negocio los necesita una vez por hora. Workflows duplicados que corren en paralelo porque alguien clonó uno para probar y no lo despublicó. Es la fuga menos interesante intelectualmente y la más frecuente. Cómo detectarla: lista tus workflows publicados que contengan un nodo de IA y, para cada uno, responde "¿quién consume su resultado?". Si la respuesta es "nadie", ya lo encontraste.

Fíjate en un patrón: las cinco son invisibles para el monitoreo tradicional. Ninguna produce un error, ninguna baja la tasa de éxito, ninguna dispara una alerta de disponibilidad. La única superficie donde se ven todas es la que estás por construir.

Construir cost_log

Ahora la parte concreta. Vamos a instrumentar un workflow con IA para que registre su propio consumo.

De dónde salen los números

Cuando un nodo de IA termina, n8n muestra en el panel de ejecución información sobre el consumo de esa llamada — típicamente un objeto con los tokens de entrada, los de salida y el total. El nombre exacto de esos campos y el lugar exacto donde aparecen dependen del sub-nodo de modelo y de tu versión de n8n, así que el primer paso no se salta y no se adivina:

1. Abre el workflow que quieres instrumentar y ejecútalo una vez con datos reales.
2. En el panel de ejecución, abre el nodo del agente (o el sub-nodo del modelo) y mira su salida y sus registros.
3. Localiza con tus propios ojos dónde están los tokens. Anota la ruta exacta: si está en json.tokenUsage, si está en json.usage, si los campos se llaman promptTokens y completionTokens o input_tokens y output_tokens.

Ese paso de reconocimiento toma dos minutos y te ahorra media hora de escribir código contra un campo que no existe. Cada versión y cada proveedor tienen su forma, y lo que ves en tu pantalla manda sobre lo que diga cualquier guía.

El nodo Code que cuenta y calcula

Con la ruta identificada, el cálculo es un nodo Code. Y aquí conviene ser explícito sobre por qué el nodo Code es la herramienta correcta para esto en n8n 2.0, porque hay mucha confusión al respecto.

Desde n8n 2.0 el nodo Code corre en un proceso aislado y tiene restricciones duras: no puede hacer peticiones HTTP, no puede leer ni escribir archivos, y en Cloud solo tiene disponibles unos pocos módulos (crypto y moment). No hay fetch, no hay axios, no hay require de paquetes arbitrarios, no hay this.helpers, no hay $env. Si tu instinto es "voy a escribir un nodo Code que llame a la API de precios del proveedor", eso no se puede hacer y hay que hacerlo con un nodo HTTP Request.

Pero contar tokens y multiplicar por un precio no requiere nada de eso. Los tokens ya vienen en el item. El precio ya lo tienes como constante. Lo único que hace falta es aritmética sobre datos que ya están en memoria — y para eso el nodo Code es exactamente la herramienta indicada. Es el buen uso: transformar y calcular sobre lo que ya llegó.

// Nodo: Code — "Calculate cost"
// Modo: Run Once for All Items
// Entrada: la salida del nodo de IA, que trae el consumo de tokens
// Salida: un item por llamada, listo para escribirse en cost_log

// Precios por millón de tokens. Los tomas de la página de precios del
// proveedor el día que montas esto, y los revisas cada trimestre.
// Van aquí arriba, en un solo lugar, para que cambiarlos sea trivial.
const PRICE_IN_PER_M = 0;    // ← sustituye por el precio vigente de entrada
const PRICE_OUT_PER_M = 0;   // ← sustituye por el precio vigente de salida
const MODEL_NAME = 'model-id-que-usas';

const rows = [];

for (const item of $input.all()) {
  const data = item.json;

  // Los tokens vienen del nodo de IA. Ajusta estas rutas a lo que
  // viste en TU panel de ejecución — no las copies a ciegas.
  const usage =
    data.tokenUsage ??      // forma frecuente en los sub-nodos de modelo
    data.usage ??           // forma frecuente en respuestas crudas
    {};

  // Cada proveedor nombra los campos distinto. Se cubren las dos formas
  // más comunes y se cae a 0 si no aparece ninguna, para que un cambio
  // de nombre produzca un 0 visible en el registro y no una excepción.
  const inputTokens =
    usage.promptTokens ?? usage.input_tokens ?? 0;
  const outputTokens =
    usage.completionTokens ?? usage.output_tokens ?? 0;

  // La aritmética de la fórmula, tal cual.
  const costIn = (inputTokens / 1000000) * PRICE_IN_PER_M;
  const costOut = (outputTokens / 1000000) * PRICE_OUT_PER_M;

  rows.push({
    json: {
      workflow_name: $workflow.name,      // qué workflow gastó
      execution_id: $execution.id,        // para poder volver a la ejecución
      model: MODEL_NAME,                  // qué modelo atendió
      input_tokens: inputTokens,
      output_tokens: outputTokens,
      total_tokens: inputTokens + outputTokens,
      cost_in: costIn,
      cost_out: costOut,
      // El costo total es lo que va a la suma mensual.
      cost_total: costIn + costOut,
      // Marca las filas donde no se encontró el consumo: si esta columna
      // se llena de true, tus rutas de campo cambiaron y hay que revisarlas.
      usage_missing: inputTokens === 0 && outputTokens === 0,
      logged_at: new Date().toISOString(),
    },
  });
}

return rows;

Vale la pena detenerse en tres decisiones de ese código, porque son las que lo hacen sobrevivir en producción.

Primera: los precios están arriba, juntos y con nombre. Cuando el proveedor cambie el precio, o cuando cambies de modelo tras leer la lección 4, tocas dos líneas. Si esas constantes estuvieran incrustadas dentro del bucle, tocarías el código en varios lugares y algún día te olvidarías de uno.

Segunda: los ?? con caída a cero, y la bandera usage_missing. Si mañana n8n renombra el campo o cambias de proveedor, el código no explota: escribe un cero y lo marca. Un cero marcado es infinitamente mejor que una excepción, porque el registro sigue funcionando y tú ves la señal en la columna. Un workflow de costos que tumba el workflow de negocio cuando cambia un nombre de campo es un workflow de costos que alguien va a desconectar.

Tercera: se guardan los tokens crudos, no solo el costo. Si dentro de seis meses el precio cambia, con los tokens guardados puedes recalcular el histórico; con solo el costo, no. Guarda siempre la magnitud física, no solo su conversión a dinero. Es la misma razón por la que un registro de consumo eléctrico guarda kilovatios-hora y no pesos.

Qué esperar al ejecutarlo. El panel de salida muestra un item por cada llamada al modelo que hubo en esa ejecución. Si el agente dio tres vueltas, verás tres items — y esa es tu primera evidencia visual de que el bucle agéntico es real y cuesta. Cada item trae input_tokens y output_tokens con números, y cost_total con un decimal pequeñísimo. Si usage_missing sale en true, no sigas: vuelve al panel de ejecución y corrige las rutas de los campos. Un registro que escribe ceros es peor que no tener registro, porque da falsa tranquilidad.

Dónde vive el registro

Los items que produce ese nodo tienen que ir a algún lado. Tres opciones, de menos a más:

Sea cual sea, una regla dura: el registro de costo no puede romper el workflow de negocio. Si la escritura del log falla, el ticket del cliente igual se tiene que clasificar. En la práctica eso significa poner la rama de costo en una salida separada, con su propio manejo de error, configurada para no detener el flujo principal. El mecanismo exacto —Continue On Error, rama de error, workflow de error global— lo aprendiste en el módulo 2; aquí solo se aplica.

De medir a presupuestar

Con cost_log escribiendo, ya puedes responder preguntas que antes eran opiniones. Vale la pena listar las cuatro que más se usan, porque son las que te van a pedir:

-- 1. ¿Cuánto gastamos este mes, por workflow?
SELECT workflow_name,
       SUM(cost_total)  AS spend,
       SUM(total_tokens) AS tokens,
       COUNT(*)          AS calls
FROM cost_log
WHERE logged_at >= date_trunc('month', now())
GROUP BY workflow_name
ORDER BY spend DESC;

-- 2. ¿Cuál fue la ejecución más cara, y cuál el caso típico?
SELECT workflow_name,
       MAX(cost_total)    AS worst_call,
       AVG(cost_total)    AS avg_call,
       COUNT(*)           AS calls
FROM cost_log
WHERE logged_at >= now() - interval '7 days'
GROUP BY workflow_name;

-- 3. ¿Cuántas llamadas al modelo hace una ejecución típica?
--    (si este número sube, alguien tocó Max Iterations o el prompt)
SELECT workflow_name,
       execution_id,
       COUNT(*) AS calls_per_execution
FROM cost_log
WHERE logged_at >= now() - interval '24 hours'
GROUP BY workflow_name, execution_id
ORDER BY calls_per_execution DESC;

-- 4. ¿Hay filas donde no se capturó el consumo?
--    (si esto deja de ser 0, tus rutas de campo cambiaron)
SELECT COUNT(*) AS broken_rows
FROM cost_log
WHERE usage_missing = true
  AND logged_at >= now() - interval '24 hours';

La consulta 2 merece un comentario. El promedio miente y el máximo no. En un sistema con IA, el promedio se ve tranquilizador porque la mayoría de las ejecuciones son baratas; lo que te arruina el mes son las pocas que se disparan. Cuando reportes costos, reporta las dos cifras juntas — y si puedes, reporta también el percentil alto. Una diferencia grande entre el promedio y el máximo es la firma de un bucle agéntico sin techo, que es exactamente lo que la lección 3 va a arreglar.

Y la consulta 3 es tu detector de cambios de configuración. Si el número de llamadas por ejecución sube de un día para otro sin que el volumen cambie, alguien tocó algo. Esa consulta, corriendo a diario, es lo que le habría dado a Terra Market la respuesta el mismo día en vez de al mes siguiente.

El presupuesto: monthly_budget

Medir sin tope es contemplar. El paso final es fijar un número y compararse contra él.

Cómo se fija. No se saca del aire: se calcula hacia atrás desde la operación.

1. Costo observado por ejecución (usa el promedio Y el máximo, no solo uno)
2. × volumen mensual esperado, con un margen de crecimiento
3. + un colchón para las ejecuciones caras
4. = monthly_budget

Terra Market, con los números de arriba:
   ticket-classify:  9.000 ejecuciones/mes
   reply-draft:      3.600 ejecuciones/mes
   margen de crecimiento del 20%
   colchón del 15% para la cola de ejecuciones caras

Qué hacer con el número. Un presupuesto que solo se mira a fin de mes no sirve de nada — para eso ya está la factura. Lo que sirve es compararse contra el acumulado del mes en curso, todos los días, y avisar antes de llegar:

gasto_acumulado_del_mes  vs.  monthly_budget × (día_del_mes / días_del_mes)

  Si el acumulado va por encima de esa línea proporcional, vas a pasarte.
  Y lo sabes el día 8, no el día 30.

Ese cálculo es un workflow programado diario: consulta cost_log, suma el mes en curso, compara contra la línea proporcional, y si va por encima manda una notificación. Es literalmente la misma estructura de alerta que montaste en el módulo 4 para los fallos, con otra métrica adentro. En el proyecto de la lección 8 lo vas a construir completo, con dos umbrales —uno de aviso y uno de emergencia— y con una decisión explícita sobre qué pasa cuando se cruza el segundo.

Errores comunes

Guardar el costo en dinero y tirar los tokens (práctico). Qué pasa: el registro guarda solo cost_total. Seis meses después el proveedor baja los precios, o el equipo cambia de modelo, y toda la serie histórica queda incomparable — no se puede saber si el consumo bajó o si solo bajó el precio. Por qué pasa: el dinero es lo que interesa al final, así que parece lo único que hace falta guardar. Cómo detectarlo: pregúntate si podrías recalcular el costo del mes pasado con los precios de hoy. Si no puedes, te falta información. Cómo corregirlo: guarda siempre input_tokens y output_tokens además del costo, y guarda también el model que atendió la llamada. Con esos tres campos el histórico se puede recalcular entero; sin ellos, no.

Instrumentar solo el workflow que sospechas (conceptual). Qué pasa: alguien sospecha de reply-draft, le pone medición solo a ese, y descubre que consume menos de lo esperado. Como no midió los otros, sigue sin saber dónde está el gasto y concluye —erróneamente— que el problema no es la IA. Por qué pasa: instrumentar cuesta trabajo y se empieza por donde apunta la corazonada. Cómo detectarlo: cuenta cuántos de tus workflows con IA escriben en cost_log. Si no son todos, tu registro tiene huecos y cualquier conclusión que saques de él es parcial. Cómo corregirlo: instrumenta todos los workflows que llamen a un modelo, aunque parezcan inofensivos, y hazlo antes de sacar conclusiones. Los workflows "inofensivos" que corren cada quince minutos son justamente donde se esconde la fuga 5.

Poner la escritura del log en el camino crítico (práctico). Qué pasa: la tabla donde vive cost_log se llena, o la base no responde, y los tickets de soporte dejan de clasificarse porque el workflow se detiene en el nodo que escribe el registro de costos. Por qué pasa: se conecta el nodo de log en serie, después del nodo de negocio, sin pensar en qué pasa si falla. Cómo detectarlo: dibuja mentalmente tu workflow y pregúntate "si este nodo falla, ¿el cliente se entera?". Si la respuesta es sí para el nodo de costos, tienes el problema. Cómo corregirlo: rama separada, Continue On Error activo en el nodo de escritura, y —si tu volumen lo justifica— acumular en lote en vez de escribir fila por fila. La observabilidad nunca puede ser la causa de una caída del negocio.

Confundir el costo de ejecución de n8n con el costo de tokens (conceptual). Qué pasa: alguien mira el consumo de ejecuciones de su plan de n8n Cloud, ve que va holgado, y concluye que el costo está bajo control. La factura del proveedor de IA llega aparte y es diez veces mayor. Por qué pasa: los dos son "el costo de la automatización" en la cabeza de quien no lo ha desglosado, pero son dos facturas de dos empresas distintas. Cómo detectarlo: pon los dos números uno al lado del otro en la misma tabla. Casi siempre sorprende cuál domina. Cómo corregirlo: cuando reportes el costo de una automatización con IA, repórtalo siempre desglosado en plataforma (ejecuciones de n8n o el servidor donde se aloja) y modelo (tokens). Son palancas distintas: la primera se optimiza con arquitectura de workflows, la segunda con prompts, modelo y guardarraíles.

Escribir un nodo Code que salga a buscar el precio (práctico). Qué pasa: alguien intenta que el nodo Code consulte la página de precios del proveedor con fetch o axios, para que el cálculo esté siempre actualizado. El nodo falla. Por qué pasa: desde n8n 2.0 el nodo Code corre aislado y no tiene acceso a la red ni al sistema de archivos; en Cloud solo dispone de crypto y moment. No hay fetch, no hay axios, no hay require arbitrario, no hay this.helpers, no hay $env. Cómo detectarlo: si tu código en un nodo Code menciona cualquiera de esas cosas, no va a correr. Cómo corregirlo: el precio es una constante que tú mantienes, no un dato que se consulta en cada ejecución — y si de verdad quieres traerlo de algún lado, eso lo hace un nodo HTTP Request antes del Code, que sí puede salir a la red. El Code se queda con lo que sabe hacer bien aquí: aritmética sobre datos que ya llegaron en el item.

Ejercicios

Ejercicio 1 — Calcula y proyecta. Terra Market está evaluando meter un tercer agente: refund-check, que lee una solicitud de devolución y decide si califica automáticamente según la política. Mediste una ejecución típica y obtuviste 1.100 tokens de entrada y 90 de salida. El workflow correría unas 220 veces al día.

(a) Escribe la fórmula del costo mensual, dejando los precios como P_IN y P_OUT. (b) Calcula los tokens mensuales de entrada y de salida. (c) Del total de entrada, se sabe que 800 tokens son fijos (system prompt + política) y 300 son la solicitud del cliente. ¿Cuánto ahorrarías al mes si recortaras la parte fija a 500 tokens? (d) Alguien propone: "en vez de recortar el prompt, usemos un modelo más barato". Explica en una frase por qué las dos cosas no son alternativas.

costo_mensual = (220 × 30 × 1100 / 1.000.000) × P_IN
              + (220 × 30 ×   90 / 1.000.000) × P_OUT

entrada = 6.600 × 1.100 =  7.260.000 tokens  ≈ 7,26 millones
salida  = 6.600 ×    90 =    594.000 tokens  ≈ 0,59 millones

ahorro = 6.600 × 300 = 1.980.000 tokens de entrada al mes  ≈ 1,98 millones

Es una reducción del 27% de la entrada de ese workflow — sin tocar
el modelo, sin tocar el volumen y sin cambiar el resultado del negocio.

Ejercicio 2 — Clasifica las fugas. Aquí van seis observaciones sobre la instancia de Terra Market. Para cada una, di a cuál de las cinco fugas corresponde, si es multiplicador o sumando, y cuál sería tu primera acción.

(a) El agente de ticket-classify tiene memoria conectada y las conversaciones de soporte llegan a los 15 turnos. (b) Hay un workflow llamado reply-draft-v2-test publicado, con trigger cada 15 minutos, cuyo resultado no lo lee nadie. (c) El nodo del agente tiene Retry On Fail con 3 intentos, y la tasa de error del proveedor subió al 12% la semana pasada. (d) El system prompt de reply-draft pasó de 200 a 900 palabras en cuatro meses. (e) Max Iterations está en 30 en ticket-classify. (f) weekly-report genera un resumen de 4.000 palabras que solo dos personas leen, y de esas 4.000 leen las primeras 300.

Ejercicio 3 — Diseña el registro para que sobreviva. Vas a montar cost_log en la instancia de Terra Market. Escribe la lista de campos que vas a guardar por fila, y para cada uno justifica en media frase por qué está. Después responde estas tres preguntas de diseño:

(a) ¿Qué pasa si el proveedor cambia el nombre del campo donde vienen los tokens? (b) ¿Qué pasa si la base de datos donde vive cost_log no responde durante una hora? (c) ¿Qué pasa si dentro de un año el proveedor baja los precios a la mitad y alguien pregunta "¿nuestro consumo bajó o solo bajó el precio?"

Resumen y siguiente paso

Ya sabes qué se te está cobrando. Un token es un pedacito de texto, y se paga por cada uno que entra y por cada uno que sale — con una asimetría que manda: la salida cuesta varias veces más que la entrada, porque leer es paralelo y escribir es secuencial. De ahí el principio que vas a usar toda la guía: si tienes que elegir dónde recortar, empieza por lo que el modelo escribe.

Tienes la fórmula —tokens entre un millón por el precio del millón, sumando las dos direcciones— y sabes dónde buscar los precios vigentes en vez de confiar en una tabla impresa que envejece. Hiciste el cálculo de una ejecución de ticket-classify y descubriste lo que descubre todo el mundo: que una ejecución cuesta una fracción imperceptible y que el costo aparece en la multiplicación por el volumen. Y viste que dos tercios de la entrada de ese workflow es texto fijo que se repite en cada llamada, lo que convierte el recorte del prompt en la palanca más barata que existe.

Te llevas las cinco fugas —bucle agéntico sin techo, prompt que crece por acumulación, contexto que se arrastra, reintento que vuelve a pagar, ejecuciones que nadie pidió— con la característica que comparten: ninguna produce un error, y por eso el monitoreo tradicional no las ve.

Y construiste cost_log: un nodo Code que lee el consumo de tokens del item, lo multiplica por precios que viven en un solo lugar, y escribe una fila por llamada con los tokens crudos además del dinero. Con tres decisiones que lo hacen sobrevivir: precios como constantes, caída a cero con bandera usage_missing en vez de excepción, y la magnitud física guardada junto a su conversión. Todo eso dentro de las restricciones reales del nodo Code en n8n 2.0 — sin red, sin sistema de archivos, solo aritmética sobre lo que ya llegó, que es exactamente para lo que sirve.

Antes de avanzar deberías poder: explicar por qué la salida cuesta más que la entrada; calcular el costo mensual de un workflow a partir de una ejecución medida y su volumen; nombrar las cinco fugas y decir cuáles son multiplicadores; y decir qué campos guarda tu registro y por qué cada uno.

La lección 3 va directo al multiplicador más grande de los cinco: el nodo AI Agent y su bucle. Vas a ver qué es exactamente una iteración, por qué la iteración número diez cuesta mucho más que la primera, qué hace Max Iterations —cuyo valor por defecto es 10— y por qué subirlo no suma gasto sino que lo multiplica. También vas a ver Return Intermediate Steps, que es la opción que te deja ver el bucle por dentro y que tiene su propio costo. Y vas a resolver, con los números de cost_log, el caso concreto que abrió el módulo: qué hacer con el Max Iterations que alguien subió a 30 en ticket-classify.

Recursos

• Code node — n8n Docs — la referencia del nodo con el que construiste cost_log, incluidos sus límites en n8n 2.0: sin acceso a red ni a archivos, y con módulos restringidos en Cloud.
• Built-in methods and variables — n8n Docs — $input, $workflow, $execution y el resto de lo que sí tienes disponible dentro de un nodo Code.
• Data tables — n8n Docs — las tablas nativas de n8n, la opción más rápida para que cost_log exista hoy sin montar infraestructura.
• Anthropic — pricing · OpenAI — API pricing · Google — Gemini API pricing — las páginas de precios vigentes. Consúltalas el día que llenes las constantes del nodo Code, y revísalas cada trimestre.
• AI Agent node — n8n Docs — el nodo cuyo bucle genera las llamadas que acabas de aprender a contar. Es el tema de la lección siguiente.
• Módulo 4 de esta guía — la capa de observabilidad donde cost_log debería vivir a largo plazo: logging estructurado, almacén de métricas y alertas.