Local-First-Agenten vs. gehostete Agenten

Ein gehosteter Agent läuft in der Cloud eines Anbieters. Du gibst ihm eine Kopie deiner Repositories und Zugangsdaten, und er arbeitet von dort aus. Ein Local-First-Agent läuft auf deinem eigenen Rechner – mit der runtime, dem Abonnement, den Dateien und Schlüsseln, die bereits darauf liegen. Nur die Konversation verlässt das System.

Beide Ansätze haben ihre Berechtigung. Sie verorten deinen Code, deine Identität und deine Rechnung an unterschiedlichen Stellen – und diese Unterschiede fallen noch mehr ins Gewicht, sobald du den Agenten mit anderen teilst.

Was gehostete Agenten richtig machen – und was sie kosten

Die konkreten Beispiele im Jahr 2026 sind Claude Code on the web und OpenAI’s Codex cloud tasks. Beide führen den Agenten in der Sandbox des Anbieters für einen Klon deines Repositorys aus und authentifizieren sich gegenüber git mit tokens, die dem Anbieter über die GitHub-OAuth-Integration ausgestellt wurden. So hat der Agent niemals Zugriff auf deine lokalen Zugangsdaten, SSH-Schlüssel oder Umgebungsvariablen. Das ist ein echter Sicherheitsvorteil: Ein kompromittierter Entwickler-Laptop kann nicht in die Umgebung des Agenten überschwappen, und eine unzureichend eingegrenzte Aufgabe kann keine Dateien außerhalb der Sandbox berühren.

Ein gehosteter Agent ist immer online. Es gibt keinen Laptop, der wachgehalten werden muss, und nichts zu installieren. Für unbeaufsichtigte Flotten, die rund um die Uhr laufen, ist das entscheidend.

Die Nachteile sind struktureller Natur und lassen sich nicht einfach beheben.

• Eine zweite Kopie von allem. Der Anbieter verwahrt deine Repositories und oft auch deine Umgebung, damit der Agent arbeiten kann. Diese Kopie hat eigene Zugriffskontrollen, Aufbewahrungsfristen und Angriffsflächen.
• Ein zweiter Satz Zugangsdaten. Tokens für GitHub, Cloud-Konten und interne APIs werden für den Anbieter ausgestellt. Wenn du sie rotierst, musst du sie auch dort rotieren.
• Eine zweite Rechnung. Du bezahlst für die gehostete runtime zusätzlich zu – oder anstelle von – dem Abonnement, das du ohnehin schon hast.
• Die Modellauswahl eines Dritten. Der Host bestimmt, welche Modelle verfügbar sind und wann sie geändert werden.

Was Local-First richtig macht – und was es kostet

Ein Local-First-Agent nutzt das, was sich bereits auf deinem Rechner befindet: das Claude Code- oder Codex-Abonnement, für das du bezahlst, die Repositories, die du bereits ausgecheckt hast, die Schlüssel, die schon in deinem Schlüsselbund liegen. Nichts wird irgendwohin kopiert. Wenn du den Agenten teilst, darf die andere Person Anfragen stellen; dein Rechner erledigt nach wie vor die Arbeit.

Der Nachteil ist die Verfügbarkeit. Schläft der Rechner, schläft auch der Agent.

Die Gegenmaßnahmen sind eher pragmatischer als architektonischer Natur: Registriere den daemon als Dienst, damit er beim Login startet und nach einem Absturz neu anläuft, halte den Rechner während der Arbeitszeit wach und stelle Anfragen in eine Inbox, damit nichts verloren geht, während er offline ist. Anfragen werden der Reihe nach abgearbeitet, sobald er wieder da ist.

Zwei Orte für die Vertrauensgrenze: um die Sandbox des Anbieters oder um den eigenen Rechner mit einem Raum davor.

Wie dünn die Cloud-Schicht sein kann

muti ist local-first, und die interessante Designfrage war, was die Cloud überhaupt vorhalten darf. Die Antwort: den Raum – und nichts, womit sich der Raum als der Rechner ausgeben könnte.

Drei Mechanismen stellen das sicher.

Nur ausgehend. Der daemon auf deinem Rechner fragt Aufgaben über eine ausgehende Verbindung ab. Es gibt keinen offenen Port, keinen Tunnel und keinen eingehenden Pfad. Wäre die Cloud von muti kompromittiert, könnte ein Angreifer zwar Anfragen in die Warteschlange stellen, die aber weiterhin deinen Berechtigungsregeln und Freigaben unterlägen; an deine Dateien käme er nicht heran.

Events statt Dateien. Der daemon sendet Timeline-Events, die beschreiben, was passiert ist. Er lädt keinen Arbeitsbaum hoch und liest niemals Umgebungsvariablen oder Schlüsseldateien aus, um sie irgendwohin zu übertragen.

Freigaben als Zwischenschritt. Da der Rechner dir gehört, pausieren die vier gefährlichen Aktionsarten bei jeder Anfrage einer anderen Person und warten auf dich. Ein gehosteter Agent mit deinen Zugangsdaten hat niemanden, den er fragen könnte.

Eine Entscheidungshilfe

Warum muti keine runtimes hostet

Es wäre ein Leichtes, einen Button wie „In unserer Cloud ausführen“ hinzuzufügen. Das haben wir nicht getan, und es ist ein ganz bewusstes Nicht-Ziel. In dem Moment, in dem die runtime wandert, folgen die Zugangsdaten und Repositories – und der Besitzer ist nicht mehr derjenige, der freigibt. Jede Garantie in den vier Aktionen, bei denen ein Agent immer nachfragen sollte, beruht darauf, dass der Rechner dem Besitzer gehört.

muti hostet Räume. Dein Agent bleibt, wo er ist.

Häufig gestellte Fragen

Bedeutet „Local-First“ dasselbe wie „Offline“? Nein. Der Agent benötigt das Netzwerk, um seinen Modellanbieter zu erreichen, und muti benötigt es, um Nachrichten zuzustellen. Local-First beschreibt, wo die Arbeit und die Geheimnisse liegen, nicht, ob der Rechner mit dem Internet verbunden ist.

Kann ich die Cloud von muti selbst hosten? Das Self-Hosting der Raum-Schicht steht als Einzelnutzer-Modus mit Offline-Funktion auf der Roadmap. Der daemon und die Cloud kommunizieren bereits über eine schlichte API.

Was ist, wenn ich mehrere Rechner habe? Verbinde einfach jeden einzelnen. Agenten sind an einen Rechner und ein Arbeitsverzeichnis gebunden, und du kannst deine Rechner anhand der Adressen unterscheiden, die der daemon meldet.

Wenn du bereits für einen guten Agenten bezahlst und ihn dort behalten möchtest, wo er ist: Gib ihm einen Raum.