Start/Strömungen/Forschung/KAIROS: Anatomie von Anthropics Always-On Agent Daemon
2. April 2026

Der Claude Code Source Leak vom 31. Maerz 2026 hat 512.000 Zeilen TypeScript-Quellcode offengelegt. Waehrend der Leak viele Architekturdetails enthuellte -- vom Memory-System ueber Permission-Layer bis zum Context-Compression-Stack -- ist ein Feature das mit Abstand bedeutendste: KAIROS, Anthropics unreleased Always-On Agent Daemon. CodePointer nannte es "probably the biggest product roadmap reveal from the leak". Alex Kim ordnete es aehnlich ein.

Dieser Artikel konzentriert sich ausschliesslich auf KAIROS und die technischen Mechanismen, die einen proaktiven Agenten ausmachen. Fuer den breiteren Kontext des Leaks, die DMCA-Nachwirkungen und die allgemeine Architektur von Claude Code siehe den Leak-Artikel.

Was KAIROS ist

KAIROS ist ein persistenter Daemon -- ein Hintergrund-Agent, der eigenstaendig weiterarbeitet, nachdem der Nutzer das Terminal geschlossen hat. Der Name stammt vom altgriechischen Konzept des kairos (der "richtige Moment"), im Gegensatz zu chronos (die messbare, lineare Zeit). Kairos bezeichnet den qualitativen Augenblick, in dem Handeln angemessen ist. Fuer einen Agenten, der selbst entscheidet wann er aktiv wird und wann er schlaeft, ist der Name treffend gewaehlt.

Im Quellcode finden sich ueber 150 Referenzen auf KAIROS. Das Feature ist hinter zwei Feature-Gates gesperrt: feature('KAIROS') und feature('PROACTIVE'). Insgesamt dokumentiert der Leak 108 gesperrte Module, die nicht im oeffentlichen Paket erscheinen -- KAIROS ist das umfangreichste davon.

Der konzeptionelle Paradigmenwechsel ist fundamental: Claude Code wird vom reaktiven Werkzeug, das auf Eingaben wartet, zum proaktiven Agenten, der Kontext ueber die Zeit aufbaut und eigenstaendig handelt. Das ist kein inkrementelles Feature-Update, sondern eine Architekturverschiebung.

Die fuenf Kernmechanismen

KAIROS besteht aus fuenf ineinandergreifenden Mechanismen, die zusammen einen proaktiven Agenten ergeben, ohne den Nutzer zu stoeren. Jeder einzelne loest ein spezifisches Problem, das beim Uebergang vom reaktiven zum proaktiven Agenten entsteht.

1. Tick-Loop (Proaktive Engine)

Das Herzstueck von KAIROS ist die Tick-Loop -- der Mechanismus, der den Agenten von einem passiven Antwortgeber in einen aktiven Akteur verwandelt.

Wenn die Warteschlange leer ist (der Nutzer hat keine Eingabe gemacht), injiziert KAIROS <tick>-Nachrichten. Der technische Mechanismus ist elegant:

setTimeout(() => {
  ...
  enqueue({ mode: 'prompt', value: tickContent ... })
})

Das setTimeout() ist entscheidend: Es yieldet zum Event-Loop, sodass Nutzereingaben autonome Aktionen jederzeit unterbrechen koennen. Der Agent arbeitet also nie in einem blockierenden Loop, sondern gibt dem System nach jedem Schritt die Moeglichkeit, auf den Nutzer zu reagieren.

Bei jedem Tick durchlaeuft der Agent einen Entscheidungszyklus:

  1. Tick fires -- die <tick>-Nachricht wird injiziert
  2. Agent prueft auf Arbeit -- das Modell entscheidet eigenstaendig, ob es etwas Sinnvolles zu tun gibt
  3. Ausfuehrung -- wenn ja, fuehrt es Kommandos aus (das Blocking Budget greift hier, dazu gleich mehr)
  4. Logging -- Beobachtungen werden ins taegliche Append-Only Log geschrieben
  5. Kommunikation -- Ergebnisse werden via SendUserMessage an den Nutzer gesendet
  6. Queue leert sich -- der Agent ist fertig
  7. Naechster Tick wird geplant -- zurueck zu Schritt 1

