Un « régime d'outils » en toute discrétion : 6 définitions d'outils allégées, de 17 % à 44 % de tokens économisés par appel

Avez-vous déjà fait le calcul ? Chaque fois que vous demandez à Hermes d’appeler un outil, le modèle doit relire de zéro « à quoi ressemble cet outil » — paramètres, formats, pièges, le tout détaillé dans une définition JSON qui voyage avec chaque requête. Plus votre session est longue et plus vos appels d’outils sont fréquents, plus ce coût fixe grossit. Entre le 27 et le 28 août, les mainteneurs ont fusionné six PR qui font exactement la même chose : alléger les définitions JSON des outils. process est passé de 306 à 228 tokens (−25 %), todo de 323 à 232 (−28 %), read_file de 426 à 244–269, skill_manage de 517 à 427 (−17 %), video_generate d’environ 814 à 458/377, et browser_exec de 803 à 663 (−17 %) — avec zéro changement de comportement pour l’ensemble.

Pourquoi il vaut la peine d’alléger les définitions d’outils

Construisons d’abord un modèle intuitif. Quand Hermes appelle un outil, la requête doit inclure le schema JSON de cet outil : description (ce qu’il fait), parameters (le nom, le type et les contraintes de chaque paramètre), les enums et les avertissements. Cette définition voyage avec chaque requête — ce n’est pas un coût unique ; elle est renvoyée à chaque tour de votre conversation.

Si la définition d’un outil A pèse 300 tokens et que vous l’appelez 50 fois dans une session, cette seule définition brûle 15 000 tokens. Hermes embarque des dizaines d’outils intégrés, et quelques définitions lourdes (comme les 800+ tokens de browser_exec) sont une « taxe cachée » tapie dans chaque requête. Cette vague cible exactement ces sources de taxe — méthodiquement, sous la campagne #95681.

Le principe : enseigner chaque fait une seule fois

L’idée centrale de cette vague tient en une phrase : supprimer les enseignements dupliqués, garder les vrais pièges. En détail :

1. L’enum EST la liste des verbes (#97279 process, 306→228, −25 %)

La description de process ré-énumérait les 8 actions (list, kill, submit…) avec une phrase d’explication chacune. Désormais : les verbes qui vont de soi (list, kill) n’ont plus rien ; ceux qui sont mécaniques gardent une clause chacun ; les parties vraiment délicates reçoivent plus d’emphase — comme le piège write-vs-submit : « submit ajoute Entrée — utilisez-le pour répondre aux prompts ; write envoie des octets bruts, sans newline. Sur un PTY Windows, un \n isolé n’est pas un terminateur de ligne ; le prompt ne revient jamais, en silence. »

2. Ce que le schema de paramètres enseigne déjà n’est pas ré-enseigné en prose (#97257 todo, 323→232, −28 %)

La description de todo détaillait la structure des items ({id, content, status}) en prose — quatre lignes au-dessus du schema JSON identique. La prose dupliquée a disparu ; le schema est la seule source structurelle. Les règles porteuses de sens survivent toutes : énumérer chaque instance pour les tâches « tous les N items », UN item in_progress, complété seulement après vérification (jamais sur intention), annuler-et-réviser en cas d’échec.

3. Des capacités annoncées à la demande (#97195 read_file, 426→244–269 ; #97095 video_generate, ~814→458/377)

La liste des formats de read_file est désormais générée dynamiquement selon les capacités : c’est la présence de l’extension anydoc dans votre installation qui décide des formats annoncés ; les formats absents ne sont pas annoncés du tout, et le message d’erreur vous apprend à les activer. video_generate va plus loin : il montrait 10 paramètres statiques à chaque session, dont quatre s’excusaient d’eux-mêmes (« ignorés par les providers qui ne les supportent pas »). Désormais seuls les paramètres que le backend actif honore réellement sont rendus — negative_prompt, audio, seed, upscale n’apparaissent que sur les backends qui déclarent les supporter.

4. Déduplication inter-outils (#97152 skill_manage, 517→427, −17 %)

Le mécanisme de patch de skill_manage utilise la même sémantique de recherche-et-remplacement floue que l’outil patch (unicité sauf replace_all, contexte pour l’unicité, doit différer) — enseignée deux fois auparavant. skill_manage dit désormais « mêmes règles de correspondance que l’outil patch » et ne garde que les faits propres au skill (new_string vide supprime). Il corrige aussi une vraie ambiguïté : file_path est désormais explicitement « relatif au répertoire du skill lui-même, ex. ‘references/api.md’ — pas de slash de tête, jamais absolu ».

5. Les chiffres parlent (#96300 browser_exec, 803→663, −17 %)

Le régime précédent de browser_exec incluait une vérification A/B : le schema allégé atteignait la parité de précision avec l’original tout en économisant 140 tokens par appel.

Ce que cela change pour vous

  • De l’argent économisé : c’est une réduction du coût fixe par appel — plus votre session est longue et plus il y a d’appels d’outils, plus vous économisez ;
  • Plus fiable : des schemas plus petits réduisent le coût de compréhension pour le modèle et diminuent les appels mal paramétrés ;
  • Une mise à jour sans friction : tous les changements sont « zéro changement de comportement », avec des tests de contrat qui épinglent chaque enseignement conservé — pas de « l’outil est devenu plus bête après la mise à jour ».

Note : ces changements ont été fusionnés du 27 au 28 août et vivent actuellement sur main en amont, pas encore dans un tag de release. Dès que vous faites hermes update vers un build qui les contient, ils prennent effet automatiquement — rien à configurer.

Pour aller plus loin