Hast du schon mal die Rechnung gemacht? Jedes Mal, wenn du Hermes bittest, ein Tool aufzurufen, muss das Modell von Grund auf neu lesen, „wie dieses Tool aussieht“ – Parameter, Formate, Stolperfallen, alles in einer JSON-Definition, die bei jedem Request mitreist. Je länger deine Session und je häufiger die Tool-Calls, desto größer wird dieser fixe Overhead. Zwischen dem 27. und 28. August haben die Maintainer sechs PRs gemergt, die alle dasselbe tun: die JSON-Definitionen der Tools verschlanken. process fiel von 306 auf 228 Tokens (−25 %), todo von 323 auf 232 (−28 %), read_file von 426 auf 244–269, skill_manage von 517 auf 427 (−17 %), video_generate von ~814 auf 458/377 und browser_exec von 803 auf 663 (−17 %) – bei null Verhaltensänderung in allen Fällen.

Warum sich das Trimmen der Tool-Definitionen lohnt

Bauen wir zuerst ein intuitives Modell. Wenn Hermes ein Tool aufruft, muss der Request das JSON-Schema des Tools enthalten: description (was es tut), parameters (Name, Typ, Constraints jedes Parameters), Enums und Einschränkungen. Diese Definition reist mit jedem Request mit – sie ist keine einmalige Kosten, sondern wird in jedem einzelnen Turn deiner Konversation neu gesendet.

Wenn die Definition von Tool A 300 Tokens kostet und du es in einer Session 50-mal aufrufst, verbrennt allein diese Definition 15.000 Tokens. Hermes bringt dutzende eingebaute Tools mit, und ein paar schwergewichtige Definitionen (wie browser_exec mit 800+ Tokens) sind eine „versteckte Steuer“, die in jedem Request lauert. Diese Welle zielt genau auf diese Steuerquellen – systematisch, unter Kampagne #95681.

Das Prinzip: jede Tatsache genau einmal lehren

Die Kernidee dieser Welle lässt sich in einem Satz zusammenfassen: doppeltes Lehren löschen, echte Fallstricke behalten. Aufgeschlüsselt:

1. Das Enum IST die Verbliste (#97279 process, 306→228, −25 %)

Die Beschreibung von process listete früher alle 8 Aktionen (list, kill, submit …) mit einem erklärenden Satz pro Aktion auf. Jetzt: Selbsterklärende Verben (list, kill) bekommen gar nichts; mechanische behalten je einen Satz; die wirklich kniffligen Stellen bekommen mehr Betonung – wie die write-vs-submit-Falle: „submit hängt Enter an – damit beantwortest du Prompts; write sendet rohe Bytes ohne Newline. Auf einer Windows-PTY ist ein einzelnes \n kein Zeilenumbruch; der Prompt kehrt still nie zurück.“

2. Was das Parameter-Schema schon lehrt, wird nicht nochmal in Prosa gelehrt (#97257 todo, 323→232, −28 %)

Die Beschreibung von todo buchstabierte die Items-Struktur ({id, content, status}) in Prosa aus – vier Zeilen über dem identischen JSON-Schema. Die doppelte Prosa ist weg; das Schema ist die einzige strukturelle Quelle. Die tragenden Regeln überleben alle: für „alle N Items“-Aufgaben jedes Item aufzählen, genau ONE Item in_progress, completed erst nach verifizierter Erledigung (nie nach Absicht), bei Fehlern cancel-and-revise.

3. Fähigkeiten werden on demand beworben (#97195 read_file, 426→244–269; #97095 video_generate, ~814→458/377)

Die Formatliste von read_file wird jetzt dynamisch nach Fähigkeit erzeugt: Ob deine Installation die anydoc-Erweiterung hat, entscheidet, welche Formate beworben werden; fehlende Formate werden gar nicht beworben, und die Fehlermeldung bringt dir bei, wie du sie aktivierst. video_generate geht weiter: Früher zeigte es jeder Session 10 statische Parameter, von denen sich vier selbst entschuldigten („von Providern ignoriert, die es nicht unterstützen“). Jetzt werden nur die Parameter gerendert, die das aktive Backend tatsächlich honoriert – negative_prompt, audio, seed, upscale erscheinen nur auf Backends, die Unterstützung deklarieren.

4. Dedup über Tools hinweg (#97152 skill_manage, 517→427, −17 %)

Die Patch-Mechanik von skill_manage nutzt dieselbe Fuzzy-Find-and-Replace-Semantik wie das patch-Tool (uniqueness-außer-replace_all, context-für-uniqueness, muss-sich-unterscheiden) – früher zweimal gelehrt. Jetzt sagt skill_manage „gleiche Matching-Semantik wie das patch-Tool“ und behält nur die Skill-spezifischen Fakten (leeres new_string löscht). Es behob auch eine echte Mehrdeutigkeit: file_path ist jetzt explizit „relativ zum eigenen Skill-Verzeichnis, z. B. references/api.md – kein führender Slash, nie absolut.“

5. Zahlen sprechen (#96300 browser_exec, 803→663, −17 %)

Die frühere browser_exec-Diät enthielt eine A/B-Verifikation: Das verschlankte Schema erreichte Genauigkeits-Parität mit dem Original und sparte dabei 140 Tokens pro Call.

Warum das für dich wichtig ist

• Geld gespart: Es ist eine Senkung der fixen Kosten pro Call – je länger deine Session und je mehr Tool-Calls, desto mehr sparst du;
• Zuverlässiger: Kleinere Schemas bedeuten geringere Verständniskosten für das Modell und weniger falsch parametrisierte Calls;
• Upgrade ohne Reibung: Alle Änderungen sind „null Verhaltensänderung“, mit Contract-Tests, die jede behaltene Lehre festnageln – kein „nach dem Upgrade ist das Tool dümmer geworden“.

Hinweis: Diese Änderungen wurden am 27.–28. August gemergt und leben derzeit auf upstream main, noch nicht in einem Release-Tag. Sobald du per hermes update auf einen Build mit ihnen aktualisierst, greifen sie automatisch – nichts zu konfigurieren.

Weiterlesen

• Du willst verstehen, wie Hermes Context abrechnet und komprimiert? Sieh den Guide zur vierstufigen Context-Reduktion;
• Interessiert am neuen Lean-Tail-Kompressionsstandard? Lies den neuen Standard der Kompressionsstrategie;
• Du willst das komplette Tool-Panorama? Schau ins 82-Slash-Commands-Panorama.