Dieses Design hat eine wichtige Eigenschaft: Der Agent ist nie "beschaeftigt" im klassischen Sinne. Er ist entweder aktiv (fuehrt einen Tick aus) oder wartend (naechster Tick ist geplant). Dazwischen kann der Nutzer jederzeit eingreifen.

2. 15-Sekunden Blocking Budget

Das zweite Problem eines proaktiven Agenten: Was passiert, wenn ein Shell-Kommando laenger dauert? Ein git clone eines grossen Repos, ein npm install, ein laufender Build -- all das kann Minuten dauern. Ein blockierter Agent waere in dieser Zeit unbrauchbar.

KAIROS loest das mit einer harten Konstante:

ASSISTANT_BLOCKING_BUDGET_MS = 15_000

Shell-Kommandos, die laenger als 15 Sekunden dauern, werden automatisch in den Hintergrund verschoben via startBackgrounding(...). Der Agent wird nie blockiert, waehrend der Prozess weiterlaeuft. Er kann den naechsten Tick verarbeiten, auf den Nutzer reagieren oder andere Aufgaben erledigen.

Das erzwingt Responsiveness auf Systemebene. Es ist keine Empfehlung an das Modell ("bitte blockiere nicht zu lange"), sondern ein harter Mechanismus in der Runtime. Der Agent monopolisiert nie Systemressourcen -- egal was er tut.

Fuer die Agentenarchitektur ist das ein wichtiges Muster: Autonome Agenten brauchen nicht nur die Faehigkeit zu handeln, sondern auch harte Grenzen, die verhindern, dass sie das System lahmlegen. Das Blocking Budget ist eine solche Grenze.

3. SleepTool

Das dritte Problem: Ein proaktiver Agent, der bei jedem Tick einen API-Call macht, verursacht enorme Kosten -- selbst wenn er nichts zu tun hat. Gleichzeitig verfaellt der Prompt-Cache nach 5 Minuten Inaktivitaet, was den naechsten Call teurer macht.

Das SleepTool loest diesen Zielkonflikt. Der System-Prompt instruiert das Modell explizit:

"Each wake-up costs an API call, but the prompt cache expires after 5 minutes of inactivity -- balance accordingly."

Das Modell muss also selbst lernen, Kosten gegen Reaktionsfaehigkeit abzuwaegen. Das ist bemerkenswert: Statt eine feste Sleep-Dauer zu codieren, delegiert Anthropic die Kostenoptimierung an das Modell selbst. Es ist eine oekonomische Entscheidung, die der Agent bei jedem Tick trifft.

Die Pacing-Anweisung im System-Prompt ist dabei unmissverstaendlich:

"If you have nothing useful to do on a tick, you MUST call Sleep. Never respond with only a status message."

Das verhindert, dass der Agent bei jedem Tick eine nichtssagende "Alles ok"-Nachricht sendet und dabei API-Kosten verursacht. Entweder der Agent hat etwas Substanzielles zu berichten, oder er schlaeft. Dazwischen gibt es nichts.

4. Append-Only Tageslogbuch

Proaktive Agenten, die ueber laengere Zeitraeume laufen, brauchen ein Gedaechtnis, das nicht bei jeder Session ueberschrieben wird. KAIROS loest das mit einem Append-Only Tageslogbuch.

Sessions schreiben in logs/YYYY/MM/YYYY-MM-DD.md statt MEMORY.md zu ueberschreiben. Das ist eine bewusste Designentscheidung: Append-Only Logs sind idempotent, konfliktfrei und chronologisch nachvollziehbar. Mehrere Sessions am selben Tag fuegen Eintraege hinzu, ohne sich gegenseitig zu ueberschreiben.

Aber Logs allein skalieren nicht. Nach Wochen oder Monaten wuerden die taeglichen Logs zu gross und unstrukturiert. Deshalb gibt es einen separaten naechtlichen /dream-Prozess, der die Logs in strukturierte Topic-Files destilliert und anschliessend den Index aktualisiert. Die Logs sind das Rohmaterial, die Topic-Files sind das destillierte Wissen.

5. SendUserMessage (BriefTool)

Das fuenfte und letzte Kernproblem: Wie kommuniziert ein Hintergrund-Agent mit dem Nutzer, ohne ihn zu ueberfluten? Ein Agent, der staendig Statusmeldungen ausgibt, ist genauso stoerend wie einer, der schweigt.

