Hermes reasoning effort : session, réglage global et par modèle

Conserver Hermes au niveau de reasoning maximal n’améliore pas toutes les tâches, et voir du thinking à l’écran ne prouve pas que la requête a utilisé le niveau choisi. Une méthode plus fiable consiste à garder une valeur globale pratique, augmenter temporairement l’effort pour les travaux difficiles, ajouter des valeurs par modèle seulement après des résultats répétés, puis vérifier avec une tâche contrôlable et les relevés réels du fournisseur.

Règle pratique : commencez par medium

Hermes accepte none, minimal, low, medium, high, xhigh, max et ultra. Une valeur non définie est résolue en medium. Un modèle ou une route peut ne prendre en charge qu’une partie de l’échelle : le niveau peut être réduit, traduit, ignoré ou rejeté. Consultez la documentation de configuration Hermes et les enregistrements de requêtes de votre fournisseur.

Type de tâche	Point de départ	Quand changer
Mise en forme, extraction de champs ou réécriture déterministe	low ; essayez minimal ou none seulement après confirmation du support	Passez à medium si des champs ou contraintes manquent
Petite modification de code, question courante ou débogage bien délimité	medium	Testez low après plusieurs réussites ; testez high si des contraintes sont oubliées
Revue à contraintes multiples, diagnostic entre fichiers ou analyse de compromis	high	Testez xhigh ou max seulement si le gain se répète et si l’attente reste acceptable
Planification exceptionnellement difficile	Comparez d’abord high et xhigh	Gardez max ou ultra uniquement si un test contrôlé montre un gain utile

ultra est un échelon interne à Hermes. La route le convertit vers la valeur la plus forte qu’elle peut réellement envoyer ; son nom ne suffit donc pas pour en faire un réglage global.

Afficher le thinking ne change pas le reasoning effort

Ces commandes modifient le reasoning effort de la session actuelle :

/reasoning high
/reasoning none

Celles-ci modifient uniquement l’affichage du thinking :

/reasoning show
/reasoning hide

Un thinking masqué peut correspondre à une requête exécutée en high. Un thinking visible ne prouve pas que le niveau est élevé. Exécutez /reasoning sans argument pour lire séparément l’effort actuel et l’état d’affichage.

Session, global ou par modèle : quel scope choisir ?

Session : une seule tâche difficile

Dans une session active, exécutez :

/reasoning high

Par défaut, le changement ne vaut que pour cette session. C’est la façon la plus sûre d’accorder davantage d’effort à un débogage ou à une décision ponctuelle sans modifier les conversations futures.

Pour demander la désactivation du reasoning dans la session :

/reasoning none

Cela ne désactive réellement le reasoning que si le modèle et la route l’acceptent. Le fournisseur peut l’imposer, traduire la valeur ou la refuser ; il faut donc vérifier la requête réelle.

Global : la valeur quotidienne

Ajoutez --global pour enregistrer la valeur des nouvelles sessions :

/reasoning medium --global

Hermes la persiste dans agent.reasoning_effort. Pour des usages variés, medium est une base plus prudente que le maximum ; augmentez uniquement les sessions qui en ont besoin.

Lisez la configuration depuis le terminal :

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

Un résultat correct de config get prouve qu’Hermes a résolu la valeur. Il ne prouve pas à lui seul que le fournisseur l’a acceptée et appliquée sans modification.

Par modèle : des valeurs stables lors des changements

Si vous alternez régulièrement un modèle rapide et un modèle de reasoning plus profond, modifiez config.yaml :

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

Une règle par modèle correspondante est prioritaire sur agent.reasoning_effort. Utilisez de préférence le model ID exact configuré dans Hermes. Après la modification, ouvrez une nouvelle session, sélectionnez le modèle et exécutez à nouveau /reasoning.

Pour lire la table :

hermes config get agent.reasoning_overrides --json

Les model ID contiennent souvent des points et des barres obliques. L’édition directe du YAML est simple ; si vous créez une clé avec des points via hermes config set, suivez les règles d’échappement des points littéraux de la référence CLI.

Priorité : pourquoi une valeur globale peut sembler ignorée

Pour le modèle sélectionné, retenez cet ordre :

