Talorys: Zustandsbehaftete KI-Agenten auf Serverless

Hier kommt meine unbequeme These, und ich verteidige sie: Ein persönlicher KI-Agent passt besser zu Serverless-Infrastruktur als zum Raspberry Pi unter dem Schreibtisch. Das Talorys-Projekt – ein Open-Source-Assistent, der sich mit einem einzigen npx create-talorys@latest in deinen eigenen Cloudflare-Account installiert – ist der bisher beste Beleg dafür, dass das Problem „zustandsbehafteter KI-Agent auf zustandslosem Serverless“ nicht nur lösbar ist, sondern gut dazu passt. Und die Hacker-News-Leute, die darüber streiten, ob das „selbst gehostet“ ist, streiten über die falsche Frage.

Ich betreibe seit Jahren Infrastruktur und räume hinterher auf. Was selbst gehostete Personal Software umbringt, ist nicht das Deployment – sondern Monat drei, wenn die Festplatte voller Logs ist, das TLS-Zertifikat abläuft und du dich nicht mehr erinnerst, welche systemd-Unit das Scheduling übernimmt. Talorys umgeht diese ganze Fehlerklasse, indem es gar keinen Server hat. Alles, was es braucht – Chat, Speicher, Aufgaben, geplante Erinnerungen – läuft im Free Tier von Cloudflare: Pages für das Frontend, ein privater Worker für die API, ein SQLite-gestütztes Durable Object für den gesamten Zustand und Workers AI für das Modell. Gesamtkosten pro Monat für einen Nutzer: null.

Das eigentliche Problem: Agenten sind zustandsbehaftet, Serverless ist es nicht

Ein KI-Agent ist ein Bündel langlebigen Zustands, das sich als Request-Response-Anwendung ausgibt. Er braucht Gesprächsverlauf, dauerhafte Erinnerungen, eine Aufgabenliste, geplante Jobs, die um 7 Uhr feuern, ob jemand eingeloggt ist oder nicht, und einen Ort für Tool-Ausgaben, während eine mehrstufige Kette läuft. Jedes dieser Teile ist dem klassischen Serverless-Modell feindlich gesinnt, bei dem deine Funktion ein Goldfisch ist: Sie wacht auf, bearbeitet eine Anfrage und vergisst alles.

Die übliche Antwort der Branche: Zustand an den Rändern wieder zusammensetzen. Redis für Session-Daten, Postgres für dauerhafte Datensätze, eine Queue plus Scheduler für Cron, eine Vektordatenbank für semantische Erinnerung. Das funktioniert, aber du hast damit eine Serverfarm aus Managed Services nachgebaut, mit entsprechender Rechnung und Betriebsfläche. Ich habe gesehen, wie Teams mehr Entwicklungszeit damit verbracht haben, fünf zustandsbehaftete Dienste für einen Agenten zu verdrahten, als die Agentenlogik selbst zu schreiben. Wie ich schon früher argumentiert habe, sind LLM-Agenten nichts anderes als verteilte Systeme – und verteilte Systeme sind der Ort, an dem gute Absichten sterben.

Talorys geht den umgekehrten Weg: Der gesamte Zustand kommt an genau eine Stelle. Ein Durable Object namens personal-agent hält die ganze Welt – Gespräche, Erinnerungen, Aufgaben, Notizen, Projekte, Automatisierungen, Sessions, Einstellungen und Nutzungsdaten – in seiner eingebetteten SQLite-Datenbank. Kein KV, kein D1, kein R2, kein Vectorize. Die README stellt ausdrücklich klar, dass davon nichts bereitgestellt wird. Das ist kein Zufall, das ist die Architektur.

Durable Objects sind der Cheat-Code

Durable Objects sind derzeit das wohl stillste radikale Primitiv im Cloud-Computing, und das ist keine Übertreibung. Ein Durable Object ist eine Single-Instance-Codeeinheit mit stark konsistentem, transaktionalem Speicher, der physisch direkt daneben liegt. Kommt eine Anfrage an das Objekt personal-agent, weckt Cloudflare es auf – in Millisekunden, aus dem Kaltstart – führt deinen Code gegen das lokale SQLite aus und friert es wieder ein, sobald es untätig ist. Du bekommst die Ergonomie eines lang laufenden Serverprozesses mit dem Abrechnungsmodell einer Lambda-Funktion.

