Alternative zu OpenClaw: Persönlicher KI-Assistent mit Claude Code und MCP nach Anthropics Abschaltung (April 2026)

Vom Kiwop-Team · Digitalagentur spezialisiert auf Softwareentwicklung und angewandte Künstliche Intelligenz · Veröffentlicht am 19. April 2026 · Zuletzt aktualisiert: 19. April 2026

TL;DR — Am 4. April 2026 deaktivierte Anthropic die OAuth-Tokens, die es OpenClaw ermöglichten, die Abonnements Claude Max und Claude Pro zu nutzen. Betroffene Nutzer haben drei Optionen: "Extra Usage" zum API-Preis zahlen (zwischen 5- und 50-mal teurer), zu OpenAI Codex migrieren oder den Persönlichen Assistenten auf Claude Code + MCP neu aufbauen. Bei Kiwop haben wir uns für den dritten Weg entschieden und dokumentieren hier die resultierende Architektur — einen PA mit vier Kanälen (IMAP, Gmail, Slack, Telegram), rund 500 Zeilen eigenem Python-Code und null Grenzkosten, da alles innerhalb des Max-Abonnements bleibt.

Bei Kiwop haben wir 48 Stunden gebraucht, um zu entscheiden, was nach der Ankündigung von Anthropic zu tun ist. Dieser Artikel beschreibt diese Entscheidung — warum wir nicht zu OpenAI Codex gewechselt sind, warum wir das "Extra Usage" von Anthropic nicht bezahlt haben und wie wir unseren Persönlichen Assistenten (PA) auf Claude Code und Model Context Protocol (MCP) neu aufgebaut haben. Ein Assistent, der weiterhin auf demselben Claude Max x20-Abonnement läuft, mit denselben Kanälen, die wir vorher benutzten, aber mit einem fundamentalen Unterschied: Der Stack gehört uns, der Code gehört uns, und der Anbieter kann uns nicht den Teppich unter den Füßen wegziehen.

Es ist kein Anti-Anthropic-Manifest — wir nutzen ihre Modelle weiterhin täglich und halten sie für die besten auf dem Markt für Agenturen im Jahr 2026. Es ist eine analytische Lektüre dessen, was passiert, wenn das Wirtschaftsmodell eines Agenten von einer Anbieter-Policy abhing, diese Policy sich ändert, und man entscheiden muss, ob man sich anpasst oder neu baut.

Was ist ein PA und warum das Wort "Persönlich" zählt

Ein Personal Assistant (PA) ist ein KI-Assistent, der eine einzige Person betreut und deren E-Mails, Kalender, Nachrichten und Dokumente in einer dialogorientierten Oberfläche zentralisiert. Im Gegensatz zu einem multi-tenant SaaS läuft ein PA dediziert für einen einzelnen Menschen mit exklusivem Zugriff auf dessen Konten. Diese scheinbar offensichtliche Definition trennt einen gut konzipierten PA von einem verkappten kommerziellen Werkzeug.

Die Unterscheidung ist nicht pedantisch. Ein Mensch im Jahr 2026 kann drei oder vier E-Mail-Adressen haben (die berufliche, die eines Nebenprojekts, die private), zwei oder drei WhatsApp-Nummern, Slack-Konten in verschiedenen Workspaces und ein halbes Dutzend synchronisierter Kalender. Ein PA zentralisiert diese gesamte Fläche und verwandelt sie in eine einzige dialogorientierte Oberfläche, die versteht, wer Du bist und was Dir wichtig ist. Nicht weil er für Dich trainiert wurde, sondern weil er für Dich und nur für Dich läuft, mit Zugriff auf Deine Konten, Deine Threads, Deine Präferenzen.

Das ist das Versprechen eines PA, und es ist dasjenige, das uns dazu gebracht hat, OpenClaw im Januar zu adoptieren. Und es ist auch dasjenige, das uns im April dazu gebracht hat, ihn selbst neu zu bauen, als sich die Ökonomie des Anbieters änderte.

Warum wir OpenClaw im Januar 2026 als Persönlichen KI-Assistenten gewählt haben

