Honcho: Speicherinfrastruktur für zustandsbehaftete Agenten
Memory library for building stateful agents
Auf einen Blick
- Was ist das?
- Honcho speichert Nachrichten und Ereignisse, leitet daraus im Hintergrund Peer-Repräsentationen ab und liefert sie als Kontext an beliebige Modelle. Der FastAPI-Dienst lässt sich lokal oder selbst gehostet betreiben, steht unter AGPL-3.0 und ist keine kleine Abhängigkeit.
- Für wen ist es gedacht?
- Wer einem Chat- oder Coding-Agenten ein persistentes Gedächtnis geben will und den Betrieb eines FastAPI-Dienstes samt Datenbank und Hintergrundverarbeitung akzeptiert, findet in Honcho ein Modell, das Gesprächsverläufe nicht nur als Chunks zurückgibt, sondern daraus Aussagen über Peers ableitet.
- Darf ich es kommerziell nutzen?
- Ja, unter strengen Bedingungen. AGPL-3.0 ist eine Lizenz mit Netzwerk-Copyleft: Wenn andere eine veränderte Version über ein Netzwerk nutzen, etwa als gehosteten Dienst, müssen Sie ihnen den Quellcode unter derselben Lizenz anbieten.
- Wird es noch gepflegt?
- Ja. Das Repository hat innerhalb des letzten Tages neue Commits erhalten.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem Honcho adressiert und für wen
Ein Agent, der einen Nutzer über Wochen begleitet, kann nicht bei jeder Anfrage den vollständigen Verlauf mitschicken. Das Kontextfenster ist zu klein, die Kosten steigen mit jedem Turn, und ältere Nachrichten gehen in der Masse unter. Honcho setzt an dieser Stelle an: Nachrichten werden gespeichert, und der Dienst leitet daraus ab, was über einen Peer bekannt ist. Das README beschreibt das Ziel als Infrastruktur für Agenten, die "changing people, agents, groups, projects, and ideas over time" verstehen sollen. Die Zielgruppe ist damit enger gefasst, als der Begriff Memory-Bibliothek vermuten lässt. Angesprochen sind Teams, die bereits einen Agenten betreiben und dessen Verhalten über mehrere Sitzungen hinweg stabilisieren wollen, sowie Entwickler von Coding-Agenten, für die das Projekt Integrationen listet: Claude Code, OpenCode, OpenClaw, Hermes und MCP-Clients. Wer einen einmaligen Chatbot ohne Sitzungsgrenzen baut, bekommt hier mehr Betriebsaufwand als Nutzen.
Peers, Sessions, Messages: das Datenmodell
Die Dokumentation beschreibt vier Ebenen. Ein Workspace enthält Peers. Peers nehmen an Sessions teil. Nachrichten hängen an Sessions. Aus diesen Nachrichten baut Honcho eine Repräsentation pro Peer auf, die sich über die Zeit verändert. Diese Trennung ist der eigentliche Entwurf: Der Nutzer ist nicht die Session, und die Session ist nicht der Workspace. Ein Peer kann in mehreren Sessions auftauchen, und seine Repräsentation wächst über alle hinweg. Das erklärt auch, warum das Projekt von "Multi-peer perspective" spricht: Wenn konfiguriert, modelliert Honcho, was ein Peer über einen anderen weiß. Das ist mehr als eine Speicherschicht, es ist eine Modellierung von Beziehungen. Der Preis dafür ist, dass die Datenbank mehr als eine Tabelle mit Embeddings hält und dass die Konsistenz dieser Repräsentationen von der Hintergrundverarbeitung abhängt.
Der Ablauf: Store, Reason, Query, Inject
Das README nennt vier Schritte. Zuerst werden Konversationen, Ereignisse, Dokumente oder Tool-Traces als Nachrichten auf einer Session gespeichert. Danach verarbeitet Honcho die Warteschlange im Hintergrund und aktualisiert die Peer-Repräsentationen. Anschließend fragt man Kontext, Suchergebnisse, Repräsentationen oder eine natürlichsprachliche Antwort ab. Zuletzt übergibt man das Ergebnis an einen LLM-Aufruf. Entscheidend ist Schritt zwei: Er läuft asynchron. Das bedeutet, dass eine gerade gespeicherte Nachricht nicht sofort in die Repräsentation eingeflossen sein muss. Wer unmittelbar nach dem Schreiben eine Abfrage stellt, kann ein Ergebnis erhalten, das die letzte Nachricht noch nicht berücksichtigt. Das ist kein Fehler, sondern die Folge der Architektur, und es sollte bei der Fehlersuche im Hinterkopf behalten werden. Im Python-Beispiel ruft der Code `session.add_messages([...])` auf und kommentiert den nächsten Schritt mit "happens asynchronously in the background".
Inbetriebnahme: SDK, CLI, Selbsthosting
Drei Wege stehen offen. Der schnellste ist der verwaltete Dienst unter api.honcho.dev, für den man einen API-Schlüssel bei app.honcho.dev erhält. Laut README bekommt man bei der Anmeldung eine Organisation mit eigener Honcho-Instanz und 100 USD Startguthaben. Der zweite Weg ist lokal: `pip install honcho-cli` und anschließend `honcho start --setup`, danach zeigt die SDK auf `http://localhost:8000`. Der dritte Weg ist der FastAPI-Server aus dem Repository, gestartet per Docker Compose oder als lokale Entwicklungsumgebung. Für die Clients gibt es `pip install honcho-ai` und `npm install @honcho-ai/sdk`. Im Python-Code setzt man `workspace_id` und `api_key`; für selbst gehostete Instanzen nennt das README `base_url="http://localhost:8000"` oder die Umgebungsvariable `HONCHO_URL`. Die Konfiguration ist also nicht auf einen Anbieter festgelegt, aber sie ist auch nicht bei null: Wer selbst hostet, muss die Umgebungsvariablen für Datenbank und Modellanbieter selbst setzen.
Abfragen: Chat-Endpunkt und Kontextfenster
Zwei Abfrageformen zeigt das README. Die eine ist eine Frage in natürlicher Sprache an einen Peer: `alice.chat("What learning styles does the user respond to best?")`. Hier liefert Honcho eine Antwort, nicht Rohdaten. Die andere ist der Aufbau von Kontext für einen eigenen Modellaufruf: `session.context(summary=True, tokens=10_000)`. Der Parameter `tokens` begrenzt, wie viel Material zurückkommt, `summary=True` veranlasst eine Zusammenfassung. Das Ergebnis wird über `context.to_openai(assistant=tutor)` in das Nachrichtenformat von OpenAI überführt. Bemerkenswert ist der Parameter `assistant`: Er benennt den Peer, aus dessen Perspektive der Kontext zusammengestellt wird. Wer den Kontext für einen anderen Agenten braucht, muss hier den passenden Peer übergeben, sonst stimmt die Perspektive nicht mit der Rolle überein, die das Modell im Gespräch spielt. Das ist eine kleine Signatur mit großer Wirkung.
Grenzen: asynchrone Verarbeitung, Betriebsaufwand, Lizenz
Die erste Einschränkung steckt im Ablauf selbst. Wer nach dem Speichern sofort eine konsistente Antwort braucht, muss mit Verzögerungen rechnen, weil die Verarbeitung im Hintergrund läuft. Die zweite betrifft den Betrieb. Honcho ist kein Paket, das man in einen Prozess importiert und vergisst. Es ist ein FastAPI-Dienst mit Datenbank und Warteschlange. Wer selbst hostet, übernimmt Updates, Migrationen und die Überwachung der Hintergrundverarbeitung. Die CLI bietet dafür `honcho workspace inspect` und `honcho doctor`, was hilfreich ist, aber den Aufwand nicht aufhebt. Die dritte Einschränkung ist die Lizenz: AGPL-3.0. Wer Honcho als Netzwerkdienst betreibt und Änderungen daran nicht offenlegen will, muss die Vereinbarung mit seinem eigenen Vertriebsmodell prüfen. Das ist keine Rechtsberatung, aber der Punkt gehört vor die Entscheidung, nicht danach. Schließlich: Für reine Ähnlichkeitssuche über Embeddings ist der Apparat zu groß. Wer nur Chunks speichern und wiederfinden will, fährt mit einer Vektordatenbank direkter.
Alternative und Unterschied im Ansatz
Der naheliegende Vergleich ist eine Vektordatenbank wie pgvector oder Chroma, kombiniert mit einem eigenen Prompt-Baukasten. Der Unterschied liegt nicht im Speicher, sondern im Zeitpunkt der Auswertung. Eine Vektordatenbank indiziert Text und gibt bei einer Anfrage die ähnlichsten Abschnitte zurück. Die Interpretation dessen, was diese Abschnitte bedeuten, findet im Prompt statt, also bei jedem Aufruf neu. Honcho verlagert diese Interpretation in einen Hintergrundprozess und schreibt das Ergebnis in eine Peer-Repräsentation. Das ist der Kern des Satzes "Extracts conclusions from conversations and events, not just matching chunks" aus dem README. Der Vorteil: Der Kontext ist kürzer und stabiler, weil die Schlussfolgerung bereits gezogen wurde. Der Nachteil: Man verliert die Kontrolle darüber, wann und wie diese Schlussfolgerung entsteht, und muss dem Dienst vertrauen. Eine Vektordatenbank ist transparent und dumm, Honcho ist undurchsichtig und urteilt. Wer die Kontrolle über jede Ableitung behalten will, sollte bei der Datenbank bleiben.
Wartung, Upgrades und was vorher zu klären ist
Das Repository ist nicht archiviert, der letzte Push datiert auf den 9. September 2026, und das README nennt Server-Version 3.1.2. Abfragbare Releases wurden für diese Einschätzung nicht geliefert, sodass sich das Tempo der Weiterentwicklung und die Stabilität der Schnittstellen zwischen Versionen nicht beurteilen lässt. Wer den Dienst selbst hostet, sollte deshalb vor dem ersten Einsatz klären, wie Migrationen ablaufen und ob ein Upgrade die bestehenden Peer-Repräsentationen neu berechnet. Die Lizenz AGPL-3.0 verlangt bei einer Weitergabe über das Netz die Offenlegung des Quellcodes der eigenen Änderungen; das ist der Punkt, an dem sich entscheidet, ob Selbsthosting überhaupt in Frage kommt. Wer den verwalteten Dienst nutzt, umgeht diese Frage, gibt aber die Kontrolle über die Daten und die Modellwahl aus der Hand. Zwischen diesen beiden Polen gibt es keinen dritten Weg, und genau dort liegt die eigentliche Entscheidung.
Redaktionelles Fazit
Wer einem Chat- oder Coding-Agenten ein persistentes Gedächtnis geben will und den Betrieb eines FastAPI-Dienstes samt Datenbank und Hintergrundverarbeitung akzeptiert, findet in Honcho ein Modell, das Gesprächsverläufe nicht nur als Chunks zurückgibt, sondern daraus Aussagen über Peers ableitet. Wer nur eine Vektordatenbank mit Embeddings braucht, wer keine asynchronen Verarbeitungsschritte einplanen will oder wer die AGPL-3.0 nicht mit seinem Vertriebsmodell vereinbaren kann, sollte es nicht einsetzen. Vor dem ersten Commit lohnt der Blick in die Konfigurationsdatei und in die Migrationsroutine: welche Umgebungsvariablen für Datenbank und Modellanbieter gesetzt werden müssen und ob der Dienst beim Start ausstehende Migrationen selbst ausführt oder ob das ein separater Schritt ist.
Community-Notizen