Für einen persönlichen Agenten mit einem einzigen Nutzer werden die berüchtigten Einschränkungen dieses Modells zu Vorteilen:

• Ein einziger Schreiber ist ein Feature. Ein Nutzer bedeutet genau einen Schreiber. Das ganze Concurrency-Elend von Multi-Tenant-Zuständen entfällt; du bekommst serialisierten, transaktionalen Zugriff auf alles gratis.
• Colocation macht Latenz klein. Speicherabfragen, Aufgabensuche und Gesprächsverlauf des Agenten sind SQLite-Lesevorgänge auf der lokalen Platte, keine Netzwerk-Roundtrips zu einer Datenbank in einer anderen Availability Zone.
• Alarme ersetzen Cron. Durable-Object-Alarme erlauben dem Objekt, sein eigenes Aufwachen zu planen. Erinnerungen, wiederkehrende Routinen und Tagesübersichten feuern, ohne dass irgendeine Maschine online bleibt – das Objekt schläft, der Alarm weckt es, es erledigt seinen Job und legt sich wieder hin.
• Ruhezustand ist kostenlos. Leerlaufzeit kostet nichts. Ein persönlicher Assistent, der 23 Stunden am Tag untätig ist, ist genau die Art von Last, für die Serverless-Preise erfunden wurden.

Das ist die Erkenntnis, die ich mir von diesem Projekt bei mehr Leuten wünschen würde. Wenn deine Anwendung von Natur aus Single-Tenant ist – ein persönliches Tool, ein Workspace pro Kunde, ein Koordinator pro Gerät –, gibt dir das Muster „ein Durable Object pro Tenant“ etwas, das früher einen VPS erforderte: einen kleinen Rechner, der konzeptionell immer läuft, im Leerlauf nichts kostet und nie einen Sysadmin braucht. Allein die Scheduling-Geschichte ist den Eintritt wert. Wer schon mal eine persönliche Cron-Kiste betrieben hat, kennt den typischen Fehler: Die Kiste startet neu, der Cron-Daemon kommt nicht zurück, und zwei Wochen später merkst du, dass deine Erinnerungen stillschweigend ausgefallen sind. Alarme sind vom Betreiber der Infrastruktur verwaltetes Scheduling – und eine Sache weniger, um die man sich kümmern muss.

Das Netzwerkmodell ist besser als die meisten Produktivsetups