OpenClaw ist ein Open-Source Persönlicher KI-Assistent, der Ende 2025 veröffentlicht wurde und sich mit Kanälen wie WhatsApp, Telegram, Slack und mehr als zwanzig Messaging-Plattformen über ein zentrales Gateway und ein System erweiterbarer Skills verbindet. Das Projekt läuft auf Deiner eigenen Maschine (lokal, VPS oder fly.io) und unterstützte bis April 2026 OAuth gegen das Claude Max-Abonnement — das bedeutete, dass alle Interaktionen auf den Max x20-Plan angerechnet wurden, den wir bereits bezahlten. Die Liste der unterstützten Kanäle umfasst unter anderem Discord, Google Chat, Signal, iMessage, Teams, Matrix, Feishu, LINE, Mattermost, Nextcloud Talk, Nostr, Synology Chat, Tlon, Twitch, Zalo, WeChat und WebChat.

Die wirtschaftliche Rechnung Ende Januar war einfach. Wir hatten ein Claude Max x20-Abonnement (etwa 200 US-Dollar pro Monat), das wir bereits intensiv für Claude Code in der Entwicklung nutzten. Einen Persönlichen Assistenten hinzuzufügen, der E-Mails verarbeitet, Slack liest, Telegram-Nachrichten beantwortet und morgendliche Briefings erstellt, würde keine relevanten Zusatzkosten verursachen, da die Limits des Abonnements mehr als ausreichend waren. Für 200 US-Dollar pro Monat hatten wir tagsüber einen Senior-KI-Entwickler und morgens und abends einen Persönlichen Assistenten.

OpenClaw hat im Januar, Februar und März geliefert. Jeden Morgen um acht landete ein Briefing mit meinem Terminkalender und vorrangigen E-Mails in Telegram. Ich konnte dem Bot vom Mobilgerät aus antworten und meine Nachricht ging mit dem gesamten Kontext von E-Mail und Kalender an Claude. Ich konnte von WhatsApp aus fragen "Habe ich um fünf etwas?" und er antwortete korrekt. Ehrlich gesagt war es das nützlichste Produkt der Saison für die tägliche Produktivität.

Aber am 4. April änderte sich alles.

Der 4. April 2026: Was sich genau geändert hat

An diesem Tag kündigte Anthropic an, dass die OAuth-Tokens von Claude Max und Claude Pro mit "Third-Party-harnesses" nicht mehr funktionieren würden — ein Begriff, der in der Branche OpenClaw, Crush, Aider und andere Clients einschließt, die sich bis dahin mit den Abonnement-Credentials des Nutzers an Claude anschlossen. Die Medienberichterstattung war sofort da: TechCrunch, VentureBeat, The Register und Hacker News berichteten über die Nachricht, mit sehr aktiven Threads von Nutzern, die nach der Änderung erhebliche Kostensteigerungen meldeten.

Die offizielle Erklärung von Anthropic führte "den Druck auf unsere Rechen- und Engineering-Ressourcen und den Wunsch, eine breite Nutzerbasis zuverlässig zu bedienen" an. Die technische und wirtschaftliche Lesart ist interessanter.

Ein Claude Max x20-Abonnement ist technisch gesehen ein Vertrag mit elastischen Limits: Anthropic berechnet Dir eine Pauschale und gibt Dir ein großzügiges Nutzungslimit, das die meisten Kunden nicht vollständig ausschöpfen. Dieses Modell funktioniert, wenn die Sitzungen von einem Menschen vor der Tastatur gestartet werden: Die Nutzung ist intermittierend, Pausen sind häufig, und der tatsächliche Verbrauch liegt weit unter der Obergrenze. Wenn Du einen autonomen Multi-Channel-Agenten zwischen den Menschen und das Modell stellst — wie OpenClaw es tut — steigt der Verbrauch auf sehr vorhersehbare Weise: Jede eingehende Nachricht löst einen Aufruf aus, jede Antwort einen weiteren, und 24 Stunden am Tag gibt es Traffic, selbst wenn der Mensch schläft.