KAIROS loest das mit einem dedizierten Tool: SendUserMessage (intern auch BriefTool genannt). Alle nutzer-sichtbaren Ausgaben muessen durch dieses Tool laufen. Das System-Prompt warnt explizit:

"Text outside it is visible if the user expands the detail view, but most won't -- assume unread."

Das bedeutet: Alles, was der Agent denkt, plant oder intern verarbeitet, ist fuer den Nutzer unsichtbar -- es sei denn, er klappt aktiv die Detailansicht auf. Nur was durch SendUserMessage geht, erreicht den Nutzer zuverlaessig.

Ein dreistufiges Filtersystem erzwingt diesen Vertrag auf UI-Ebene. Das ist keine blosse Konvention, sondern ein architektureller Mechanismus, der sicherstellt, dass der Agent den Nutzer nur mit relevanten Ergebnissen stoert -- nie mit internem Rauschen.

autoDream: Naechtliche Memory-Konsolidierung

Ueber den fuenf Kernmechanismen liegt ein weiteres System, das KAIROS von einem einfachen Cron-Job unterscheidet: autoDream, die naechtliche Memory-Konsolidierung.

autoDream liegt im Verzeichnis services/autoDream/ und laeuft als geforkter Subagent -- ein separater Prozess, unabhaengig vom Hauptassistenten. Das ist Isolation by Design: Der Dream-Prozess kann den primaeren Kontext nicht korrumpieren, weil er in einem eigenen Prozessraum operiert.

Was autoDream tut:

Der Trigger fuer autoDream ist ein Drei-Gate-System:

  1. Zeitgate: Mindestens 24 Stunden seit dem letzten Dream
  2. Aktivitaetsgate: Mindestens 5 Sessions seit dem letzten Dream
  3. Lock-Gate: Nur ein Agent "traeumt" gleichzeitig -- verhindert Race Conditions bei mehreren KAIROS-Instanzen

Waehrend des Dream-Prozesses gilt eine harte Sicherheitsschranke: Der Agent darf ausschliesslich Memory-Dateien schreiben. Quellcode aendern ist waehrend eines Dreams verboten. Das verhindert, dass ein naechtlicher Konsolidierungsprozess versehentlich (oder absichtlich) Code modifiziert -- eine sinnvolle Vorsichtsmassnahme fuer einen Prozess, der ohne menschliche Aufsicht laeuft.

Die Metapher des "Traeumens" ist bewusst gewaehlt: Wie im menschlichen Schlaf konsolidiert der Prozess Erfahrungen, ohne neue zu machen. Er verarbeitet, ordnet und strukturiert -- aber er handelt nicht.

GitHub-Integration

KAIROS ist nicht nur ein lokaler Daemon. Die Codebase zeigt eine tiefe GitHub-Integration:

Das Szenario, das sich daraus ergibt: Ein Entwickler pusht Code, geht in die Mittagspause, und KAIROS reviewt den PR, fuehrt Tests aus, und hat bei Rueckkehr eine Zusammenfassung via SendUserMessage bereit. Oder: Ein CI-Build schlaegt fehl, KAIROS analysiert den Fehler und schlaegt einen Fix vor -- noch bevor der Entwickler es bemerkt hat.

Verwandte gesperrte Features

KAIROS existiert nicht isoliert. Der Leak enthuellt mehrere verwandte Module, die zusammen ein Bild der geplanten Agent-Infrastruktur zeichnen:

ULTRAPLAN lagert tiefe Planungssessions an eine Remote-Opus-4.6-Instanz aus -- fuer bis zu 30 Minuten. Das bedeutet: Komplexe Planungsaufgaben, die das Kontextfenster eines einzelnen Calls sprengen wuerden, werden an eine dedizierte Instanz delegiert, die sich Zeit nehmen kann.

COORDINATOR_MODE orchestriert Multi-Agent-Schwaerme mit strukturierten Research-Synthese-Implementierungs-Phasen. Bemerkenswert: Die Orchestrierung erfolgt ueber System-Prompts, nicht ueber Code. Die Anweisung "Do not rubber-stamp weak work" zeigt, dass Anthropic explizit gegen die Tendenz von LLMs vorgeht, Ergebnisse unkritisch durchzuwinken. Die Datei coordinatorMode.ts implementiert diese Multi-Agent-Orchestrierung.

