Hermes reasoning effort: Sitzung, global und pro Modell

Hermes dauerhaft auf der höchsten Reasoning-Stufe laufen zu lassen, verbessert nicht jede Aufgabe. Sichtbares Thinking beweist außerdem nicht, dass die Anfrage mit der gewählten Stufe gesendet wurde. Sinnvoller ist ein praktikabler globaler Standard, eine vorübergehende Erhöhung für schwierige Aufgaben, Modellregeln erst nach wiederholbaren Ergebnissen und eine Kontrolle mit derselben prüfbaren Aufgabe sowie den echten Provider-Daten.

Praktischer Standard: mit medium beginnen

Hermes akzeptiert none, minimal, low, medium, high, xhigh, max und ultra. Ohne gesetzten Wert wird medium verwendet. Ein Modell oder eine Route unterstützt möglicherweise nur einen Teil der Skala; eine Stufe kann reduziert, übersetzt, ignoriert oder abgelehnt werden. Prüfen Sie deshalb die aktuelle Hermes-Konfigurationsdokumentation und den Anfrageverlauf Ihres Providers.

Aufgabe	Sinnvoller Start	Wann ändern?
Formatierung, Feldextraktion oder deterministische Überarbeitung	low; minimal oder none nur nach bestätigter Unterstützung	Auf medium erhöhen, wenn Felder oder Formatvorgaben fehlen
Kleine Codeänderung, Routinefrage oder klar begrenztes Debugging	medium	Nach mehreren korrekten Läufen low testen; bei übersehenen Bedingungen high
Review mit vielen Bedingungen, dateiübergreifende Diagnose oder Abwägung	high	xhigh oder max nur testen, wenn der Gewinn wiederholt auftritt und die Wartezeit passt
Außergewöhnlich schwierige Planung	Zuerst high und xhigh vergleichen	max oder ultra nur bei erkennbarem Nutzen im kontrollierten Vergleich behalten

ultra ist eine interne Hermes-Stufe. Die Route bildet sie auf den stärksten tatsächlich sendbaren Wert ab; der Name allein rechtfertigt keinen globalen Standard.

Thinking anzeigen ist nicht dasselbe wie Effort ändern

Diese Befehle ändern den reasoning effort der aktuellen Sitzung:

/reasoning high
/reasoning none

Diese Befehle ändern nur die Anzeige des Thinking:

/reasoning show
/reasoning hide

Ein verborgenes Thinking kann weiterhin zu einer Anfrage mit high gehören. Sichtbares Thinking beweist keine hohe Stufe. Führen Sie /reasoning ohne Argument aus, um den aktuellen Effort und den Anzeigestatus getrennt zu lesen.

Sitzung, global oder pro Modell: welcher Scope passt?

Sitzung: eine konkrete schwierige Aufgabe

Führen Sie in einer aktiven Sitzung aus:

/reasoning high

Standardmäßig gilt die Änderung nur in dieser Sitzung. So erhält ein einzelnes Debugging- oder Architekturproblem mehr Effort, ohne alle künftigen Unterhaltungen zu verändern.

Um Reasoning in der aktuellen Sitzung abzuschalten, verwenden Sie:

/reasoning none

Das funktioniert nur, wenn Modell und Route eine Abschaltung zulassen. Der Provider kann Reasoning erzwingen, den Wert anders abbilden oder ablehnen; deshalb bleibt der echte Anfrageverlauf entscheidend.

Global: der Standard für den Alltag

Mit --global speichern Sie den Wert für neue Sitzungen:

/reasoning medium --global

Hermes speichert ihn als agent.reasoning_effort. Bei gemischten Aufgaben ist medium meist ein besserer globaler Ausgangspunkt als die Maximalstufe; erhöhen Sie nur die Sitzungen, die es wirklich benötigen.

Lesen Sie die gespeicherte Konfiguration im Terminal:

hermes config path
hermes config get agent.reasoning_effort
hermes config check

Ein erfolgreicher config get zeigt, dass Hermes einen Konfigurationswert aufgelöst hat. Er beweist nicht allein, dass der Provider ihn unverändert angenommen und ausgeführt hat.