Multipliziert mit der geschätzten weltweit installierten Basis von OpenClaw waren die Compute-Kosten für Anthropic innerhalb des Abonnement-Preises nicht tragbar. Die Lösung des Anbieters war, beide Welten zu trennen: Claude.ai, Claude Code und Claude Cowork bleiben weiterhin von Max/Pro abgedeckt, aber alles, was über Third-Party-harnesses läuft, wird jetzt über "Extra Usage" zum API-Preis abgerechnet.

Für einen Nutzer wie uns, der zwischen 300 und 500 Interaktionen pro Tag mit dem PA verarbeitete (Briefings, E-Mails, Triage, Antworten vom Mobilgerät), stieg die neue projizierte Rechnung mit Extra Usage von "in den 200 US-Dollar des Max enthalten" auf etwa 800-1.200 US-Dollar zusätzlich pro Monat. Das war nicht tragbar. Es war auch nicht zu rechtfertigen, da dieselbe Arbeit weiterhin locker in den Max-Plan gepasst hätte, wenn wir sie direkt aus Claude Code heraus ausgeführt hätten.

Die Frage war dann: Wie bringt man einen Multi-Channel Persönlichen Assistenten dazu, innerhalb von Claude Code zu laufen?

Claude Code vs OpenAI Codex als Motor für Deinen Persönlichen Assistenten

Die erste Versuchung war, OpenClaw zu einem anderen Anbieter zu migrieren. OpenClaw selbst unterstützt OAuth gegen ChatGPT und Codex, und Peter Steinberger — der Schöpfer des Projekts — hatte im Februar angekündigt, dass er zu OpenAI wechselt. Den Assistenten auf ein ChatGPT Pro-Abonnement oder einen Codex-Plan laufen zu lassen, war technisch eine Frage des Wechsels des authentication profile.

Wir haben diesen Weg aus drei Gründen verworfen.

Erstens, die Modellqualität für die Aufgaben, die uns wichtig sind. Zum heutigen Zeitpunkt gaben uns die Anthropic-Modelle (insbesondere Opus 4.7) bei der E-Mail-Triage, der Zusammenfassung von Slack-Threads und der Extraktion von Kalenderinformationen konsistent bessere Ergebnisse als GPT-5 beim gleichen Prompt. Das ist keine generische Meinung — wir haben es im März evaluiert, indem wir dieselben Briefings durch beide Anbieter laufen ließen und die Ausgaben qualitativ verglichen, ohne formale publizierbare Methodik, aber mit konsistenten Kriterien, die vom selben Reviewer angewendet wurden. Das Fazit für unseren Use Case (E-Mail-Verwaltung auf Spanisch und Katalanisch, mit Fachvokabular einer Agentur) war klar zugunsten von Anthropic. Dein Ergebnis kann variieren — wir empfehlen Dir, vor der Wahl eines Anbieters Deine eigene Evaluierung mit Deinen eigenen Prompts durchzuführen.

Zweitens, Lock-in mit einem Anbieter, der gerade einseitige Policy-Änderungen demonstriert hatte. Wenn Anthropic OAuth für Dritte mit fünfzehn Tagen Vorankündigung schließen konnte, konnte jeder andere Anbieter dasselbe tun. Die Lektion war nicht "wechsle den Anbieter", die Lektion war "verknüpfe Deine kritische tägliche Infrastruktur nicht mit fremden Entscheidungen über Abrechnungsmodelle". OpenClaw zu OpenAI zu verschieben, hätte das Symptom behandelt, ohne die Ursache zu bekämpfen.

Drittens, und das Wichtigste: Claude Code war bereits im Stack. Wir benutzten es täglich zum Programmieren mit KI in der Agentur. Es hatte angeschlossene MCP-Server. Es wusste, wie man unsere Datenbanken liest, Skripte ausführt, in die Produktion deployt. Wenn wir den Persönlichen Assistenten statt als separates Projekt als "einen weiteren Use Case" von Claude Code behandelten — mit seinem eigenen CLAUDE.md, seinen eigenen MCPs, seinen eigenen Befehlen — konnten wir die gesamte Infrastruktur absolut wiederverwenden. Und das Wichtigste: Dieser Use Case war weiterhin durch das Max x20-Abonnement abgedeckt, da Claude Code ein first-party-Produkt von Anthropic ist und kein Drittanbieter.

Die Entscheidung wurde an einem Nachmittag getroffen. Der Projektname: PA, direkt und wörtlich.

