Du sitzt eine halbe Stunde an SOUL.md. Du ergänzt zwei neue Regeln in einem Skill. Du startest das Gateway neu, wechselst zurück in die Session, die seit gestern läuft, und bittest sie, die eben erledigte Aufgabe noch einmal zu machen. Sie antwortet in der alten Stimme, folgt den alten Schritten und lässt genau das weg, was du ihr gerade verboten hast. Du öffnest die Konfigurationsdatei dreimal, um sicherzugehen, dass die Änderung wirklich angekommen ist. Am Ende bleibt nur eines: /new — und vierzig Turns Kontext verschwinden.

Die Konfiguration war in Ordnung. Hermes hat sie absichtlich ignoriert, um dir Kosten zu sparen. Inzwischen gibt es einen Befehl, der die Instruktionen aktualisiert, ohne die Unterhaltung anzufassen.

Warum eine laufende Session deine Änderung nicht sieht

Die Provider der Modelle haben einen Kostentrick: Wenn der Anfang jeder Anfrage Byte für Byte identisch ist, kann der Provider seine zwischengespeicherte Berechnung wiederverwenden, statt sie neu zu rechnen. Dieser Prefix ist der system prompt — der Block mit deiner SOUL.md-Persona, dem Skill-Index, den Projektregeln aus AGENTS.md, dem Memory und USER.md.

Damit dieser Prefix stabil bleibt, baut Hermes den system prompt einer Session genau einmal und spielt danach exakt diese Bytes in jedem weiteren Turn wieder ein. Nach einem Neustart des Gateways stellt er die gespeicherte Kopie aus der Session-Zeile wieder her; ein Agent, der im Speicher warmgehalten wird, liest die Dateien überhaupt nicht neu.

Also liest nur eine brandneue Session die Dateien. Alte Unterhaltungen spielen weiter den Prompt ein, mit dem sie geboren wurden — und genau das hast du gesehen.

Der Befehl: hermes sessions refresh-prompts

# jede Session in diesem Profil
hermes sessions refresh-prompts

# nur eine Session (ID oder eindeutiges Präfix)
hermes sessions refresh-prompts --session a1b2c3

# ein anderes Profil
hermes sessions refresh-prompts -p work

# maschinenlesbar, praktisch in einem Update-Skript
hermes sessions refresh-prompts --json

Was er tut, ist bewusst klein: Er vermerkt eine Refresh-Anfrage in der state.db des Profils und gibt aus, wie viele Sessions einen gespeicherten Prompt haben. Die eigentliche Arbeit passiert am Anfang des nächsten Turns jeder Session.

Die Ausgabe sieht so aus:

Requested a system prompt refresh for every session in this profile (12 session(s) with a stored prompt).
Each rebuilds its prompt from the current SOUL.md, skills and context files on its next turn (one prompt-cache miss per session); conversation history is kept.

Mit --session gibt es einen Sonderfall, der für dich abgefangen wird: Eine kompaktierte Unterhaltung läuft an ihrer Spitze weiter, deshalb hängt die Anfrage an dieser Fortsetzung und nicht an der längst abgeschlossenen Wurzel, aus der sie komprimiert wurde.

Was tatsächlich neu gebaut wird

• Neu gebaut: Der gesamte system prompt läuft durch den normalen Builder, das neue SOUL.md, hinzugekommene oder entfernte Skills, AGENTS.md und Context-Dateien wirken also in diesem Turn. Auch die Memory- und USER.md-Blöcke werden neu von der Platte gelesen.
• Unberührt: der Verlauf der Unterhaltung, die Session-ID und die gepinnte Tool-Liste der Session. Der Hook on_session_start feuert nicht, seine Nebenwirkungen laufen also nicht noch einmal.
• Kosten: ein Prefix-Cache-Miss pro aktualisierter Session, und zwar in dem Turn, der neu baut. Spätere Turns laufen wieder aus dem Cache.
• Persistenz: Der neue Prompt und sein Versionsstempel werden in state.db zurückgeschrieben, und jeder spätere Turn spielt sie wortgleich ein. Das ist ein einmaliger Rebuild, keine Ausgabe pro Turn.

Ein Neustart des Gateways ist nicht nötig, und ein Neustart macht die Anfrage nicht zunichte: Sie liegt in der Datenbank, ein Agent, der aus einem Neustart zurückkommt, liest sie also weiterhin. Ein Update-Skript kann den Befehl vor oder nach dem Austausch des Gateways aufrufen.

Woran Hermes erkennt, dass eine Aktualisierung fällig ist

Hermes führt in state_meta des Profils eine fortlaufende Epoche — stell sie dir als Revisionsnummer deiner Instruktionen vor. Jede Session hält in ihrer model_config fest, welche Revision ihr gespeicherter Prompt bereits erfüllt. Am Anfang eines Turns macht der Agent einen einzelnen Point-Read: Ist die gespeicherte Epoche älter, baut er einmal neu; andernfalls tut er nichts.

Ohne vermerkte Anfrage besteht der zusätzliche Aufwand nur in diesem einen Read. Nichts beobachtet Dateien im Hintergrund, und nichts tauscht die Instruktionen mitten in einem Turn aus.

Wann man es nutzen sollte — und wann nicht

Was du gerade geändert hast	refresh-prompts laufen lassen?
SOUL.md, Skills, AGENTS.md, USER.md	Ja — genau dafür ist es gebaut
Nur das Modell oder die Sampling-Einstellungen	Nicht nötig
Tool-Definitionen oder Tool-Berechtigungen	Neue Sessions übernehmen sie; das Tool-Pinning einer bestehenden Session bleibt, wie es war
Du willst zu einem neuen Thema bei null anfangen	Nimm /new; dieser Befehl leert keine Historie
Die Session-Zeile selbst ist beschädigt	Nimm hermes sessions repair-prompts, ein anderer Befehl

Zwei Einschränkungen. Erstens: Ein Refresh spielt keine Historie neu ein und repariert keine kaputte Unterhaltung — er ersetzt nur den Instruktions-Prefix. Zweitens: Wenn du viele lange Sessions fährst und pro Token zahlst, nimm --session: Jede aktualisierte Session zahlt ihren eigenen Cache-Miss, und über Dutzende Unterhaltungen summiert sich das.

Wenn deine Frage stattdessen lautet „warum werden Instruktionen nach einer Kompaktierung veraltet“, ist das ein anderer Mechanismus — Hermes baut den system prompt während der Kompaktierung neu. Die Details stehen in wie die Kompaktierung den Prompt neu baut. Wenn du Skills gerade ins Repository verschoben hast, lies zuerst projektlokale Skills und das Trust-Gate — der Refresh ist nur der Weg, auf dem eine laufende Session aufholt. Und die Mechanik, einen Prefix-Cache über Sessions hinweg zu teilen, steht in profilübergreifendes Prompt-Cache-Sharing. Die vollständige Flag-Referenz findest du auf der Seite zum Befehl hermes sessions.

Release-Status

Der Befehl ist am 29. Oktober 2026 in main gemerged (PR #143581). Das aktuelle Release v0.22.5 (23. Oktober 2026) enthält ihn noch nicht — wenn hermes sessions --help kein refresh-prompts auflistet, läufst du auf einem älteren Build. Installiere von main, um ihn jetzt zu nutzen, oder warte auf das nächste Release.

Dateien bearbeiten, einen Befehl ausführen, und der nächste Turn läuft mit den neuen Instruktionen — ohne dass du dafür eine Unterhaltung opfern musst.