Hast du schon einmal einen Chat von Montag bis Freitag offen gehalten, zugesehen, wie der Kontext mit jeder Antwort schwerer und teurer wurde – und Hermes trotzdem nie klüger wirkte oder sich nicht einmal an die Vorliebe erinnerte, die du ihm letzte Woche mitgeteilt hattest? Ein Entwickler hat diese Woche seine eigene Version dieser Geschichte geteilt (I think I used the Hermes Agent wrong), und seine Schlussfolgerung verdient einen genaueren Blick: Das Problem könnte schlicht sein, dass er fast nie eine Session beendete.

Mit Hermes auf einem Raspberry Pi und Telegram kam er mit nur 5 Sessions über 18 Tage – jeden Abend fuhr der Pi herunter, jeden Morgen setzte Hermes still die vorherige Session fort. Das Ergebnis: Über 1.990 Nachrichten hinweg nutzte Hermes session_search (das Tool zum Abrufen über Sessions hinweg) proaktiv nur 9-mal, und die Memory-Dateien veränderten sich kaum. Der Grund ist nicht, dass der Agent dümmer wurde. Alles Wichtige lag noch im Kontextfenster, also gab es nichts zu erinnern. Das Langzeitgedächtnis von Hermes ist allerdings ausdrücklich um die Annahme herum gebaut, dass Sessions enden.

Wie das Gedächtnis von Hermes wirklich funktioniert

Hermes hält zwei Arten von persistentem Gedächtnis vor – wer beide versteht, weiß auch, warum Grenzen wichtig sind.

Die notizbasierten Erinnerungen über Sessions hinweg: MEMORY.md und USER.md. Jedes Profil enthält diese Textdateien (plus optional SOUL.md): USER.md speichert Fakten über dich, MEMORY.md Notizen und Vorlieben, die Hermes gesammelt hat. Zu Beginn einer neuen Session werden beide Dateien in den Kontext injiziert, sodass Hermes „weiß“, wer du bist und was es gelernt hat. Aber sie sind in der Größe begrenzt – die Defaults im Quellcode sind memory_char_limit: 2200 und user_char_limit: 1375, grob 800 beziehungsweise 500 Token. Nahe am Limit muss Hermes sein Memory-Tool einsetzen, um zusammenzuführen, zu kürzen und zu priorisieren – und das Wichtigste zu behalten.

Der vollständige Gesprächs-Speicher: state.db. Jede Nachricht liegt in einer lokalen SQLite-Datenbank. session_search ist das Tool, mit dem Hermes außerhalb der aktuellen Session nachschauen kann – „Wie habe ich diesen CI-Fehler letztes Mal behoben?“ Das ist die andere Hälfte des Designs: Wenn der Kontext nicht alles fassen kann, holt der Abruf alte Details zurück.

Und wann wird geschrieben? Neben der expliziten Memory-Tool-Nutzung mitten im Gespräch führt Hermes eine background review aus: Nach einem Turn geht es asynchron noch einmal durch die Konversation und destilliert, was sich festzuhalten lohnt – Lektionen, Korrekturen, Vorlieben. Diese Schleife funktioniert nur dann richtig, wenn Sessions natürliche Endpunkte haben: Am Ende ein Bündel festsetzen, beim nächsten Start injizieren – und wieder von vorn.

Was passiert, wenn du nie eine Session beendest

Übertrage dieses Design auf eine einzige 18-Tage-Session, und das Fehlerbild wird offensichtlich:

• Memory-Dateien werden zur Deko. MEMORY.md/USER.md werden beim Session-Start injiziert – in einer Mega-Session steckt ihr Inhalt bereits im Kontext, Hermes braucht die Dateien also nie zum „Erinnern“, und die background review sieht nichts, was sich zu aktualisieren lohnt. Sie veralten still.
• session_search feuert kaum. Das Tool ist für „nicht im Kontext, aber in der Historie“ gedacht. In einer endlosen Session liegt die letzte Woche noch im Fenster, der Abruf hat also nichts zu tun. Neun Einsätze pro 1.990 Nachrichten sind keine Dummheit – es ist ein Tool ohne Aufgabe.
• Kosten und Latenz steigen. Jeder Turn sendet die ständig wachsende Historie erneut an das Modell; die Token-Rechnung skaliert mit der Session-Länge. Nahe der Fenstergrenze greift die Kompression und faltet alte Inhalte in Zusammenfassungen – verlustbehaftete Zusammenfassungen, in denen Details leise verdunsten.
• Die Gedächtnis-Schichtung geht verloren. Die Mega-Session verwischt Kurzzeitkontext und Langzeitgedächtnis zu einem Topf. Sich an alles zu erinnern heißt, sich an nichts präzise zu erinnern: Langlebige Vorlieben, die in eine Notiz gehören, und einmalige Details, die in die Suche gehören – alles köchelt im selben Topf.

Wann neu starten, wann fortsetzen

Die gute Nachricht: Die Regel ist einfach. Läuft die Aufgabe noch?

Setze die Session fort, wenn:

• dieselbe Aufgabe noch nicht abgeschlossen ist – nur pausiert (du bist mitten in einem langen Dokument weggegangen);
• flüchtiger Kontext (ein Dateipfad, der exakte Code, an dem du debugst) im nächsten Schritt gebraucht wird und es sich nicht lohnt, ihn neu zu erklären;
• du in einem Terminal zwischen Aufgaben wechselst und die Historie jedes Strangs intakt bleiben soll.

Starte eine neue Session, wenn:

• die letzte Aufgabe ausgeliefert oder klar erledigt ist – selbst „für jetzt reicht es“ zählt;
• sich das Thema geändert hat und die beiden Aufgaben keinen Kontext teilen, den du mitnehmen musst;
• der Kontext bereits groß ist (beobachte die Token-Nutzung in der Statusleiste oder in Ansichten wie hermes status) und die neue Aufgabe den alten Inhalt nicht brauchen wird;
• du willst, dass Hermes sich dieses Gespräch wirklich merkt – das Beenden gibt der background review die Chance, die Erkenntnisse zu destillieren.

Der richtige Weg zum Wechseln: Bevor du etwas Neues beginnst, bitte Hermes, behaltenswerte Schlussfolgerungen ins Memory zu schreiben, oder archiviere die Konversation mit dem /save-Befehl, den wir früher behandelt haben. Wenn du doch fortsetzt, hält der hermes chat -c-Trick zum Fortsetzen pro Terminal jeden Terminal-Strang auf eigenem Gleis. Und falls Session-Daten je Probleme machen, führt unser Field Guide zu Session-Zwischenfällen durch Diagnose und Wiederherstellung.

Mach Session-Grenzen zur Gewohnheit

Die Geschichte des Entwicklers ist es wert, geteilt zu werden, weil er keinen Bug traf – er traf auf eine Nutzungs-Diskrepanz: Er benutzte ein Memory-System, das für viele Sessions gebaut ist, als wäre es ein einziger endloser Strang. Du musst Sessions nicht nach der Uhr beenden; öffne einfach natürlich eine neue, wenn eine Aufgabe abgeschlossen ist. So können Datei-Injektion, das Festsetzen durch die background review und der Abruf per session_search jeweils ihre Arbeit tun. Sessions mit Grenzen geben dem Gedächtnis einen Kreislauf – und ein Hermes, das sich wirklich an dich erinnert, ist der Grund, warum du es installiert hast.