Architektur des Persönlichen Assistenten mit Claude Code und MCP Servern

Der PA läuft in einem eigenen Verzeichnis (~/Dev/PA) mit einer einfachen, aber bewussten Struktur. Es ist keine geschlossene Anwendung: Es ist eine Sammlung von Python-Skripten, Claude-Code-Konfigurationen und einem Telegram-Bot, die über das Betriebssystem miteinander kommunizieren. Die Philosophie ist das Gegenteil von OpenClaw, das alles in einem monolithischen Gateway integriert. In PA tut jedes Teil eine Sache, und der Klebstoff ist Unix.

Die Basis: Claude Code als dialogorientierter Motor

Claude Code ist das Gehirn. Kein Chatbot, keine API, sondern das vollständige Anthropic-CLI, das im "Projekt"-Modus mit einem dedizierten Verzeichnis und seiner eigenen CLAUDE.md-Datei läuft, die Persona, Standardsprache (in unserem Fall Katalanisch) und die obligatorische Bestätigungsregel vor dem Senden von E-Mails oder dem Erstellen von Terminen definiert. Diese Regel ist nicht verhandelbar: Der PA berührt nie etwas, ohne vorher zu fragen.

Jedes Mal, wenn wir mit dem PA interagieren, sei es per Terminal, über einen geplanten Befehl oder über den Telegram-Bot, läuft im Inneren eine claude -p-Sitzung mit persistentem Kontext. Das bedeutet, dass das Gedächtnis des Assistenten nicht in einem willkürlichen externen Speicher lebt: Es lebt im eigenen Session-Flow von Claude Code, mit denselben Cache- und Reinjection-Garantien, die wir in der Entwicklung nutzen.

Die Konnektoren: MCP für alles Externe

Um auf die Außenwelt zuzugreifen, verwendet der PA MCP — Model Context Protocol —, den offenen Standard, den Anthropic 2024 veröffentlicht hat und der 2026 zur gemeinsamen Sprache der KI-Agenten geworden ist. Wenn Du verstehen möchtest, was MCP ist und warum es so wichtig ist, geht der Artikel WebMCP: Deine Website bereit für KI-Agenten auf die technischen Details ein. MCP ist das Stück, das es Claude Code ermöglicht, sich mit Unternehmenssystemen über LLM-Integration zu verbinden, ohne maßgeschneiderte Konnektoren für jeden Dienst neu schreiben zu müssen.

Im Fall des PA sind die aktiven MCP-Konnektoren:

• Gmail MCP: E-Mails lesen, verfassen, senden aus den verschiedenen Adressen derselben Person (das berufliche Agenturkonto, das private Konto, das Konto eines Nebenprojekts). Lesen immer; Schreiben nur mit Bestätigung.
• Google Calendar MCP: Terminkalender abfragen, Termine erstellen und verschieben. Auch mit Bestätigung.
• Google Drive MCP: Suche und Lektüre von Dokumenten auf Anfrage. Nur Lesen.
• Slack MCP: DMs und Erwähnungen lesen, mit Bestätigung antworten.

Alle diese Konnektoren sind von Drittanbietern, werden aktiv gewartet und authentifizieren sich über das eigene OAuth jedes Dienstes. In keinem Fall übergeben wir dem PA direkt die Credentials — es sind die MCP-Server, die die Authentifizierung verwalten, und wir autorisieren den Zugriff lediglich einmalig während des Setups über den Browser.

Die blinden Flecken von MCP: IMAP-E-Mail und Telegram

MCP deckt die Google + Slack-Oberfläche ab, lässt aber zwei wichtige Lücken für einen Assistenten, der "persönlich" sein soll: die Unternehmens-E-Mail über IMAP (der eigene E-Mail-Server eines Unternehmens, nicht Gmail) und Telegram-Nachrichten. Für diese beiden Lücken haben wir eigene Python-Skripte geschrieben, die als Brücke zwischen der Außenwelt und Claude Code fungieren.