Pro Modell: stabile Standards beim Wechsel

Wenn Sie regelmäßig zwischen einem schnellen und einem tiefer schlussfolgernden Modell wechseln, bearbeiten Sie config.yaml:

agent:
  reasoning_effort: "medium"
  reasoning_overrides:
    "custom/example-fast-model": "low"
    "custom/example-deep-model": "high"

Eine passende Modellregel hat Vorrang vor dem globalen agent.reasoning_effort. Verwenden Sie möglichst die genaue model ID aus Ihrer Hermes-Konfiguration. Starten Sie nach der Änderung eine neue Sitzung, wählen Sie das Zielmodell und führen Sie /reasoning erneut aus.

Die Regelkarte lesen Sie mit:

hermes config get agent.reasoning_overrides --json

Model IDs enthalten häufig Punkte und Schrägstriche. Direktes Bearbeiten der YAML-Datei ist übersichtlich; wenn Sie mit hermes config set einen neuen Schlüssel mit Punkten anlegen, beachten Sie die Regeln für literale Punkte in der CLI-Referenz.

Priorität: warum eine globale Änderung scheinbar nichts bewirkt

Für das ausgewählte Modell gilt als Denkmodell diese Reihenfolge:

1. die temporäre /reasoning-Wahl der aktuellen Sitzung;
2. ein passender Eintrag in agent.reasoning_overrides;
3. der globale agent.reasoning_effort;
4. der Standard des Modells oder Providers.

Steht global low, während /reasoning weiterhin high meldet, prüfen Sie zuerst eine aktive Sitzungswahl oder Modellregel. Kontrollieren Sie auch nach einem /model-Wechsel erneut, weil das neue Modell eine andere Regel treffen kann.

Immer dieselbe prüfbare Aufgabe verwenden

Testen Sie nicht eine Stufe mit einer trivialen Überarbeitung und eine andere mit einem schwierigen Fehler. Dann messen Sie unterschiedliche Aufgaben statt des Effort. Das folgende kleine Beispiel lässt sich von Hand prüfen und benötigt keine Tools:

Die Funktion soll sich überschneidende oder berührende geschlossene Ganzzahlintervalle zusammenführen, ohne bereits abgedeckten Bereich zu verkleinern.
Finde ein minimales Gegenbeispiel, nenne erwartete und tatsächliche Ausgabe, liefere die kleinste Codekorrektur und drei Regressionstests.
Verwende keine Tools. Gib ausschließlich JSON mit den Schlüsseln counterexample, expected, actual, fix und tests zurück.

def merge_ranges(ranges):
    ranges = sorted(ranges)
    merged = []
    for start, end in ranges:
        if not merged or start > merged[-1][1] + 1:
            merged.append([start, end])
        else:
            merged[-1][1] = end
    return merged

Der zentrale Fehler tritt auf, wenn ein späteres Intervall vollständig im aktuellen liegt: Das Zuweisen des kleineren Endes verkleinert den abgedeckten Bereich. Bewerten Sie fünf objektive Kriterien statt des Stils:

1. gültiges JSON ohne zusätzlichen Text;
2. ein enthaltenes Intervall als Gegenbeispiel, das den Fehler wirklich auslöst;
3. korrekte Werte für expected und actual;
4. eine minimale Korrektur, die das größere Ende erhält;
5. Tests für enthaltene, angrenzende und getrennte Intervalle.

Manueller Vergleich

Verwenden Sie für jede Kandidatenstufe eine neue Sitzung. Model ID, Provider, Arbeitsverzeichnis, Kontext, Tool-Einstellungen, Aufgabentext und Ausgabeformat bleiben gleich. Ein Lauf genügt zur Vorauswahl; wenn die Entscheidung einen häufigen Standard verändert, führen Sie für jeden Finalisten mindestens drei saubere Läufe aus, damit eine Zufallsschwankung nicht als stabiler Vorteil gilt.

Dokumentieren Sie:

Feld	Erfassung
Effort	Vor der Aufgabe /reasoning ausführen und den gemeldeten Wert speichern
Qualität	Die objektive Skala von 0 bis 5 verwenden
Latenz	Reale Zeit vom Absenden bis zur vollständigen Antwort
Modell und Provider	Im Hermes-Status und im Provider-Anfrageverlauf bestätigen
Echte Nutzung	API-Verlauf oder Abrechnungsdetails des Providers verwenden
Auffälligkeiten	Timeout, Retry, Fallback, Fehler oder Modellwechsel markieren

Mischen Sie einen Lauf mit Retry oder Fallback nicht mit sauberen Läufen. Dabei können sich Modell, Zahl der Aufrufe, Latenz und Token-Verbrauch gleichzeitig ändern, sodass der Einfluss des reasoning effort nicht isoliert wird.

Lokalen Hermes-Bericht mit --usage-file speichern

Für einen maschinenlesbaren Vergleich ändern Sie vorübergehend die globale Stufe und führen dieselbe One-shot-Aufgabe aus:

hermes config set agent.reasoning_effort low
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-low-usage.json > ./hermes-low-output.txt

hermes config set agent.reasoning_effort medium
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-medium-usage.json > ./hermes-medium-output.txt

hermes config set agent.reasoning_effort high
hermes -z "Review the supplied merge_ranges function and return the requested JSON only." --usage-file ./hermes-high-usage.json > ./hermes-high-output.txt

Im echten Vergleich übergeben Sie bei allen drei Läufen denselben vollständigen Aufgabentext statt der verkürzten Zeile. Stellen Sie vorher sicher, dass keine Modellregel den globalen Wert überdeckt. Stellen Sie anschließend den ursprünglichen Wert wieder her. War er vorher nicht gesetzt, verwenden Sie:

hermes config unset agent.reasoning_effort

Andernfalls setzen Sie den notierten Ursprungswert erneut.

Der Hermes-JSON-Bericht kann input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, reasoning_tokens, total_tokens, api_calls, model, provider und estimated_cost_usd enthalten. Die obersten Zähler decken den main agent loop ab. Hilfsaufrufe wie Titelerzeugung, vision oder compression stehen getrennt unter auxiliary; die lokale Gesamtsumme liegt in total_including_auxiliary.

Drei Grenzen müssen klar bleiben:

• estimated_cost_usd ist eine lokale Schätzung, nicht die Provider-Rechnung;
• liefert der Provider eine Token-Kategorie nicht, beweist ein fehlendes Feld keinen Nullverbrauch;
• bei Retry oder Fallback müssen die echten Aufrufe und Modelle im Provider-Verlauf geprüft werden.

Vier Arten von Nachweisen getrennt prüfen

Eine brauchbare Prüfung hält vier verschiedene Dinge fest:

1. Konfiguration zurücklesen: hermes config get und config.yaml enthalten den gewünschten Wert. Das belegt, was Hermes gespeichert und aufgelöst hat, nicht was der Provider angenommen hat.
2. Tatsächlich gesendeter oder gemappter Effort: Wählen Sie das Zielmodell und führen Sie /reasoning aus. Wenn der Status sends ... on this route anzeigt oder die Route einen Trace der ausgehenden Anfrage bereitstellt, prüfen Sie, ob der an die API gesendete Wert dem erwarteten Mapping entspricht. Die Thinking-Anzeige bleibt eine separate Darstellungsoption.
3. Empfang, Annahme oder Ausführung beim Provider: Verwenden Sie einen serverseitigen Anfrageeintrag, einen zurückgespiegelten Wert oder eine ausdrückliche Annahme-/Ausführungsbestätigung nur, wenn Route oder Provider dies tatsächlich bereitstellen. Ein Erfolgssignal ist, dass der serverseitig erfasste Parameter dem gesendeten/gemappten Wert entspricht und kein Reject, Retry, Fallback oder weiteres Herabstufen verzeichnet ist. Ein Payload-Trace belegt den Empfang, nicht die Ausführung; verlangen Sie kein Feld, das der Provider nicht anbietet.
4. Nutzung und Ergebnis: Erfassen Sie das tatsächliche Modell, Ausgabequalität, Latenz, Token-Kategorien, API-Aufrufe sowie berechnete oder geschätzte Kosten. Diese Daten können Route und echte Nutzung belegen, aber nicht den vom Provider angenommenen Effort; aus der Zahl der reasoning Token lässt sich die Stufe nicht zurückrechnen.

