Wer mit lokalen LLMs und Coding-Agenten arbeitet, kennt irgendwann dieses Problem: Die Session läuft. Der Agent arbeitet. Es werden Dateien geändert, Entscheidungen getroffen, Fehler analysiert und wieder behoben. Und irgendwann ist das Kontextfenster voll.
Dann beginnt das Vergessen.
Eine Entscheidung, die in Turn 3 getroffen wurde, kann in Turn 40 schlicht verschwunden sein. Compaction hilft dabei, die Session weiterzuführen. Aber eine Zusammenfassung ist immer eine Zusammenfassung. Irgendetwas geht verloren.
Für mich war irgendwann klar: Der Kontext darf nicht der Ort sein, an dem Wissen dauerhaft lebt.
Genau hier kommt Hermes ins Spiel.
Mein Stack — ganz lokal
Ich arbeite dabei komplett lokal. LM Studio stellt meine Modelle bereit. Mein Standardmodell ist aktuell qwen3.8-27b, dazu kommen kleinere Modelle für andere Aufgaben.
Dazwischen sitzt mein MANTIS-LLM-Gateway. Ein kleiner OpenAI-kompatibler Proxy auf FastAPI-Basis. Er vereinheitlicht die Provider-Endpunkte, übernimmt Key-Rotation und hält die Modellliste synchron.
Für den Client gibt es dadurch genau einen stabilen Endpoint.
Als Client läuft OpenCode in VS Code. In meiner opencode.json ist für jedes Modell die jeweilige Kontextgröße definiert. Genau diese Information braucht Hermes, um abschätzen zu können, wie weit die aktuelle Session bereits fortgeschritten ist.
Pro Projekt starte ich einen neuen OpenCode-Chat. Dadurch entsteht in LM Studio eine neue Chat-ID. Saubere Trennung. Keine alten Gesprächsreste. Keine Session, die über Wochen immer weiter wächst.
Das eigentliche Problem
Das Problem ist nicht einmal unbedingt, dass ein LLM Dinge vergisst. Das Problem ist, dass wichtige Entscheidungen häufig nur im Kontext existieren.
„Warum haben wir das eigentlich so gebaut?“
Wenn die Antwort darauf irgendwo 30.000 Tokens weiter oben steht, ist sie irgendwann nicht mehr zuverlässig verfügbar. Genau das habe ich bei einem fremden Repository erlebt: Ein offenes Issue beschäftigte sich mit einem „Decision-Leck“. Eine wichtige Entscheidung war im Verlauf getroffen worden, aber nie dauerhaft dokumentiert worden.
Der Kontext wusste es einmal. Das Repository wusste es nicht.
Für einen Coding-Agenten ist das gefährlich. Denn eine neue Session kann dann durchaus wieder eine alte Entscheidung infrage stellen, obwohl diese bereits bewusst getroffen wurde.
Hermes: Checkpoints statt Amnesie
Hermes ist meine kleine OpenCode-Pluginschicht, die genau dieses Problem adressiert. Das Plugin ist bewusst klein gehalten. Rund 250 Zeilen TypeScript reichen aus, um die Session zu überwachen und bei definierten Schwellenwerten ein AAMS-Checkpoint-Ritual auszulösen.
Die aktuelle Kontextfüllung wird dabei gegen die für das Modell konfigurierte Fenstergröße gesetzt:
| Füllung | Checkpoint | Was passiert |
|---|---|---|
| ≥ 70 % | SOFT | Dateiprotokoll und offene Entscheidungen ins Workpaper |
| ≥ 85 % | HARD | Whitepaper aktualisieren, Langzeit-Memory pflegen, Diary-Eintrag schreiben |
| ≥ 90 % | HANDOFF | Exakten Resume-Punkt dokumentieren und Session beenden |
Die entscheidende Idee dahinter ist eigentlich ganz einfach:
Session = Kontext-Fenster. Workpaper = Task.
Das Kontextfenster ist flüchtig. Das Workpaper lebt weiter.
Wenn Hermes bei 90 Prozent einen Handoff schreibt, beginnt die nächste Session nicht wieder bei null. Sie beginnt mit dem dokumentierten Zustand der vorherigen Session.
Und dann kommt Compaction
OpenCode selbst besitzt inzwischen einen Hook für den Compaction-Prozess. Damit kann ein Plugin zusätzlichen Kontext in die Compaction einbringen, bevor OpenCode daraus die Fortsetzung der Session erzeugt.
Hermes sitzt genau an dieser Stelle nicht als Ersatz, sondern als zusätzliche Sicherung. Bevor der Kontext komprimiert wird, soll das wichtige Wissen bereits außerhalb des flüchtigen Gesprächsverlaufs stehen.
Ich möchte nicht darauf vertrauen, dass eine spätere Zusammenfassung die richtige Entscheidung rekonstruiert. Ich möchte, dass die Entscheidung vorher dokumentiert wurde.
Dazu kommen Anti-Loop-Schutz und ein State-File. Ein Schwellwert wird pro Session nur einmal ausgelöst. Die Zustände landen in WORKING/LOGS/ und bleiben damit nachvollziehbar.
AAMS: der Vertrag darüber
Hermes funktioniert nicht isoliert. Darunter liegt AAMS — eine Spezifikation für den dauerhaften Zustand eines Agentenprojekts. Sie definiert die Struktur, in der ein Projekt seinen Zustand ablegt:
Workpaper
Aktueller Task und Arbeitszustand.
Whitepaper
Stabile Architektur- und Projektwahrheit.
Diary
Chronologisches Entscheidungstagebuch.
Memory
Langfristig relevantes Wissen.
Damit entsteht eine klare Trennung:
Der Chat ist nicht das Gedächtnis.
Der Chat ist der Arbeitsraum. AAMS ist der dauerhafte Zustand. Hermes ist die Brücke zwischen beiden.
Wichtig ist dabei auch die Abgrenzung: Hermes ist keine Erweiterung der AAMS-Spezifikation selbst. Es ist meine lokale Anpassung für OpenCode.
Einordnung, die mir wichtig ist: AAMS ist heute eine Spezifikation — kein etablierter Standard. Zum Standard wird sie, wenn Teams sie in echter Projektentwicklung zuverlässig einsetzen — oder wenn Unternehmen sie für ihre Agenten-Projekte verlangen. Bis dahin soll sie leicht einsetzbar und offen bleiben.
Die Sidecar-Variante habe ich beim AAMS-Upstream bewusst zur Diskussion gestellt: Issue ogerly/AAMS#53 beschreibt genau diesen Ansatz. Die Idee ist dort als optionales, beschreibendes Pattern interessant — nicht als verpflichtender Bestandteil der Spezifikation. Das finde ich richtig.
Diskutieren, Fragen und Updates laufen über die Discussions im AAMS-Repo. AAMS soll offen bleiben. Hermes darf dagegen genau auf meinen lokalen Workflow zugeschnitten sein.
Was sich dadurch verändert
Seit Hermes läuft, sehe ich den Kontext nicht mehr als etwas, das ich möglichst groß machen muss. Selbst ein riesiges Kontextfenster löst das grundsätzliche Problem nicht. Denn irgendwann ist auch dieses Fenster voll.
Entscheidend ist deshalb nicht nur, wie viel das Modell gleichzeitig sehen kann. Sondern:
Was bleibt erhalten, wenn es das nicht mehr sehen kann?
Mit Hermes landen Entscheidungen nicht mehr nur im Gespräch. Sie landen dort, wo die nächste Session sie wiederfinden kann.
Und genau deshalb gefällt mir dieser kleine Satz inzwischen ziemlich gut:
Das Kontextfenster ist flüchtig. Der Task nicht.