DisPatch: Eine selbstgehostete Chat-App für lokale KI-Agenten

DisPatch ist die App, die ich entwickelt habe, um nicht mehr eine Installation von 30 Containern des Rocket.Chat-Systems betreiben zu müssen – nur um mit meinen eigenen KI-Agenten zu kommunizieren. Es handelt sich dabei um einen einzigen Python-Prozess sowie eine einzige SQLite-Datei. Jedes Gerät im Haushalt kann darauf zugreifen; die Agenten antworten in Threads, genau wie Menschen es tun. Alles, was ich per Handy hochlade, gelangt auf das System, auf dem die Agenten laufen. Version 2.0.0 wurde am 09.10.2026 veröffentlicht: Das Download-Paket ist eine 3 MB große ZIP-Datei; deren Testsuite bestätigt, dass alle 1.915 Tests erfolgreich verlaufen sind. Auf dieser Seite erfahren Sie, wozu DisPatch dient, wie Antworten exakt einmal auf Ihr Telefon gelangen und wie die PIN-Sperre verhindert, dass Kinder auf Tablets Zugriff auf die Agenten erhalten – Agenten, die ja reale Veränderungen vornehmen können.

Was es kann

Die Screenshots stammen von einer isolierten Testversion mit Dummy-Daten. Die ersten vier Bilder sind aus Version 2.0; die Aufnahmen zum „Sicheren Modus“ sowie zum Dateiserver stammen vom Juli-Update – diese Funktionen funktionieren in Version 2.0 genauso.

• Gesprächsthreads pro Bot auf allen Geräten. Öffnen Sie ein Gespräch auf dem Handy – es ist derselbe Verlauf wie zuvor. Threads lassen sich pinnen, archivieren, umbenennen und durchsuchen.
• Markdown-Antworten in Echtzeit mit syntaxhervorgehobenem Code sowie Kopier-Buttons; Vorschauen für Bilder und Videos per Lightbox; außerdem ist eine installierbare PWA verfügbar.
• Ein interaktives Arbeitsfenster samt „Stopp“-Button. Eine Statuszeile zeigt an, was der Bot gerade tut (Modell lädt, Text schreibt, Werkzeug nutzt). Klicken Sie auf die „Typing-Dots“, um den Denkprozess des Bots zu verfolgen; mit „Stopp“ können Sie den Vorgang abbrechen.
• Standard-Steuerungselemente eines Chat-Apps. „Erneut generieren“ behält vorherige Antworten bei; man kann Nachrichten bearbeiten und erneut ausführen, zitieren, bewerten oder aus dem Kontext entfernen. Pro Thread lässt sich das Modell sowie der Komplexitätsgrad festlegen; ein Füllstandsanzeiger zeigt den verfügbaren Kontextraum an.
• Entwürfe sowie Offline-Outbox. Ungesendete Entwürfe bleiben dem jeweiligen Thread zugeordnet; Nachrichten werden gespeichert und erst versendet, sobald eine Verbindung verfügbar ist.
• Tools und Apps. Ein „Tools“-Button öffnet eigene Projekte direkt in der App: ein statischer Ordner, eine Webseite oder ein vertrauenswürdiges App-Paket mit eigenem Backend sowie Bot. Die „Job Board“-App ist die erste solche Anwendung.
• Zwei Möglichkeiten, einen KI-Bot zu aktivieren. Entweder verknüpfen Sie ihn direkt mit einem Modell-API (LM Studio, Ollama, OpenAI, Anthropic oder jedem OpenAI-kompatiblen Dienst) über die Einstellungen – oder Sie nutzen ein OpenClaw-Gateway für Bots, die Werkzeuge einsetzen und auf dem System agieren.
• Eine Push-API. POST /api/inject ermöglicht es einem Cron-Job oder anderen Agenten, eine Nachricht in einen Thread einzufügen. So erhalte ich beispielsweise morgens automatisch eine Zusammenfassung auf meinem Handy.
• Zweistufige Sicherheitssperre. Ein PIN-Code trennt „vollwertige“ Bots von einer „sichereren“ Auswahl. Mehr dazu unten.
• Host-Dashboard. Anzeige von Systemgesundheit, Speicherplatz, Datenbankintegrität sowie Backup-Status; außerdem eine Checkliste für fehlerhafte Konfigurationen.
• Acht Sprachen inklusive rechts-nach-links geschriebenem Arabisch sowie zehn Themes.
• Lokaler Dateiviewer. Tippen Sie auf einen Dateipfad in einer Nachricht – die Datei öffnet sich direkt in der App, auch auf dem Handy. Voraussetzung ist das Benennen eines Ordners; sensible oder systemrelevante Pfade werden nicht freigegeben.

