¿Por qué "Reasoning Effort" solo está disponible para modelos que coinciden con gpt-5*, o1 y o3+?

Preguntas
1

Hola a todos,

Estoy usando el nodo OpenAI Chat Model con un endpoint personalizado compatible con OpenAI (LiteLLM) que sirve un modelo que admite razonamiento.

Por ejemplo, mi modelo (glm-5.2) admite el parámetro reasoning_effort compatible con OpenAI, pero noté que la opción Reasoning Effort no aparece en el nodo. Solo aparece al seleccionar un modelo cuyo nombre coincide con ciertos modelos de OpenAI (por ejemplo, gpt-5.*), lo que parece ser una verificación del frontend.

Después de revisar el código fuente, descubrí que el campo solo se muestra cuando el nombre del modelo coincide con esta expresión regular:

regex: '(^o1([-\\d]+)?$)|(^o[3-9].*)|(^gpt-5.*)'

Por lo tanto, por ejemplo:

  • :cross_mark: glm-5.2 → Reasoning Effort está oculto
  • :white_check_mark: gpt-5.6 → Reasoning Effort aparece

image
image877×535 67.4 KB

La lógica de solicitud en sí es genérica: simplemente envía:

{
  "reasoning_effort": "high"
}

Esto significa que la limitación parece estar solo en la interfaz de usuario.

También noté que los valores disponibles se limitan a low, medium y high. Sería bueno que el campo fuera editable (o al menos incluya valores adicionales como none, que varios proveedores admiten).

Para proveedores compatibles con OpenAI como LiteLLM, vLLM, LM Studio, OpenRouter, etc., los nombres de modelos personalizados aún pueden admitir reasoning_effort, por lo que esta expresión regular impide que los usuarios accedan a una función que su backend ya admite.

¿Tendría sentido:

  • mostrar siempre la opción al usar una URL base personalizada,
  • determinar la compatibilidad a partir de las capacidades del modelo en lugar de hacer coincidir el nombre del modelo, o
  • simplemente hacer que la opción esté disponible para todos los modelos compatibles con OpenAI y permitir que el backend valide si es compatible?

Principalmente me pregunto si esta es una decisión de diseño intencional o simplemente un atajo de implementación.

2

¡Excelente hallazgo, @mohamed3nan !!!

image
image672×601 3.09 KB

Ahora sé cómo „activar" el razonamiento para otros modelos :partying_face:

Solicitud de función aquí:

Quizás quieras votarla

3

¡Gracias! En realidad encontré una solución en los comentarios de ese tema. Solo cambia el selector de modelo a “Por ID” e ingresa el nombre de tu modelo manualmente:

image
image840×403 17.3 KB

El problema restante es que Reasoning Effort solo acepta low, medium y high. No hay soporte para valores como none, xhigh o max, aunque muchos de los modelos frontera más recientes los admitan.

Parece que este nodo no se ha puesto al día con las capacidades de razonamiento más nuevas aún..

Espero que se actualice pronto, quizás como parte de n8n v3..

5

Hola @mohamed3nan
El límite low/medium/high no es solo el desplegable, el nodo también valida el valor en su constructor de solicitudes. En la ruta predeterminada de Chat Completions, reasoning_effort solo se reenvía cuando es igual a low, medium o high, por lo que un valor como none, xhigh o max se descarta antes de la llamada y nunca llega a tu endpoint, sin importar cómo se seleccione el modelo.
Para enviar un reasoning_effort arbitrario a LiteLLM, evita el nodo y llama a tu /chat/completions con un nodo HTTP Request, con el valor directamente en el cuerpo, n8n lo reenvía tal cual:

{
  "model": "glm-5.2",
  "messages": [ { "role": "user", "content": "..." } ],
  "reasoning_effort": "minimal"
}
6

Finalmente, esto se resolvió con un buen enfoque en la nueva versión n8n@2.34.0:

image
image551×280 14.2 KB

Hay un nuevo campo Extra Body que ahora podemos usar para pasar cualquier cosa que admita el backend, como reasoning_effort.

¡Gracias a todos!