Bonjour à tous,
J’utilise le nœud OpenAI Chat Model avec un point de terminaison personnalisé compatible avec OpenAI (LiteLLM) qui utilise un modèle prenant en charge le raisonnement.
Par exemple, mon modèle (glm-5.2) prend en charge le paramètre reasoning_effort compatible avec OpenAI, mais j’ai remarqué que l’option Reasoning Effort n’apparaît pas dans le nœud. Elle n’apparaît que lors de la sélection d’un modèle dont le nom correspond à certains modèles OpenAI (par exemple, gpt-5.*), ce qui semble être une vérification côté interface.
Après avoir consulté le code source, j’ai constaté que le champ n’est affiché que lorsque le nom du modèle correspond à cette regex :
regex: '(^o1([-\\d]+)?$)|(^o[3-9].*)|(^gpt-5.*)'
Donc, par exemple :
glm-5.2→ Reasoning Effort est masqué
gpt-5.6→ Reasoning Effort apparaît
La logique de requête elle-même est générique—elle envoie simplement :
{
"reasoning_effort": "high"
}
Cela signifie que la limitation semble être uniquement au niveau de l’interface.
J’ai également remarqué que les valeurs disponibles sont limitées à low, medium et high. Il serait agréable que le champ soit modifiable (ou du moins qu’il inclue des valeurs supplémentaires comme none, que plusieurs fournisseurs prennent en charge).
Pour les fournisseurs compatibles avec OpenAI comme LiteLLM, vLLM, LM Studio, OpenRouter, etc., les noms de modèles personnalisés peuvent toujours prendre en charge reasoning_effort, donc cette regex empêche les utilisateurs d’accéder à une fonctionnalité que leur backend supporte déjà.
Serait-il logique de :
- toujours afficher l’option lors de l’utilisation d’une URL de base personnalisée,
- déterminer le support à partir des capacités du modèle au lieu de faire correspondre le nom du modèle, ou
- simplement rendre l’option disponible pour tous les modèles compatibles avec OpenAI et laisser le backend valider si elle est supportée ?
Je me demande principalement s’il s’agit d’une décision de conception intentionnelle ou simplement d’un raccourci d’implémentation.