Bots können außerdem Bilder in einen Thread einfügen. Dazu schreibt der Bot in seine Antwort den Marker [[pic:prompt|caption]]; sofort erscheint ein Platzhalter, der nach der Generierung durch das Bild ersetzt wird. Die Bilder stammen von einer GPU-Maschine im Netzwerk; ist diese nicht verfügbar, zeigt der Platzhalter dies an – ohne stillschweigend zu scheitern.

Der Dateiserver

Dies ist das Feature, das ich am häufigsten nutze. Öffnen Sie DisPatch auf jedem Gerät, ziehen Sie eine Datei hinein – schon landet sie auf dem Server. Die Dateien werden nach Tagen gruppiert angezeigt; bei Bildern und Videos werden Thumbnails gezeigt.

Der Clou ist, dass die Dateien auf demselben Rechner landen, auf dem die Agenten laufen. Ein Foto, das ich vom Handy hochlade, kann Sekunden später von einem Agenten direkt von der Festplatte gelesen werden – sodass ich es beschreiben, archivieren oder auf einer Website veröffentlichen kann, ohne Cloud-Speicher oder Kabel zu benötigen.

Der Code schützt vor offensichtlichen Fehlerquellen:

• Die angegebene Upload-Größe wird vor dem Buffern des Datenstroms durch FastAPI überprüft – so kann ein Handy den Arbeitsspeicher des Servers nicht überlasten.
• Der Gesamtspeicherplatz ist standardmäßig auf 20 GB begrenzt (DISPATCH_FILES_TOTAL_MAX; der Wert 0 deaktiviert diese Begrenzung).
• Jede hochgeladene Datei wird zunächst in eine temporäre Datei geschrieben, anschließend synchronisiert und erst danach umbenannt – so bleibt nach einem Verbindungsabbruch keine unvollständige Datei zurück.
• Bei einem gesperrten Gerät ist nur das Senden von Dateien möglich. Das Gerät kann zwar Dateien versenden, darf aber weder den Inhalt des Dateiservers durchsuchen noch herunterladen.

Warum ich es selbst gebaut habe, anstatt eine bestehende UI zu nutzen

Rocket.Chat funktionierte zwar, aber eine Datenbank sowie zahlreiche Container stellen eine enorme Infrastruktur dar – nur für die Aufgabe „Text senden, Text zurückerhalten und alles synchronisieren“.

Open WebUI und LibreChat sind die üblichen Lösungen für „selbstgehostete KI-Chatsysteme“; sie verstehen sich gut darauf, mit Modellen zu kommunizieren. Meine Anforderungen waren jedoch anders: Ich wollte Agenten, die als Teilnehmer in Threads fungieren können, die im ganzen Haus geteilt werden; außerdem ein Sicherheitsmechanismus, den der Server für Geräte erzwingt, die von Kindern benutzt werden. Zudem brauchte ich einen HTTP-Endpunkt, an den Skripte Daten senden können – sowie Dateien, die an einem Ort landen, wo die Agenten darauf zugreifen können. Genau diese Kombination ist DisPatch. Falls Sie nur eine schöne Oberfläche für ein Modell wünschen, sollten Sie bei den genannten Lösungen starten.

DisPatch erfordert außerdem keinen Build-Schritt. Die Frontend-Implementierung besteht aus reinen JavaScript-Modulen sowie einfachem CSS/HTML – ohne Bundler und ohne npm run build. Meine Ausgangsbedingung war: „Für einen KI-Agenten muss es später leicht modifizierbar sein“ – also: eine Datei bearbeiten, Seite aktualisieren – fertig. Unter diesen Voraussetzungen würde ich dieselbe Entscheidung erneut treffen.