DREAM ist das naechtliche Selbstwartungssystem fuer Memory-Reorganisation -- der breitere Rahmen, in dem autoDream operiert.

Buddy ist ein ueberraschendes Feature: Ein Tamagotchi-Companion mit 18 Spezies, Seltenheitsstufen und Statistiken. Es wirkt wie ein Gamification-Element, das die Bindung des Nutzers an Claude Code erhoehen soll -- ungewoehnlich fuer ein Entwicklertool, aber konsistent mit dem Ziel, Claude Code von einem Werkzeug zu einem Begleiter zu machen.

promptCacheBreakDetection.ts trackt 14 verschiedene Cache-Break-Vektoren mit "sticky latches". Das deutet auf eine ausgefeilte Kostenoptimierung hin, die erkennt, wann und warum der Prompt-Cache invalidiert wird -- relevant fuer KAIROS, wo jeder unnoetige Cache-Break direkte API-Kosten verursacht.

Insgesamt sind 108 gesperrte Module im Leak dokumentiert -- KAIROS ist das Flaggschiff, aber das Oekosystem drum herum zeigt, dass Anthropic eine umfassende Agent-Infrastruktur plant.

Architekturelle Einordnung

Fuer Entwickler, die eigene Agentensysteme bauen, liefert KAIROS einen konkreten Blueprint. Die fuenf Kernmechanismen adressieren fuenf fundamentale Probleme proaktiver Agenten:

Problem Mechanismus Loesung
Wann soll der Agent handeln? Tick-Loop Regelmaessige Entscheidungspunkte mit Event-Loop-Yielding
Wie verhindert man Blockierung? Blocking Budget Harte 15s-Grenze, automatisches Backgrounding
Wie kontrolliert man Kosten? SleepTool Modell-gesteuerte Kostenoptimierung
Wie skaliert das Gedaechtnis? Append-Only Logs + Dream Chronologische Logs mit naechtlicher Destillation
Wie kommuniziert man nicht-invasiv? SendUserMessage Dediziertes Output-Tool mit Filtersystem

Keiner dieser Mechanismen ist fuer sich genommen revolutionaer. Die Tick-Loop ist ein Event-Loop-Pattern. Das Blocking Budget ist ein Timeout. Das SleepTool ist ein Backoff. Append-Only Logs sind Standard in verteilten Systemen. SendUserMessage ist ein Output-Channel.

Was KAIROS auszeichnet, ist die Komposition: Fuenf bekannte Muster, praezise aufeinander abgestimmt, ergeben ein System, das qualitativ anders ist als die Summe seiner Teile. Der Agent kann autonom handeln, ohne den Nutzer zu stoeren, ohne Ressourcen zu monopolisieren, ohne Kosten zu explodieren und ohne sein eigenes Gedaechtnis zu korrumpieren.

Bedeutung fuer den Markt

Claude Code generiert laut Berichten einen ARR von 2,5 Milliarden Dollar. Der Leak gibt Wettbewerbern nun einen detaillierten Bauplan fuer die naechste Generation von Coding-Agenten. Projekte wie Nous Hermes Agent positionieren sich bereits als offene Alternativen und nutzen die geleakte Architektur als Referenz.

Die strategische Ironie ist offensichtlich: Was Anthropic als proprietaere IP schuetzen wollte, wird zum oeffentlichen Blueprint. Aber der Vorsprung liegt nicht im Wissen um die Architektur, sondern in der Ausfuehrung -- in den Modellgewichten, der Infrastruktur, den Nutzerdaten und der Iteration. KAIROS zu kennen ist nicht dasselbe wie KAIROS zu bauen.

Dennoch: Der Leak zeigt unmissverstaendlich, wohin die Reise geht. Der reaktive Coding-Assistent, der auf Eingaben wartet, ist ein Zwischenschritt. Das Ziel ist der proaktive Agent, der den Entwickler-Workflow versteht, Kontext ueber die Zeit aufbaut und im richtigen Moment -- im kairos -- eigenstaendig handelt.

Quellen

Nach oben