Was Hermes von Claude Code unterscheidet
Claude Code ist ein Werkzeug, das du aufmachst, wenn du es brauchst. Hermes ist die andere Kategorie: ein persistenter, selbstgehosteter Agent, der als Dauerprozess auf deinem eigenen Server läuft — und der dich erreicht, nicht umgekehrt. Er schickt dir morgens ein Briefing, erinnert an Fristen, beantwortet eine E-Mail (mit deiner Freigabe), alles ohne dass du ein Terminal öffnest.
In einem Satz: Claude Code ist on-demand. Hermes ist always-on. Beides gute Werkzeuge — für verschiedene Jobs.
Was er kann — kompakt
16+ Kanäle
Matrix, E-Mail, Telegram, Signal, WhatsApp, Slack, SMS … ein Agent, überall erreichbar.
Jedes LLM
OpenRouter (400+ Modelle mit Failover), Anthropic, OpenAI, Google, lokal — deine Wahl.
Proaktiv per Cron
Briefings, Fristen-Erinnerungen, Reports — er meldet sich von selbst.
MCP · Bot Mode · Computer-Use
Beliebige Tools über MCP, ein Roster benannter Bots, und er steuert notfalls den Rechner selbst.
Die ausführliche Übersicht (Fähigkeiten, Tech-Stack, Einrichtung) liegt als eigene Referenzseite in der Lounge. Hier geht es um den Teil, der dort bewusst kurz bleibt: die Praxis.
Falle 1: Er kann sich nicht selbst neu starten
Die teuerste Lektion zuerst. Hermes kann sich selbst umbauen — neue Bots, neues Image, neuer Container. Klingt praktisch, bis er es tut: Er stoppt seinen alten Container, um den neuen zu starten — und tötet damit genau den Prozess, der den neuen hochfahren müsste. Ergebnis: Der neue Container steht auf created, aber niemand startet ihn. Der Agent ist komplett weg — und kommt von allein nicht zurück.
Der Kern: Ein Container kann sich nicht von innen selbst starten. Wer einem Agenten erlaubt, sich selbst neu zu deployen, braucht eine Hand von außen, die den letzten Schritt macht.
Die Lösung ist ein winziger Wächter auf dem Host — außerhalb des Agenten —, der jede Minute genau eine Sache prüft:
status = docker inspect <container> -f '{{.State.Status}}'
wenn status == "created":
docker compose up -d # = die Hand von aussen
sonst:
nichts tun
Er greift nur beim Zustand created — also genau diesem Fehlerbild. Absichtliche Stops und echte Abstürze lässt er in Ruhe (kein blindes Crash-Loop-Wiederbeleben). Das komplette Skript inkl. systemd-Timer liegt im Kit.
Falle 2: Keine offene Verbindung, sondern ein Account-Hub
Man erwartet, dass die Desktop-App den Agenten über eine offene Adresse erreicht — IP und Port. Falsch. Hermes veröffentlicht keinen Port; App und Server finden sich über einen Account-Hub (bei Hermes das „Portal", per Login).
Die Falle: Nach jedem Redeploy ist der Portal-Login weg — und die Desktop-App findet den Agenten nicht mehr, obwohl er läuft. Der Server ist gesund, die Verbindung nicht. Fix: nach dem Redeploy einmal hermes portal neu einloggen. Wer das nicht weiß, sucht den Fehler stundenlang am falschen Ende.
Falle 3: Die Bind-Mount-Falle
Du editierst die Persona-Datei, startest neu — und nichts ändert sich. Der Grund: Das echte Datenverzeichnis des Containers liegt nicht dort, wo es intuitiv steht. Man bearbeitet eine Datei auf dem Host, die so heißt wie die richtige, aber ein verwaister Alt-Ordner ist — nicht der Mount, den der Container tatsächlich liest.
Der Reflex, der es löst: Nie raten, welche Datei der Container liest — docker inspect fragen:
docker inspect <container> \
-f '{{range .Mounts}}{{.Source}} -> {{.Destination}}
{{end}}' Das zeigt schwarz auf weiß, welcher Host-Ordner im Container wo landet. Verifizieren, nicht vermuten — das gilt bei jedem Container.
Wann sich das Selbermachen lohnt — und wann nicht
Lohnt sich
- Du willst einen persönlichen Always-on-Assistenten, ohne deine Daten einem SaaS zu geben
- Du hast einen kleinen Server und keine Scheu vor Docker + Terminal
- Dir sind Datenhoheit und EU-Hosting wichtiger als Ein-Klick-Komfort
Lohnt sich nicht
- Du willst nur nutzen, nicht betreiben — Wartung, Updates, Fallen inklusive
- Du arbeitest in einer §203-Branche und brauchst dokumentierte Compliance statt Bastellösung
Mein Fazit
Ein eigener, always-on KI-Agent ist kein Zukunftsversprechen mehr — er ist ein Nachmittag Setup. Aber es ist ein Betrieb, kein Produkt: Es gibt Fallen, und die drei oben sind die, an denen ich hängengeblieben bin. Mit dem Wächter und den zwei Reflexen (hermes portal nach Redeploy, docker inspect statt raten) läuft es dann erstaunlich stabil.
Kleine Offenlegung: Genau diese Technik betreiben wir auch gemanagt — als Felix / VeloAssist, §203-konform, für Kanzleien und Praxen, die nicht selbst schrauben wollen. Details auf der Referenzseite. Dieser Issue ist aber fürs Selbermachen — und dafür braucht es keinen Anbieter, nur einen Server und das Kit unten.
Zum Selbermachen
Hermes-Kit
Installationswege, das Verbindungsmodell erklärt, der fertige Self-Restart-Wächter (systemd) zum Anpassen und der Spickzettel der drei Stolperfallen.
HerunterladenDas war Issue 13 der Velo-Wissen-Reihe. Jeden Sonntag um 15 Uhr eine Empfehlung — ein Tool, eine Bibliothek, ein Workflow oder ein Skill, das ich selbst getestet habe und für nützlich halte.