Was ist im Download enthalten?

Die ZIP-Datei heißt dispatch-2026-10.zip; es handelt sich dabei um die DisPatch 2.0.0-Version, bytegenau identisch mit dem v2.0.0-Tag im öffentlichen Repository. Ich habe sie für diese Revision überprüft:

Element	In der ZIP-Datei
Downloadgröße	2.992.647 Bytes (2,9 MB); 319 Dateien, nach dem Entpacken 7,9 MB
SHA-256	e9824d3c13bb3acd2d2eebcf2b162b14ae26eb86f56ca0e4ac8aa20f686a2398
Backend	Python 3.12+, FastAPI + uvicorn; eine SQLite-Datei, verwaltet über uv. Insgesamt 36.501 Zeilen im Verzeichnis backend/app/ (main.py umfasst 12.331 Zeilen); dazu kommen 5.497 Zeilen in der mitgelieferten Job-Board-Anwendung.
Tests	30.726 Zeilen an Python-Tests; pytest meldet 1.915 erfolgreiche Tests; außerdem werden 473 Frontend-Tests unter node --test ausgeführt.
Frontend	Vanilla JavaScript ohne Build-Prozess: etwa 21.000 Zeilen außerhalb der mitgelieferten Bibliotheken und Tests; dazu kommen ca. 9.300 Zeilen an CSS- und HTML-Code.
Mitgelieferte Bibliotheken	marked, highlight.js, DOMPurify. Es werden keine CDN-Aufrufe getätigt.
Daten	Außerhalb des Codes, standardmäßig im Verzeichnis ~/.local/share/local-chat/ (der alte Projektname): Datenbank, config.yaml, security.yaml, Medien, Dateien sowie rotierte Datenbank-Backups.
Lizenz	MIT

Was hat sich seit der 1.0.0-Version vom August geändert?

• Antworten erfolgen nun über den schnellen Weg und gehen nicht verloren. Nachrichten werden jetzt über den bereits geöffneten WebSocket an das Agent-Gateway gesendet – anstatt für jede Nachricht einen neuen openclaw-Prozess zu starten. Dadurch wurde die Antwortzeit pro Nachricht um etwa eine Sekunde reduziert (von 2,26 s auf 1,12 s). Der Text wird sofort übertragen, sobald das Modell ihn generiert. Jede vom Gateway akzeptierte Anfrage wird bis zur endgültigen Verarbeitung nachverfolgt – selbst bei unterbrochener Verbindung oder Server-Neustart kommt die Antwort an.
• Lizenz. Bei Version 1.0.0 galt AGPL-3.0. Am 2026-08-30 wurde das Projekt auf MIT umlizenziert; Version 2.0.0 unterliegt daher der MIT-Lizenz. Die älteren ZIP-Dateien aus Juli und August sind weiterhin an ihren alten Adressen verfügbar – jede enthält außerdem ihre eigene LICENSE-Datei.
• Das Codeterminal wurde entfernt. In Version 1.0.0 gab es ein optionales Browser-Terminal (ein serverseitiger PTY-Stream, der in xterm.js ausgegeben wurde). Ich nutzte es für einen Coding-Agenten, den ich mittlerweile abgeschafft habe; daher entfernt Version 2.0 sowohl das Terminal als auch die dazugehörige Bibliothek. Das DeepSeek Harness-Paneel, das aktiv wird, sobald dsh installiert ist, übernimmt nun diese Funktion – es kann Live-Sitzungen starten, überwachen und beenden.
• Neu: Gesprächssteuerung, Entwürfe sowie Ausgangspostfach; Tools und Apps; Checklisten-Tabellen; ein lokaler Viewer; Markierungen für Bilder; zehn vorgefertigte Themes anstelle des klassischen Hell/Dunkel-Modus; außerdem dezentere Nachrichtenzeilen. Die vollständige Liste findet sich im CHANGELOG.md im Repository.