Der IMAP-Client ist eine Sammlung kleiner Skripte: mail_fetch.py, mail_read.py, mail_send.py, mail_flag.py. Jedes tut eine Sache. Sie authentifizieren sich gegen das Postfach der Firmendomäne, indem sie die Credentials aus dem Keychain von macOS lesen (niemals aus Dateien auf der Festplatte oder persistenten Umgebungsvariablen). Wenn Claude Code die Unternehmens-E-Mail lesen muss, ruft es diese Skripte als Werkzeuge aus der Sitzung heraus auf, genauso wie es einen MCP aufrufen würde.

Der Telegram-Bot ist die interessanteste Komponente von PA. Es ist ein Python-Daemon, der von launchd (dem macOS-Äquivalent von systemd) verwaltet wird, der beim Login startet und sich bei einem Ausfall selbst neu startet. Wenn eine Nachricht vom Mobilgerät beim Bot ankommt, übergibt der Daemon sie an claude -p mit persistenter Sitzung, wartet auf die Antwort und formatiert sie als Telegram-kompatibles Markdown, bevor er sie zurückgibt. Das Ergebnis ist, dass Du mit dem PA vom Mobilgerät aus sprechen kannst wie mit jedem anderen Chatbot, aber darunter wird die Antwort von Claude mit dem gesamten Kontext Deiner E-Mails und Deines Kalenders des Tages generiert.

Die geplanten Briefings: cron + launchd

Zwei geplante Briefings schließen das System ab: eines um 08:00 Uhr ("morning") und eines um 19:00 Uhr ("evening"). Ausgelöst werden sie von cron, das das Skript run_briefing.sh ausführt und ihm den Briefing-Typ übergibt. Dieses Skript startet eine Claude-Code-Sitzung mit einem spezifischen Prompt ("lies wichtige ungelesene E-Mails, konsultiere den Tageskalender, fasse Prioritäten zusammen") und speichert die Ausgabe in briefings/YYYY-MM-DD-morning.md. Wenn der Telegram-Bot aktiv ist, pusht dasselbe Skript das Briefing in den Chat, damit es vor Tagesbeginn auf dem Mobilgerät landet.

Struktur des Repos

Diese gesamte Maschinerie lebt in etwa 20 Python-Dateien plus einer Handvoll Shell-Skripte. Keine Datenbank, kein Backend, kein Docker. Der gesamte Quellcode des PA ist kleiner als eine typische React-Komponente. Dies ist bewusst so: Je weniger Code, desto weniger Wartung; und je weniger Abstraktion, desto einfacher ist das Debugging, wenn etwas kaputt geht. Diese Entscheidung ist konsistent mit dem, was wir unseren Kunden in LLMOps: Sprachmodelle in der Produktion verwalten empfehlen — operative Komplexität tötet Agenten mehr als Modellkomplexität.

OpenClaw vs PA: der ehrliche Vergleich

Es ist kein Wettbewerb. OpenClaw ist weiterhin ein vollständigeres Produkt, mit mehr Kanälen, einer aktiven Community und einer klaren Produkt-Roadmap. Wenn uns 2026 jemand fragt "Ich will einen Persönlichen Assistenten mit WeChat, LINE, iMessage und Discord gleichzeitig", ist die ehrliche Antwort "Schau Dir OpenClaw an". Für den Fall "Ich will WhatsApp + Telegram + E-Mail + Kalender + Slack, laufend auf meinem Claude Max, mit Code, den ich auditieren und modifizieren kann", lautet die Antwort PA.

Die Wahl zwischen dem einen und dem anderen ist fundamental eine Entscheidung darüber, wie viel Kopplung Du mit einem externen Anbieter willst. OpenClaw bietet Dir mehr Out-of-the-box-Funktionen im Austausch dafür, dass Du von den OAuth-Policies von Anthropic oder OpenAI abhängig bist. PA bietet Dir weniger Funktionen, aber mit der Gewissheit, dass Dir, solange Du Claude Max bezahlen kannst und der Gmail-Dienst weiterhin MCP anbietet, nichts Externes über Nacht den Assistenten entziehen kann.

Bauen wir Deinen? Wir entwerfen und entwickeln maßgeschneiderte Persönliche KI-Assistenten für Fachleute und Führungskräfte. → Entwicklung von KI-Agenten

