Por qué tus escenarios de Make.com caen por timeout al llamar a un LLM — y cómo arreglarlo

El escenario funcionó durante meses. Entonces cambiaste el modelo por uno que razona antes de responder, o dejaste que el prompt creciera más allá de unos miles de tokens, y ahora la ejecución muere a mitad con un timeout — unas veces a los 40 segundos, otras a los cinco minutos, y casi nunca dos veces en el mismo paso.

No es una integración inestable. Es el resultado predecible de poner una operación cuya duración no controlas detrás de una conexión que tiene que quedarse abierta todo el rato. Abajo: cómo confirmar que es eso lo que pasa, por qué subir el timeout solo mueve el muro de sitio, y qué forma tiene el arreglo.

Qué provoca los timeouts de Make con LLMs

Make ejecuta un escenario como una cadena de pasos síncronos. Cada módulo abre una petición, se bloquea hasta recibir respuesta, pasa su salida al siguiente y solo entonces suelta. En ese modelo no hay sitio para un paso que responde cuando le parece, que es exactamente lo que es un modelo de razonamiento.

Tres cosas empujan una llamada por encima del techo, y se suman entre sí:

• Tokens de razonamiento. Un modelo que delibera antes de contestar puede gastar la mayor parte de su tiempo de reloj produciendo salida que nunca ves. La respuesta es corta; la llamada no.
• Tamaño del prompt. Cada mil tokens más de contexto es más tiempo hasta el primer token. Los escenarios que reinyectan un documento entero, o el JSON completo del paso anterior, lo pagan en cada llamada.
• Bucles de herramientas. Si la llamada va a un agente y no a una completación pelada, una sola petición esconde varias idas y vueltas al modelo más lo que tarden las herramientas.

Nada de esto se ve desde Make. Desde ahí es un módulo, una línea en el registro de ejecución y una duración que de vez en cuando se pasa del límite.

Los límites duros: módulos HTTP frente a agentes nativos

Conviene saber contra qué techo estás chocando, porque no son el mismo techo ni tienen la misma salida. A día de hoy Make documenta aproximadamente esta forma — contrasta los números con tu propio plan antes de construir sobre ellos:

Por eso el primer arreglo que todo el mundo prueba —subir el timeout— funciona exactamente una vez. Pasas de 40 s a 300 s, los fallos paran unas semanas, y entonces un documento un poco más largo o un agente un poco más hablador te devuelve al punto de partida, solo que ahora cada fallo cuesta cinco minutos de ranura de escenario en vez de cuarenta segundos.

Llamada bloqueante frente a razonamiento multi-paso

El desajuste es estructural. Una llamada bloqueante da por hecho que el trabajo es acotado y rápido: preguntas, contesta, se cierra la conexión. El razonamiento multi-paso no es ni una cosa ni la otra. Está acotado solo por el problema, y su duración es una distribución con cola larga, no un número.

Meter lo segundo dentro de lo primero tiene costes más allá del propio fallo:

• Pagas trabajo que tiras. El modelo terminó de pensar; el proveedor facturó esos tokens. Make colgó antes de que llegara la respuesta, así que pagaste y no te llevaste nada.
• Los reintentos multiplican la factura. Un reintento automático tras un timeout no reanuda nada: repite la llamada entera, a precio completo, con las mismas probabilidades de que la vuelvan a cortar.
• El estado parcial no se recupera. El paso cuatro fue bien y el cinco se cortó. Lo que escribió el cuatro ya está en tu CRM, y el escenario no tiene forma de saber hasta dónde llegó.
• El fallo no es reproducible. La misma entrada funciona el martes y falla el jueves, lo que hace casi imposible arreglarlo leyendo el escenario.

Si la duración de un paso no es algo que controles, la conexión con ese paso no debería ser algo que mantengas abierto.

El arreglo: colas asíncronas y estado persistente

La forma de la solución es la misma tanto si te la construyes como si adoptas una plataforma: la petición que arranca el trabajo y la petición que recoge el resultado dejan de ser la misma petición.

En concreto son cuatro piezas. Un endpoint que acepta el trabajo y devuelve al instante un identificador. Una cola que lo guarda. Un worker que ejecuta la llamada al modelo sin ninguna conexión que mantener viva, así que su único límite real es el del proveedor. Y un registro persistente de por dónde iba el trabajo, para que una caída reanude en vez de reiniciar.

POST /v1/jobs            → 202 Accepted  { "id": "job_8fA2", "state": "queued" }

# minutos después, desde donde sea — el escenario, un webhook, un reintento:
GET  /v1/jobs/job_8fA2   → 200 OK        { "state": "done", "output": { … } }

Así corren los agentes en Bentho: el trabajo se acepta como un evento, lo ejecuta un worker con estado persistente, y se reporta al terminar — por callback si prefieres que te avisen, por consulta si prefieres preguntar. El paso que antes era una llamada bloqueante de cuatro minutos pasa a ser una petición que vuelve al instante, y el escenario deja de ser lo que tiene que seguir vivo.

La parte que importa para el coste: como el estado es persistente, un fallo en el paso cinco no tira a la basura los pasos uno a cuatro. Reanuda.

Lista de migración

No hace falta mover el escenario entero. Casi siempre uno o dos pasos son los responsables de todos los timeouts que has visto. Por este orden:

1. Mide antes de tocar nada. Exporta las ejecuciones de los últimos 30 días y saca la distribución de duración por módulo. Lo que buscas es el p95, no la media — la media está bien, y por eso el problema despista.
2. Separa los pasos genuinamente lentos de los simplemente grandes. Un paso que tarda porque el prompt lleva un documento de 40 páginas se arregla no llevando el documento, no volviéndolo asíncrono.
3. Vuelve asíncrono primero el paso lento. Sustituye el módulo bloqueante por la llamada que acepta y vuelve. Deja todo lo demás exactamente como está.
4. Decide cómo vuelve el resultado. Un callback a un segundo escenario suele ser más limpio que consultar en bucle, y gasta menos operaciones.
5. Hazlo idempotente. Pasa tu propia clave de trabajo para que un reintento no pueda crear dos de lo que sea que cree el escenario.
6. Solo entonces mira qué más puede moverse. Cuando los timeouts paran, las razones que quedan para migrar son coste y estado — y esa ya es una decisión que puedes tomar con calma.

Si tus escenarios están fallando en producción ahora mismo, el paso que vale la pena hacer hoy es el de medir. Cuesta una tarde y te dice si tienes un problema de timeout o un problema de tamaño de prompt, que tienen arreglos completamente distintos.