Einrichtung

Dies ist eine Zusammenfassung aus dem README.md sowie den Dateien in docs/ innerhalb des ZIP-Archivs. Es handelt sich dabei um ein normales uv-Projekt:

unzip dispatch-2026-10.zip
cd DisPatch-2.0.0/backend
uv sync --frozen
uv run pytest -q          # 1,915 passed on my machine
uv run uvicorn app.main:app --host 0.0.0.0 --port 8765

Oder Sie verzichten auf Python: Geben Sie cp .env.example .env && docker compose up -d im obersten Verzeichnis des entpackten Archivs ein. In deploy/systemd/ finden Sie Unit-Dateien für die ständig laufende Version des Programms; außerdem erklärt docs/deploy-bare-metal.md den Schritt, den alle vergessen: loginctl enable-linger. Ohne diesen Befehl wird Ihr Benutzerdienst beendet, sobald Sie die SSH-Sitzung schließen.

• Setzen Sie zuerst einen PIN-Code (Zahnrad-Symbol, anschließend „Sicherheit“). Beide oben genannten Befehle lauschen auf 0.0.0.0; solange kein PIN-Code gesetzt ist, hat jeder in Ihrem Netzwerk vollen Zugriff. Nutzen Sie während der Einrichtung --host 127.0.0.1 (oder BIND_ADDR=127.0.0.1 bei Docker) und leiten Sie den Port nicht an das Internet weiter.
• Bearbeiten Sie die Datei config.yaml im Datenverzeichnis, sodass die Bot-id mit den IDs Ihrer OpenClaw-Agenten übereinstimmen. Die Datei wird neu eingelesen, sobald sie geändert wird.
• Die Einstellungen stammen aus Umgebungsvariablen, die mit DISPATCH_ beginnen; alle sind in .env.example aufgeführt: HOST, PORT, DATA_DIR, AGENT_TIMEOUT (900 Sekunden), MAX_CONCURRENCY (3) sowie GATEWAY_WS.
• DISPATCH_MAX_CONCURRENCY begrenzt die Anzahl der gleichzeitig ausgeführten Agenten. Der Standardwert von 3 schützt einen Rechner, auf dem lokale Modelle laufen. Eine vierte Nachricht muss warten – sie wird jedoch nicht verworfen.

DisPatch liefert OpenClaw nicht mit. Für die Agenten wird ein OpenClaw-Gateway auf demselben Host erwartet. Ohne dieses Gateway startet das Programm dennoch und gibt eine Warnung aus. Threads, die Inject-API, der Dateiserver, der PIN-Schutz sowie die Werkzeuge und direkten Modell-APIs funktionieren trotzdem weiterhin. So führe ich auch Tests mit dem ZIP-Archiv durch: Entpacken, uv sync, freier Port – ohne Gateway.

Wie eine Antwort bei Ihnen ankommt

Der größte Teil der Entwicklungsarbeit galt Fehlerfällen: Wenn die Verbindung mitten in der Antwortabbildung abbricht, der Server während eines laufenden Durchlaufs neu startet oder ein Subagent zehn Minuten später antwortet. Die Übertragungsart wird durch DISPATCH_GATEWAY_WS festgelegt. Ist dieser Wert nicht gesetzt, startet jede Nachricht einen openclaw agent-Prozess, der nach Abschluss die Antwort zurückgibt. shadow stellt eine Verbindung her und protokolliert, was es liefern würde – ohne es tatsächlich zu tun. 1 bedeutet, dass Nachrichten über den Gateway-Socket übertragen werden und die Antworten ebenfalls über diesen Socket fließen. Ich nutze 1. In der ZIP-Datei ist diese Einstellung standardmäßig deaktiviert – somit ändert sich nichts am Empfang der Antworten, bis Sie sie aktivieren.

