Diagnóstico medido · 17 de octubre de 2026 · 9 min de lectura

El nodo de IA no falló: se quedó sin presupuesto antes de escribir

El nodo está en verde, la petición salió con HTTP 200, la respuesta trae usage con tokens cobrados y sin embargo content está vacío. No es un timeout, no es la credencial, no es el prompt: es el modelo gastando todo lo que le diste en pensar. Lo medimos en dos flujos distintos y los números explican el síntoma completo.

El síntoma, tal cual se ve en n8n

Un nodo HTTP Request contra la API de un modelo con «razonamiento» devuelve esto (recortado):

{
  "choices": [{
    "message": { "role": "assistant", "content": "" },
    "finish_reason": "length"
  }],
  "usage": {
    "prompt_tokens": 660,
    "completion_tokens": 1200,
    "completion_tokens_details": { "reasoning_tokens": 1200 }
  }
}

Tres pistas en un solo objeto, y las tres importan:

• content vacío pero HTTP 200: la petición se completó. No hay error que capturar.
• finish_reason: "length": el modelo no terminó, lo cortaron.
• completion_tokens igual a tu max_tokens y todo en reasoning_tokens: el presupuesto se gastó pensando, no escribiendo.

Y sí, esos tokens se cobran. Una respuesta vacía no es gratis: es la factura de un razonamiento que no llegó a producir nada.

Los números que medimos

Misma entrada, mismo prompt, mismo lote de cuatro negocios. Solo cambia si el razonamiento está activado:

La diferencia no es cosmética: es 3 a 7 veces el costo de salida por el mismo trabajo, con un modo de fallo que aparece justo cuando el lote es más grande. En el flujo de extracción de reuniones —una tarea mucho más pesada que puntuar un negocio— medimos 2.031 tokens de razonamiento para 1.216 de salida útil. Es decir: dos tercios del presupuesto se fueron en pensar, y con max_tokens en 1.200 ese flujo no habría escrito nunca el JSON.

Por qué empeora cuando subes de modelo

La intuición dice lo contrario: «pago el modelo mejor, debería funcionar mejor». Pero el fallo no depende de la calidad del modelo, sino de la relación entre cuánto razona y cuánto le dejas escribir. Los modelos más capaces razonan más, así que un max_tokens que servía con el modelo barato puede quedarse corto con el caro — y el síntoma es el mismo: nodo verde, salida vacía.

En nuestro flujo 01 el valor es max_tokens: 1200 y funciona con el modelo rápido. Si cambias modeloIA al modelo pro sin tocar el body, lo más probable es que veas el vacío en el primer lote grande. No es un defecto del kit: es el parámetro que tienes que acompañar al cambio de modelo.

El diagnóstico en 60 segundos

1. Mira usage, no el nodo. Si completion_tokens es exactamente tu max_tokens, el modelo fue cortado.
2. Mira finish_reason. length = presupuesto agotado. stop con contenido vacío = otro problema (prompt o filtro).
3. Mira reasoning_tokens. Si se lleva más del 50 % del total, desactiva el razonamiento o sube el límite; no hay tercera vía.
4. Reproduce con un solo item. Si con un item funciona y con cuatro falla, es presupuesto, no lógica: el costo de razonamiento no es lineal con el tamaño del lote que tú crees.

Los tres arreglos, en orden de preferencia

1. Desactivar el razonamiento cuando la tarea es de formato. Puntuar con una rúbrica y devolver seis claves no requiere deliberación: requiere obediencia al formato. Es lo que hace el kit por defecto, y es la razón por la que el costo medido es 117–121 tokens por lead en lugar de 351–800.
2. Subir max_tokens cuando la tarea sí necesita pensar. Extraer una reunión completa en JSON es de esas tareas: por eso el flujo 02 usa 4.000 con el modelo pro y 6.000 con el rápido. Un límite alto no se cobra si no se usa; un límite bajo sí se cobra, y no produce nada.
3. Partir el lote. Cuatro leads por petición es un compromiso entre velocidad y riesgo. Si tu prompt crece, baja el lote antes que el límite.

Lo que no hay que hacer: añadir un reintento silencioso. Reintentar la misma petición con el mismo presupuesto produce la misma respuesta vacía, dos veces cobrada. Si el flujo tiene que reintentar, que sea subiendo el límite o bajando el lote — no repitiendo la jugada.

La red de seguridad que sí sirve

El flujo no puede depender de que el modelo obedezca. Nuestro nodo de fusión empareja por id y descarta respuestas huérfanas o vacías por diseño, así que una respuesta mala no rompe la corrida: produce menos filas y lo deja escrito. En el flujo 02 hay además una puerta de calidad: si la confianza de la extracción es baja o falta la empresa, no se escribe en el CRM y se devuelve el motivo por HTTP.

Ese es el patrón que recomendamos en cualquier automatización con IA: el modelo es una fuente de datos falible, y el flujo tiene que saber qué hacer cuando no llega nada. Un nodo en rojo se ve; una respuesta vacía se cuela hasta la hoja de cálculo y la descubres tres semanas después.

Lista rápida para «el nodo está verde pero no devuelve nada»

1. completion_tokens == max_tokens → presupuesto agotado (este artículo).
2. reasoning_tokens alto → desactiva razonamiento o sube el límite.
3. finish_reason: "stop" con content vacío → revisa el prompt y el response_format.
4. HTTP 200 con content en null → mira si el modelo devolvió el JSON en un campo distinto (algunos lo hacen cuando se les pide «solo JSON» y el modo estricto no está activo).
5. Todo bien y aun así 0 filas → el problema está en el nodo siguiente: emparejamiento por id o deduplicación con estado.

Relacionado: las cinco etapas del flujo · la rúbrica de puntaje · la memoria del dedupe · todos los artículos