1. le choix temporaire /reasoning de la session actuelle ;
2. une entrée correspondante dans agent.reasoning_overrides ;
3. le agent.reasoning_effort global ;
4. la valeur par défaut du modèle ou du fournisseur.

Si la valeur globale est low mais que /reasoning indique encore high, recherchez d’abord une valeur de session ou une règle par modèle. Vérifiez aussi après /model, car le nouveau modèle peut correspondre à une autre entrée.

Utilisez toujours la même tâche vérifiable

Ne testez pas un niveau sur une réécriture triviale et un autre sur un bug difficile : vous mesureriez la différence entre les tâches. L’exemple suivant a une réponse vérifiable et ne nécessite aucun outil :

La fonction doit fusionner les intervalles entiers fermés qui se chevauchent ou se touchent, sans réduire une couverture existante.
Trouvez un contre-exemple minimal, donnez la sortie attendue et la sortie réelle, proposez la plus petite correction de code et ajoutez trois tests de régression.
N’utilisez aucun outil. Retournez uniquement du JSON avec les clés counterexample, expected, actual, fix et tests.

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

Le défaut principal apparaît lorsqu’un intervalle ultérieur est entièrement contenu dans l’intervalle courant : affecter une fin plus petite réduit la couverture. Notez cinq critères objectifs plutôt que le style :

1. JSON valide sans texte supplémentaire ;
2. contre-exemple d’intervalle contenu qui déclenche réellement le défaut ;
3. valeurs expected et actual correctes ;
4. correction minimale qui conserve la plus grande fin ;
5. tests pour les intervalles contenus, adjacents et séparés.

Comparaison manuelle

Utilisez une nouvelle session pour chaque niveau candidat. Gardez identiques le model ID, le fournisseur, le répertoire, le contexte, les outils, le texte de la tâche et le format de sortie. Une exécution suffit pour un tri initial ; si la décision modifie un réglage fréquent, réalisez au moins trois exécutions propres de chaque finaliste afin de ne pas confondre variation aléatoire et gain stable.

Consignez :

Champ	Méthode
Effort	Exécutez /reasoning avant la tâche et conservez la valeur affichée
Qualité	Utilisez l’échelle objective de 0 à 5
Latence	Temps réel entre l’envoi et la réponse finale
Modèle et fournisseur	Confirmez dans le statut Hermes et le relevé du fournisseur
Usage réel	Utilisez le journal API ou le détail de facturation du fournisseur
Anomalies	Notez timeout, retry, fallback, erreur ou changement de modèle

Ne mélangez pas une exécution avec retry ou fallback aux exécutions propres. Elle peut modifier simultanément le modèle, le nombre d’appels, la latence et les Token, ce qui empêche d’isoler l’effet du reasoning effort.

Rapport local avec --usage-file

Pour une comparaison exploitable par une machine, changez temporairement la valeur globale et exécutez la même tâche one-shot :

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

Pour le vrai test, fournissez le même texte complet aux trois exécutions. Vérifiez auparavant qu’aucune règle par modèle ne masque la valeur globale. Restaurez ensuite le réglage original. S’il n’était pas défini :

hermes config unset agent.reasoning_effort

S’il avait une valeur explicite, rétablissez-la.

Le JSON Hermes peut inclure input_tokens, output_tokens, cache_read_tokens, cache_write_tokens, reasoning_tokens, total_tokens, api_calls, model, provider et estimated_cost_usd. Les compteurs de premier niveau couvrent le main agent loop. Les appels auxiliaires, comme la génération de titre, vision ou compression, sont séparés dans auxiliary ; le total local combiné se trouve dans total_including_auxiliary.

Gardez trois limites claires :

• estimated_cost_usd est une estimation locale, pas la facture du fournisseur ;
• si le fournisseur ne renvoie pas une catégorie de Token, un champ absent ne prouve pas une consommation nulle ;
• en cas de retry ou fallback, vérifiez les appels et modèles réels dans le relevé du fournisseur.

Séparez quatre types de preuves

Une vérification utile consigne quatre éléments distincts :