Wenn der Socket aktiv ist, landet jeder vom Gateway akzeptierte Durchlauf in einer „In-Flight“-Tabelle und wird anschließend mittels des Aufrufs „Warte auf diesen Durchlauf“ abgeschlossen. Selbst wenn die Live-Übertragung unterbrochen wird, kommt die Antwort nach Beendigung des Durchlaufs an; außerdem werden Durchläufe, die zum Zeitpunkt eines Serverabsturzes noch liefen, beim Neustart wieder aufgenommen. Nur solche Durchläufe, die das Gateway nie akzeptiert hat, werden erneut versucht – somit wird nichts doppelt gesendet.

Ein kleiner Hinweis zum Fallback-Mechanismus: Das Transkript-Scannen liest die Sitzungsdateien von OpenClaw aus; neuere OpenClaw-Versionen speichern Sitzungen jedoch in einer Datenbank. In solchen Fällen meldet DisPatch beim Start, dass der dateibasierte Fallback nicht funktioniert – der Socket bleibt somit die einzige Übertragungsmöglichkeit. Das ist ein weiterer Grund, den Socket zu aktivieren.

Unabhängig davon, welcher Weg die Antwort schließlich erreicht: Jeder potenzielle Antworttext durchläuft denselben Verteilungskanal, der prüft, ob er bereits gesendet wurde – somit erscheint eine doppelt gefundene Antwort dennoch nur einmal. Selbst bei Fehlern in der CLI wird das Transkript-Scannen vor dem Abbruch ausgeführt; meist hat das Modell die Antwort bereits in das Transkript geschrieben, bevor der Prozess abstürzte.

Der zweistufige Schutz: Normalmodus vs. Sicherheitsmodus

Der „ungesperrte“ Modus ist keine Spielerei – in diesem Modus können die Agenten Code bearbeiten, Änderungen auf meiner Live-Website vornehmen, Tools ausführen sowie den Rechner verwalten. Im gesperrten Modus hingegen ist nur der allgemeine Chat möglich. Er ist zwar immer noch nützlich für Fragen und Hilfe, doch es sind keine weiteren Aktionen möglich. Da das Familientelefon nicht immer in Erwachsenenhänden ist, erzwingt der Server die Sperre. So verläuft eine Anfrage:

Die Funktion „Geräte merken“ ist standardmäßig deaktiviert; sie muss in den Sicherheitseinstellungen aktiviert werden – anschließend gilt eine Frist von 30 Tagen. Durch Klicken auf „Sperren“ bei einem als vertrauenswürdig gespeicherten Gerät wird dieses vergessen; das Ändern des PIN-Codes löscht alle gespeicherten Geräte. Der Server speichert maximal 10 solcher Geräte. Falls die Datei mit den vertrauenswürdigen Geräten beschädigt ist, gilt kein Gerät mehr als vertrauenswürdig – der PIN-Code funktioniert jedoch weiterhin.

Falls Sie sich selbst aussperren, gibt es zwei Möglichkeiten, wieder Zugang zu erhalten: eine Datei mit Wiederherstellungscode oder das direkte Bearbeiten der Datei security.yaml. Falls security.yaml beschädigt ist, bleibt die App gesperrt – anstatt allen Nutzern im lokalen Netzwerk Zugang zu gewähren. Das war eine bewusste Entscheidung.

Fallstricke

