Warum ist "Reasoning Effort" nur für Modelle verfügbar, die gpt-5*, o1 und o3+ entsprechen

Fragen
1

Hallo zusammen,

Ich nutze den OpenAI Chat Model-Node mit einem benutzerdefinierten OpenAI-kompatiblen Endpoint (LiteLLM), der ein Modell mit Reasoning-Fähigkeiten bereitstellt.

Mein Modell (glm-5.2) unterstützt beispielsweise den OpenAI-kompatiblen Parameter reasoning_effort, aber ich habe bemerkt, dass die Option Reasoning Effort im Node nicht angezeigt wird. Sie erscheint nur bei der Auswahl eines Modells, dessen Name bestimmten OpenAI-Modellen entspricht (z. B. gpt-5.*), was eine Frontend-Überprüfung zu sein scheint.

Nach Durchsicht des Quellcodes habe ich festgestellt, dass das Feld nur angezeigt wird, wenn der Modellname diesem Regex entspricht:

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

Zum Beispiel:

  • :cross_mark: glm-5.2 → Reasoning Effort ist verborgen
  • :white_check_mark: gpt-5.6 → Reasoning Effort wird angezeigt

image
image877×535 67.4 KB

Die Request-Logik selbst ist generisch – sie sendet einfach:

{
  "reasoning_effort": "high"
}

Das bedeutet, die Einschränkung existiert nur in der Benutzeroberfläche.

Ich habe auch bemerkt, dass die verfügbaren Werte auf low, medium und high begrenzt sind. Es wäre schön, wenn das Feld bearbeitbar wäre (oder zumindest zusätzliche Werte wie none enthielte, die mehrere Anbieter unterstützen).

Bei OpenAI-kompatiblen Anbietern wie LiteLLM, vLLM, LM Studio, OpenRouter usw. können benutzerdefinierte Modellnamen dennoch reasoning_effort unterstützen, daher hindert dieser Regex Nutzer daran, auf eine Funktion zuzugreifen, die ihr Backend bereits unterstützt.

Würde es Sinn machen, entweder:

  • die Option immer anzuzeigen, wenn eine benutzerdefinierte Basis-URL verwendet wird,
  • die Unterstützung anhand von Modellmöglichkeiten statt Modellnamen-Matching zu bestimmen, oder
  • die Option einfach für alle OpenAI-kompatiblen Modelle verfügbar zu machen und dem Backend die Validierung zu überlassen, ob sie unterstützt wird?

Ich frage mich hauptsächlich, ob dies eine bewusste Designentscheidung oder einfach ein Implementierungs-Shortcut ist.

2

Großartige Entdeckung, @mohamed3nan !!!

image
image672×601 3.09 KB

Jetzt weiß ich, wie ich das „Reasoning

3

Danke! Ich habe tatsächlich einen Workaround in den Kommentaren zu diesem Thema gefunden. Wechsel einfach den Modellwähler zu **„By ID

5

Hi @mohamed3nan
Das low/medium/high-Limit ist nicht nur die Dropdown-Liste, der Node validiert den Wert auch in seinem Request Builder. Im Standard-Chat-Completions-Pfad wird reasoning_effort nur weitergeleitet, wenn es low, medium oder high entspricht. Ein Wert wie none, xhigh oder max wird vor dem Aufruf verworfen und erreicht deinen Endpoint niemals, unabhängig davon, wie das Modell ausgewählt ist.
Um einen beliebigen reasoning_effort an LiteLLM zu senden, umgehe den Node und rufe dein /chat/completions mit einem HTTP Request-Node auf, mit dem Wert direkt im Body. n8n leitet ihn unverändert weiter:

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

Schließlich wurde dies mit einem guten Ansatz in der neuen Version n8n@2.34.0 gelöst:

image
image551×280 14.2 KB

Es gibt ein neues Extra Body-Feld, das wir jetzt verwenden können, um alles zu übergeben, das das Backend unterstützt, wie beispielsweise reasoning_effort.

Danke an alle!