Alternative zu OpenClaw 2026: Wann es Sinn ergibt, Deinen eigenen PA zu bauen

Wir werden bereits mit einer gewissen Häufigkeit gefragt, ob wir maßgeschneiderte PAs für Kunden bauen würden. Die kurze Antwort ist ja, und wir beginnen gerade, es als Teil der Dienstleistungen der Entwicklung von KI-Agenten anzubieten. Die lange Antwort erfordert Differenzierung, für wen es Sinn ergibt, einen PA zu bauen, und für wen es ein Übermaß ist.

Wann es Sinn ergibt, einen PA zu bauen:

• Für einen Fachmann, der bereits täglich mehr als 80 E-Mails manuell über mehrere Konten hinweg verarbeitet und 30-45 Minuten pro Tag der Triage widmet.
• Für jemanden, der Claude Code bereits in der Entwicklung verwendet und ein Max-Abonnement hat, sodass die Grenzkosten des Assistenten effektiv null sind.
• Für Rollen, die 24/7-Verfügbarkeit erfordern (Gründer, Führungskräfte, selbständige Anwälte, Senior-Berater), die aber aus Kosten- oder Diskretionsgründen nicht die Anstellung eines menschlichen PA rechtfertigen können.
• Für diejenigen, die vollständige Kontrolle über die Daten wollen: Der PA sendet E-Mails oder Kalender nicht an Drittanbieter-Server außerhalb der des LLM selbst.

Wann es NICHT Sinn ergibt:

• Für einen Angestellten, der bereits innerhalb von Gmail/Outlook arbeitet und dessen Unternehmen nicht erlauben würde, ein externes LLM mit dem Firmenkonto zu verbinden. Die Barriere hier ist politisch und sicherheitsrelevant, nicht technisch — wobei in diesem Szenario ein Projekt für Enterprise RAG auf kontrollierter Infrastruktur die richtige Antwort sein kann.
• Für Agenturen, die "einen PA, der alle Kunden verwaltet" wollen — das ist kein PA, das ist ein multi-tenant SaaS, und der Architekturansatz muss radikal anders sein.
• Für diejenigen, die noch kein Claude Max-Abonnement oder Äquivalent haben: Die wirtschaftliche Rechnung ändert sich stark, wenn pay-as-you-go-API bezahlt werden muss.
• Für diejenigen, die einen unfehlbaren Assistenten erwarten. Der PA kann in seinem aktuellen Zustand gelegentlich eine E-Mail in der Triage verlieren oder einen Kalendertermin falsch interpretieren. Die Regel der Bestätigung vor Aktionen ist genau dafür da, uns gegen solche Fehler abzusichern.

Die umfassendere Lektion, unabhängig davon, ob Du Deinen PA baust oder nicht, ist eine andere: KI-Agenten hängen wirtschaftlich vom Abrechnungsmodell des Anbieters ab, und dieses Modell kann sich ändern. Anthropic hat es am 4. April geändert. OpenAI hat seines seit dem Start von ChatGPT Pro mehrfach geändert. Google passt seines regelmäßig an. Jede Agent-Architektur, die Du jahrelang verwenden willst, muss dieses Risiko berücksichtigen, und die Antwort ist nicht technisch — sie ist strategisch. Dünne und entkoppelte Schichten zwischen Deiner Logik und dem Anbietermodell zu bauen, ist das, was es Dir ermöglicht, in 48 Stunden zu pivotieren, wenn sich die Policy ändert.

Bei Kiwop nennen wir das "Anbieter-resistente Agenten". Das ist keine Methodik mit kommerziellem Namen: Es ist eine Designform, die sich in drei Regeln zusammenfassen lässt. Erstens: Der Klebstoff zwischen den Teilen ist eigener Code, niemals ein Framework von Drittanbietern. Zweitens: Die Prompts und Flows sind in Deinen Dateien, nicht in einem SaaS. Drittens: Du kannst das Modell mit einer einzigen Konfigurationsdatei wechseln, ohne den Rest des Systems anzufassen. PA erfüllt alle drei. Wenn Anthropic morgen eine weitere Tür schließen würde, würde uns die Brücke zu OpenAI oder Google wenige Commits und eine Stunde Testing kosten, da das gesamte Engineering drumherum (MCPs, IMAP-Skripte, Telegram-Bot, launchd) modellagnostisch ist.