• Das Feld für die Inject-API heißt content. POST /api/inject erwartet {"bot_id": "...", "content": "..."}. Das Senden von reinem text war der häufigste Integrationsfehler – auch bei mir.
• Geben Sie keine sehr langen Nachrichten als CLI-Argument weiter (das ist auch auf dem Fallback-Pfad noch wichtig). Linux begrenzt die Größe eines einzelnen Arguments auf 128 KB (MAX_ARG_STRLEN); eine zu lange Nachricht führt zu einem Fehler vom Typ E2BIG beim Ausführen des Befehls. Der Code schreibt die Nachricht stattdessen in eine temporäre Datei und übergibt --message-file. Vereinfachen Sie das nicht wieder zu einem einfachen Argument.
• Sitzungsschlüssel sind kleinschreibend, Bot-IDs hingegen nicht. OpenClaw wandelt Sitzungsschlüssel in Kleinbuchstaben um; Ihre Bot-IDs können jedoch gemischte Groß-/Kleinschreibung enthalten (Alpha, My_Bot). Bei einer großschreibungs-sensitive Abfrage funktionieren zwar alle anderen Funktionen, doch die Verarbeitung der Sitzungsschlüssel sowie das Zustellen von Antworten versagen stillschweigend. Die Lösung: Zuerst exakte Übereinstimmung prüfen, anschließend auch Kleinbuchstaben akzeptieren.
• Die CLI gibt nur den letzten Textblock zurück. Ohne Socket bleiben alle Aussagen des Bots zwischen den einzelnen Tool-Aufrufen lediglich in dessen Transkript gespeichert. Deswegen existiert der „Transcript-Sweep“-Mechanismus – er greift auch dann noch, wenn das Socket aktiv ist.
• Prüfen Sie das Origin-Feld bei WebSockets. HTTP-Middleware wird für WebSocket-Routen nicht ausgeführt. DisPatch authentifiziert direkt und lehnt Handshakes ab, bei denen der Origin-Host nicht mit dem Host-Wert übereinstimmt; dadurch wird ein Cross-Site-WebSocket-Hijacking verhindert. Nicht-browserbasierte Clients senden kein Origin-Feld und werden somit akzeptiert.
• Stellen Sie hochgeladene SVG-Dateien niemals als Bilder bereit. Ein direkt geöffnetes SVG-File kann Skripte in Ihrem Kontext ausführen – das stellt ein Sicherheitsrisiko dar. DisPatch lehnt SVG-Dateien als Medien ab und liefert solche Dateien nur unter Verwendung von CSP-Sandboxing sowie dem nosniff-Attribut aus.
• Updates des Service Workers beeinflussen alte Tabs, die noch auf altem JavaScript laufen. Das wirkt wie ein Regression-Problem. Die Lösung: Ein automatischer Neuladen-Vorgang bei controllerchange.

Die Idee nachbilden

Auch wenn Sie meine ZIP-Datei niemals ausführen – die Architektur besteht aus vier austauschbaren Komponenten:

• Ein Chat-Backend, das den Chatverlauf verwaltet: ein kleiner Webserver (hier FastAPI sowie eine SQLite-Datei im WAL-Modus), ein WebSocket für Echtzeit-Updates sowie ein gewöhnlicher HTTP-Endpunkt zum Einlesen von Nachrichten. Dies ersetzt die Datenbank sowie sämtliche Container.
• Ein Agent-Gateway, mit dem das Backend kommuniziert: hier OpenClaw; doch jede Komponente, die eine Sitzungs-ID und eine Nachricht entgegennimmt und Text zurückgibt, ist geeignet. Da es sich um einen separaten Prozess handelt, kann er abstürzen, aktualisiert werden oder ausgetauscht werden – ohne dass die Chat-Anwendung betroffen ist.
• Modell-Server hinter dem Gateway (LM Studio, vLLM, Ollama). Sie sind Aufgabe des Gateways – nicht der Chat-Anwendung.
• Optionale Medien-Dienste, etwa ein Bildgenerator auf einem anderen Rechner, den die Agenten als Werkzeug nutzen können. Das Backend speichert lediglich die erhaltenen Ergebnisse.

Diese Erkenntnisse gelten unabhängig von Ihrer Technologie-Stack-Wahl:

• Setzen Sie den „Locked Mode“ auf dem Server – niemals in CSS.
• Betrachten Sie das Problem „Die Antwort erreicht den Nutzer genau einmal“ als reines Zustellungsproblem, für das Sie Mechanismen zur Deduplizierung implementieren müssen.
• Verzichten Sie auf Frontend-Kompilierung, falls KI-Agenten die Pflege übernehmen sollen.

Weitere Informationen: Mein lokaler KI-Agent-Stack auf OpenClaw · Erster Eindruck vom DeepSeek Harness · Meine Websites mit einem lokalen KI-Agenten verwalten · Ihren LLM-Assistenten einrichten

Downloads

• Download DisPatch source (zip, 2.0.0, October 2026, MIT) 2.9 MB

Kostenlos für die private Nutzung. Wenn es dir einen Nachmittag erspart, ist der Kaffee-Button gleich in der Nähe.