Hier wurde ich hellhörig, und das kommt von meinem Security-Hintergrund. Der Agent-Worker in Talorys wird mit workers_dev: false und preview_urls: false deployt. Er hat überhaupt keine öffentliche URL. Der Browser spricht nur mit einer *.pages.dev-Seite; eine Pages Function unter /api/* leitet Anfragen über einen Service Binding an den Worker weiter – Cloudflares interne, private Verdrahtung zwischen Compute im selben Account. Authentifizierung und Autorisierung finden im Worker statt, nicht im Frontend.

Denk darüber nach, was das ausschließt. Kein öffentlicher API-Endpunkt, den man scannen kann. Keine Firewall-Regeln, die man falsch konfigurieren kann. Kein Reverse Proxy, den man vergisst zu patchen. Die Angriffsfläche des Agenten-Backends ist praktisch: „Du musst über den Auth-Flow des Frontends kommen.“ Ich habe Produktivdeployments bei echten Firmen mit Budget und Security-Teams geprüft, die eine lockerere Netzwerkabsicherung hatten als dieses Side Project. Das häufigste Incident-Muster, das ich in Cloud-Umgebungen gesehen habe, war ein interner Dienst, der „nur intern erreichbar“ war – bis er es eines Tages nicht mehr war, weil jemand eine Load-Balancer-Konfiguration verhauen hatte. Ein Service Binding kann man nicht versehentlich öffentlich machen; die URL existiert schlicht nicht.

Auch der Installer verdient eine Erwähnung. Er hasht das Owner-Passwort lokal mit PBKDF2-SHA256 und speichert nur den Hash als Cloudflare-Secret, erzeugt ein 256-Bit-Session-Secret, vergibt eindeutige Ressourcennamen und verifiziert dann das laufende Deployment – inklusive der Prüfung, dass unauthentifizierte Anfragen tatsächlich abgelehnt werden – ohne dabei KI-Inferenzkontingent zu verbrauchen. Ein Post-Deployment-Check, der bestätigt, dass die Authentifizierung Unauthentifizierte wirklich abweist, gehört zu den Dingen, die ich schon in Incident-Postmortems festgehalten habe. Ihn in einem Installer mit einem einzigen Befehl zu sehen, ist ein angenehmer Überraschungsmoment.

Im Free Tier leben, ohne sich selbst etwas vorzumachen

Das Free Tier ist real, aber es ist ein Budget, kein Buffet. Cloudflare gibt kostenlosen Accounts ein tägliches Workers-AI-Kontingent, gemessen in „Neurons“ – 10.000 pro Tag – plus Kontingente für Requests und Durable-Object-Nutzung. Diese Zahlen legt Cloudflare fest und sie können sich ändern. Talorys geht damit ehrlicher um als die meisten „Free Tier“-Projekte, die ich gesehen habe: Ist das KI-Kontingent aufgebraucht, sagt der Chat das klar und macht nach dem täglichen Reset weiter, während Aufgaben, Notizen, Erinnerungen und Erinnerungsfunktionen weiterlaufen, weil keine davon das Modell braucht.

Die Leitplanken sind es wert, für eigene Projekte übernommen zu werden. Talorys bietet konfigurierbare Obergrenzen für maximale Ausgabe-Tokens, maximale Kontext-Tokens (ältere Historie wird zusammengefasst statt stillschweigend abgeschnitten), maximale Tool-Aufrufe und Reasoning-Schritte pro Anfrage, maximale KI-Anfragen pro Tag und maximale geplante KI-Läufe pro Tag. Das ist eine ausgereifte Haltung. Unbegrenzte Agenten-Schleifen sind der Weg, wie man mit einer Rechnung oder einem Kontingent-Ausfall aufwacht, und „der Agent hat das Tool 40-mal aufgerufen“ ist ein Fehlermuster, das ich schon echtes Geld in Produktion verbrennen gesehen habe. Passend dazu: Dass das Projekt einfache Erinnerungen und Tagesübersichten niemals KI nutzen lässt, ist genau richtig. Wenn ein Codepfad deterministisch ist, schick ihn nicht durch ein probabilistisches Modell. Das ist dieselbe Disziplin, die hinter der Beschränkung von Modellausgaben auf strukturierte Entscheidungen steckt – das Modell nur dort einsetzen, wo tatsächlich Urteilsvermögen gefragt ist.

Eine Warnung aus der Community: Mehrere Leute berichten von undurchsichtigen Abrechnungsüberraschungen, wenn Workers AI mit kostenpflichtigen Workers-Tarifen kombiniert wird. Die Neuron-Abrechnung stimmte nicht mit den dokumentierten Limits überein, und Support-Tickets liefen ins Leere. Ich kann die Details nicht überprüfen, aber es passt zu einem Muster, das ich gut kenne: Nutzungsabhängige KI-Abrechnung ist überall verwirrend, und „freundlich fürs Free Tier“ heißt nicht „unmöglich, eine Rechnung zu bekommen“. Wenn du das auf einem bezahlten Tarif deployst, richte am ersten Tag einen Ausgabenalarm im Cloudflare-Dashboard ein. Betrachte die Nutzungsoberfläche des Anbieters als maßgebliche Quelle, nicht die lokalen Schätzungen der App.

Der „Self-Hosted“-Streit verfehlt den Punkt

Jetzt das Zugeständnis, das meine Eröffnungsthese verlangt. Die Top-Kommentare zu diesem Projekt sind ein Flamewar über das Wort „self-hosted“, und die Erbsenzähler haben einen echten Punkt: Das Ding hängt vollständig von Cloudflare ab. Deine Daten liegen in deren Rechenzentren, deine Inferenz läuft auf deren GPUs, und wenn Cloudflare morgen das Free Tier ändert, ändert sich dein Assistent mit. Das als Self-Hosting zu bezeichnen, dehnt das Wort bis zum Zerreißen. Die wohlwollende Lesart – kein Drittanbieter jenseits eines Cloudflare-Accounts, den du ohnehin kontrollierst, keine Telemetrie an die Entwickler, kein Betreiber dazwischen – lässt sich besser als „selbst besessen“ oder „selbst verwahrt“ beschreiben. Worte zählen, und das Projekt würde weniger Gegenwind bekommen, wenn es bessere wählte.

Aber hier verliere ich die Erbsenzähler. Das eigentliche Bedrohungsmodell für persönliche Software ist nicht „die Nutzungsbedingungen eines Konzerns könnten sich ändern“. Es geht um Datenabfluss, Telemetrie und darum, dass der Entwickler pleitegeht und die gehostete Version abschaltet. Bei all diesen drei Punkten steht Talorys wirklich gut da: Es gibt keinen Analytics- oder Tracking-Code, nichts meldet sich bei den Autoren, und es gibt keine gehostete Version, die abgeschaltet werden könnte. Außerdem ist der Code MIT-lizenziert, und wie ein Kommentator bemerkte, ist das Umlenken der KI-Aufrufe auf einen lokalen Modellserver ein kleiner Patch – der gesamte Stack läuft sogar lokal unter wrangler dev mit einem Mock-KI-Provider. Sollte Cloudflare jemals inakzeptabel werden, ist der Ausweg kurz. Vergleich das mit der durchschnittlichen „selbst gehosteten“ App, die in Wahrheit eine Docker-Compose-Datei ist, die von der Registry irgendeines Anbieters zieht und für Lizenzprüfungen nach Hause telefoniert.

Im Thread steckt auch eine fairere Kritik: Es gibt keinen Beleg, dass der Assistent tatsächlich gut ist. Chat-Oberfläche, CRUD für Erinnerungen, Embeddings und Cron sind jeweils trivial zu bauen; das Harness, das Prompting, die Abrufstrategie für Erinnerungen und die Tool-Schemata entscheiden darüber, ob persönliche Assistenten funktionieren oder scheitern – und nichts davon wird durch ein sauberes Architekturdiagramm belegt. Das gilt für fast jedes Projekt dieser Art, und das ist zu Recht ein Grund für Skepsis. Bewerte Talorys als Infrastruktur – ein gut durchdachtes Chassis – und nicht als bewährten Copiloten. Wenn du gerade Modelle für so etwas abwägst, deckt unser Artikel über das lokale Betreiben von LLMs auf eigener Hardware das andere Ende des Souveränitätsspektrums ab.

Was du von diesem Design übernehmen solltest

Auch wenn du Talorys nie deployst, ist die Architektur eine Referenz, die es sich zu verinnerlichen lohnt. Die übertragbaren Ideen:

1. Ein Objekt pro Tenant. Ist deine App für einen Nutzer gebaut oder sauber partitionierbar, lege Code und Zustand in einem Durable Object zusammen und streiche deine Cache-Schicht, deine Message-Queue und deinen Connection-Pooler.
2. Keine öffentliche Backend-URL. Service Bindings mit workers_dev: false sind der günstigste Sicherheitsgewinn im Serverless-Bereich. Ein Dienst, der nicht erreichbar ist, kann nicht angegriffen werden.
3. Alarme statt Cron-Kisten. Scheduling, das bei der Infrastruktur liegt, übersteht Neustarts, Redeployments und deine eigene Vergesslichkeit.
4. Kontingentbewusste Degradierung. Gestalte die App so, dass die teure Abhängigkeit (das Modell) ausfallen oder das Kontingent erschöpfen kann, während das Kernprodukt weiterläuft. Degradierung sollte ein Feature sein, kein Ausfall.
5. Nur anfügende Migrationen. Der Durable-Object-Namespace wird beim Update nie neu angelegt; Schema-Migrationen laufen transaktional bei der ersten Anfrage. So aktualisierst du zustandsbehaftetes Serverless, ohne Datenverlust-Roulette zu spielen.

Die größere Lehre betrifft die Richtung, in die persönliche Software sich bewegt. Zwanzig Jahre lang war die Wahl binär: entweder einem SaaS-Unternehmen deine Daten anvertrauen oder zum Teilzeit-Sysadmin werden. Durable Objects – und die Kopien, die andere Clouds zwangsläufig nachbauen werden – öffnen einen dritten Weg: Software, die nur du kontrollierst, betrieben von Infrastruktur, die du mietest, und auf persönlicher Ebene kostenlos. Es ist kein Self-Hosting. Es könnte besser sein.