1. Relecture de la configuration : hermes config get et config.yaml contiennent la valeur attendue. Cela prouve ce qu’Hermes a enregistré et résolu, pas ce que le fournisseur a accepté.
2. Effort réellement envoyé ou mappé : après avoir choisi le modèle, exécutez /reasoning. Si l’état affiche sends ... on this route, ou si la route fournit un trace de la requête sortante, vérifiez que la valeur envoyée à l’API correspond au mappage attendu. La visibilité du thinking reste un réglage d’affichage distinct.
3. Réception, acceptation ou exécution côté fournisseur : utilisez un relevé server-side de la requête, une valeur renvoyée ou une confirmation explicite d’acceptation/exécution uniquement si la route ou le fournisseur l’expose réellement. Le signal de réussite est un paramètre server-side identique à la valeur envoyée/mappée, sans rejet, retry, fallback ni réduction supplémentaire. Un payload trace prouve la réception, pas l’exécution ; n’exigez pas un champ que le fournisseur ne fournit pas.
4. Usage et résultat : consignez le modèle réel, la qualité de sortie, la latence, les catégories de Token, les appels API et le coût facturé ou estimé. Ces données peuvent vérifier la route et l’usage réel, mais pas l’effort accepté par le fournisseur ; le nombre de reasoning Token ne permet pas de déduire le niveau.

Ces preuves ne se remplacent pas. Si le relevé du fournisseur montre seulement le modèle, les Token, le nombre d’appels ou la dépense sans exposer l’effort, la conclusion défendable est que vous avez comparé sortie, latence et usage réel sous les configurations consignées, sans pouvoir confirmer le niveau réellement accepté par le fournisseur.

Si none semble ne pas être enregistré

Un issue GitHub public du 5 octobre 2026 a signalé que, sur les commits main cités par son auteur, hermes config set agent.reasoning_effort none pouvait enregistrer YAML null, tandis que /reasoning none --global enregistrait la chaîne none. C’est un rapport utilisateur limité à des versions précises. Il ne prouve ni que votre version actuelle est touchée, ni qu’une version ultérieure a corrigé le comportement.

Vérifiez dans cet ordre :

1. exécutez /reasoning none --global ;
2. exécutez hermes config get agent.reasoning_effort ;
3. ouvrez le fichier indiqué par hermes config path et confirmez que la valeur est la chaîne none, pas une valeur vide ou null ;
4. démarrez une nouvelle session et exécutez à nouveau /reasoning ;
5. si la route ou le fournisseur expose un relevé server-side, une valeur renvoyée ou une confirmation explicite, comparez la valeur envoyée/mappée à celle reçue ou acceptée ; si le relevé ne contient que le modèle, les Token ou la dépense, notez que l’effort accepté ne peut pas être confirmé au lieu de le déduire.

Si le modèle exige du reasoning, il peut être impossible de le désactiver. Utilisez le niveau le plus bas accepté par la route au lieu de modifier sans cesse l’affichage.

Fournisseur personnalisé compatible OpenAI

Le comportement effectif dépend d’Hermes, du modèle et du fournisseur. Par exemple, le guide BetterToken pour Hermes demande de configurer sa propre API Key, la Base URL https://www.bettertoken.ai/v1 et le model ID exact du catalogue, puis de vérifier la connexion avec une courte requête. BetterToken ne garantit pas que chaque modèle accepte tous les niveaux ni qu’un niveau supérieur améliore chaque tâche.

Quel que soit le fournisseur, placez le model ID, le relevé de requête et l’usage réel dans le même tableau. Sinon, un changement involontaire de modèle, de route ou de chemin de facturation peut être pris pour un effet du reasoning effort.

Choisissez le niveau minimal qui atteint votre seuil de qualité

Gardez medium comme base globale, utilisez le scope de session pour les tâches difficiles occasionnelles et ajoutez high, xhigh ou un niveau supérieur par modèle uniquement après plusieurs comparaisons identiques montrant un gain stable. Pour un travail mécanique, baissez vers low, minimal ou none seulement si la qualité reste suffisante et si la latence mesurée ou l’usage réel s’améliorent comme prévu. Vérifiez le mappage sends ou l’acceptation/exécution côté fournisseur lorsque la route l’expose ; sinon, indiquez la limite des preuves au lieu de traiter les Token ou la dépense comme preuve du niveau accepté.

Le bon réglage n’est pas le niveau théoriquement le plus puissant. C’est le plus petit effort qui atteint régulièrement votre objectif de qualité sur votre modèle et votre route, avec une latence et un usage réel acceptables.