Häufig gestellte Fragen

Was ist die beste Alternative zu OpenClaw 2026?

Die beste Alternative hängt vom Use Case ab. Für diejenigen, die bereits ein Claude Max-Abonnement haben, ist die wirtschaftlichste Option, einen eigenen Persönlichen Assistenten auf Claude Code + MCP zu bauen (null Grenzkosten). Für diejenigen, die ein fertiges Produkt bevorzugen, bleibt OpenClaw gültig, indem sie "Extra Usage" von Anthropic bezahlen oder den OAuth auf ChatGPT/Codex umstellen. Für regulierte Unternehmensumgebungen empfehlen wir die Bewertung von On-Premise-Lösungen oder einem Enterprise-RAG-Projekt auf kontrollierter Infrastruktur.

Kann ich OpenClaw weiterhin mit meinem Claude Pro- oder Max-Abonnement nutzen?

Nein. Seit dem 4. April 2026 funktionieren die OAuth-Tokens von Claude Pro und Claude Max nicht mehr mit OpenClaw und anderen Third-Party-harnesses. OpenClaw funktioniert weiterhin, aber Du musst die Nutzung separat über Extra Usage von Anthropic (API-Tarife) oder über das OAuth-Abonnement von OpenAI (ChatGPT/Codex) bezahlen. Für Kunden, die ein hohes Volumen verarbeiteten, war der Kostenanstieg, der von der Community gemeldet wurde, erheblich.

Was ist MCP (Model Context Protocol)?

MCP ist der offene Standard, den Anthropic Ende 2024 veröffentlicht hat, damit Sprachmodelle sich einheitlich mit Werkzeugen, Datenbanken und externen APIs verbinden können. 2026 wird er von den wichtigsten KI-Clients unterstützt — einschließlich Claude Code, Cursor, Windsurf und anderen — und die Liste der verfügbaren MCP-Server (Gmail, Calendar, Drive, Slack, Linear, GitHub, Notion, etc.) wächst wöchentlich. Der PA verwendet MCP als primären Zugangsweg zu Gmail, Google Calendar, Google Drive und Slack.

Wie viel kostet es, einen eigenen PA zu bauen?

Wenn Du bereits ein Claude Max x20-Abonnement (etwa 200 USD/Monat) hast, sind die Grenzkosten aus Sicht des KI-Modells null. Die Bauzeit, wenn Du es selbst von Grund auf machst, beträgt etwa 20-30 Stunden, verteilt über eine Woche. Wenn Du es an eine Agentur auslagerst, hängt es vom Umfang ab (welche Kanäle, welche MCP-Integrationen, ob Sprache erforderlich ist oder nicht), aber für den in diesem Artikel beschriebenen Standardumfang des PA schätzen wir zwischen 4.000 und 7.000 Euro für den Aufbau und eine sehr geringe nachfolgende Wartung.

Warum Claude Code und nicht OpenAI Codex?

Claude Code passt aus zwei sehr konkreten Gründen besser zum Persönlichen-Assistenten-Modell. Erstens war die Qualität von Opus 4.7 bei Aufgaben der E-Mail-Triage und Kalenderverwaltung in unseren internen Tests im März 2026 besser als die von GPT-5 (qualitative Bewertung, keine formale publizierbare Methodik). Zweitens ist Claude Code ein first-party-Produkt von Anthropic und weiterhin vom Max-Abonnement abgedeckt, während die Verwendung von Codex von innerhalb unseres bereits aufgebauten Stacks eine doppelte Abonnementzahlung bedeutet hätte (Max für die Entwicklung, ChatGPT Pro für den PA) ohne klaren funktionalen Gewinn.

Ist der PA für vertrauliche E-Mails sicher?

Der PA ist so sicher wie der Modellanbieter, mit dem Du Dich verbindest. Im Fall von Anthropic werden verarbeitete E-Mails nicht zum Training von Modellen verwendet (öffentliche Anthropic-Policy Stand 2026), und die Kommunikation ist verschlüsselt. Dennoch impliziert jeder PA, der sensible Inhalte über ein externes LLM verarbeitet, einen Vertrauensakt gegenüber diesem Anbieter. Für regulierte Inhalte (Gesundheit, Recht, Finanzen mit Berufsgeheimnis) empfehlen wir, die spezifischen Bedingungen zu überprüfen und On-Premise-Alternativen in Betracht zu ziehen.