Diese Nachweise ersetzen einander nicht. Zeigt der Provider-Verlauf nur Modell, Token, Aufrufzahl oder Ausgaben und legt den Effort nicht offen, lautet die belastbare Aussage: Ausgabe, Latenz und echte Nutzung wurden unter den protokollierten Einstellungen verglichen, die vom Provider angenommene Stufe konnte aber nicht bestätigt werden.

Wenn none scheinbar nicht gespeichert wird

Ein öffentlicher GitHub-Issue vom 5. Oktober 2026 berichtete, dass hermes config set agent.reasoning_effort none auf den vom Autor genannten main-Commits YAML null speichern konnte, während /reasoning none --global die Zeichenfolge none speicherte. Das ist ein versionsgebundener Nutzerbericht. Er beweist weder, dass Ihre aktuelle Version betroffen ist, noch dass eine spätere Version das Verhalten behoben hat.

Prüfen Sie in dieser Reihenfolge:

1. /reasoning none --global ausführen;
2. hermes config get agent.reasoning_effort ausführen;
3. die von hermes config path genannte Datei öffnen und bestätigen, dass die Zeichenfolge none statt eines leeren Werts oder null gespeichert ist;
4. eine neue Sitzung starten und /reasoning erneut ausführen;
5. wenn Route oder Provider einen serverseitigen Anfrageeintrag, einen zurückgespiegelten Wert oder eine ausdrückliche Bestätigung bereitstellen, vergleichen Sie den gesendeten/gemappten Wert mit dem empfangenen oder angenommenen; enthält der Verlauf nur Modell, Token oder Ausgaben, halten Sie fest, dass sich der angenommene Effort nicht bestätigen lässt, statt ihn abzuleiten.

Verlangt das Modell Reasoning, lässt es sich möglicherweise nicht abschalten. Verwenden Sie dann die niedrigste von der Route akzeptierte Stufe, statt wiederholt die Anzeige umzuschalten.

OpenAI-kompatibler eigener Provider

Das tatsächliche Verhalten hängt von Hermes, Modell und Provider ab. Als Beispiel verlangt der aktuelle BetterToken-Leitfaden für Hermes die eigene API Key, die Base URL https://www.bettertoken.ai/v1 und die genaue model ID aus dem Katalog; danach soll die Verbindung zuerst mit einer kurzen Anfrage geprüft werden. BetterToken garantiert weder, dass jedes Modell alle Reasoning-Stufen unterstützt, noch dass eine höhere Stufe jede Aufgabe verbessert.

Unabhängig vom Provider gehören model ID, Anfrageverlauf und echte Nutzung in dieselbe Vergleichstabelle. Sonst kann ein unbemerkter Wechsel von Modell, Route oder Abrechnungspfad wie ein Effekt des reasoning effort aussehen.

Die niedrigste Stufe wählen, die Ihr Qualitätsziel erreicht

Behalten Sie medium als globale Basis, verwenden Sie Sitzungswerte für gelegentliche schwierige Aufgaben und setzen Sie high, xhigh oder höhere Modellregeln erst, wenn wiederholte Vergleiche derselben Aufgabe einen stabilen Gewinn zeigen. Senken Sie mechanische Aufgaben nur auf low, minimal oder none, wenn die Qualität über Ihrem Grenzwert bleibt und sich gemessene Latenz oder echte Nutzung wie erwartet verbessern. Prüfen Sie ein sends-Mapping oder einen Annahme-/Ausführungsnachweis des Providers, wenn die Route ihn offenlegt; andernfalls benennen Sie die Beweisgrenze und behandeln Token oder Ausgaben nicht als Nachweis der angenommenen Stufe.

Der nützliche Standard ist nicht die theoretisch stärkste Stufe. Es ist der niedrigste Effort, der auf Ihrem Modell und Ihrer Route das Qualitätsziel bei akzeptabler Latenz und echter Nutzung zuverlässig erreicht.