Kann WhatsApp integriert werden?

Zum heutigen Zeitpunkt verfügt WhatsApp nicht über einen offiziellen MCP, und die inoffiziellen Bridges (wie die, die OpenClaw integriert) erfordern die Pflege eines WhatsApp Business API-Kontos oder weniger stabile Techniken. Der PA integriert in seiner aktuellen Version WhatsApp nicht nativ — wir verwenden Telegram aus Stabilitätsgründen als primären mobilen Kanal. Wir evaluieren den WhatsApp Cloud API-MCP von Meta für eine zweite Iteration.

Kann der PA ohne menschliche Aufsicht handeln?

Per Design nicht. Die Regel der obligatorischen Bestätigung vor jeder Schreibaktion (E-Mail senden, Termin erstellen, Slack beantworten) ist der Sicherheitskern des Assistenten. Eine E-Mail sehen, den Kalender lesen, in Drive suchen — das sind alles Leseoperationen und er führt sie ohne Bestätigung durch. Aber senden, erstellen, verschieben, löschen — erfordern immer ein explizites "Ja" vom Menschen. Es ist eine bewusste Architekturentscheidung: Wir bevorzugen einen etwas weniger agilen PA, der aber keine irreversiblen Fehler macht.

Funktioniert diese Architektur unter Windows oder Linux?

Ja, mit Anpassungen. Die Konzepte (Claude Code + MCP + Python-Skripte + Telegram-Daemon) sind portabel. Was sich ändert, ist der Prozessmanager beim Start: Unter macOS verwenden wir launchd, unter Linux wäre es systemd mit User-Units, und unter Windows der Task Scheduler. Der Keychain für IMAP-Credentials hat auch Äquivalente auf anderen Plattformen (Secret Service unter Linux, Credential Manager unter Windows).

Fazit: KI-Agenten und das Anbieter-Risiko

Die Änderung der Anthropic-Policy vom 4. April 2026 hat uns einen Gefallen getan. Sie hat uns gezwungen, uns zu fragen, ob wir ein kritisches Stück unserer täglichen Produktivität weiterhin an ein Drittanbieter-Projekt auslagern wollen, so brillant es auch sein mag, wenn wir alle Teile hatten, um es selbst auf einem Stack zu bauen, den wir bereits beherrschten. Die Antwort, mit zwei Wochen Perspektive, ist klar: Wir wollten nicht. Und wir wollen nicht, für keine kritische Schicht unserer Arbeit.

Die Lektion lautet nicht "Ihr solltet alle Euren PA bauen". Die Lektion ist, dass im Jahr 2026, mit immer leistungsfähigeren KI-Modellen und mit der Konsolidierung von MCP als Integrationsstandard, der Abstand zwischen der Nutzung eines Drittanbieter-Agenten und dem Bau Deines eigenen drastisch kleiner geworden ist. Was im Jahr 2023 ein Team von drei Ingenieuren für drei Monate erfordert hätte, sind heute etwa 500 Zeilen Python und ein Nachmittag Setup. Diese eingerissene Barriere definiert die aktuelle Welle der angewandten KI — und erklärt am besten, warum Software-Agenturen im Jahr 2026 in einer so anderen Position sind als vor zwei Jahren.

Wenn Du darüber nachdenkst, Deinen eigenen Persönlichen Assistenten aufzubauen, oder wenn Du Hilfe beim Bau robuster KI-Agenten für Dein Team oder Dein Unternehmen brauchst, bieten wir bei Kiwop — Digitalagentur spezialisiert auf Softwareentwicklung und angewandte Künstliche Intelligenz für globale Kunden in Europa und den USA — maßgeschneiderte Entwicklung von KI-Agenten und Beratung für Künstliche Intelligenz für Produktionskontexte an. Der hier beschriebene PA ist das beste lebendige Beispiel dafür, wie wir es für uns selbst tun.