> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/de/2026/w41-personal-ai-practice-tools-engineering-and-runtime-environments.md).

# W41-Side Projects: Werkzeuge, Engineering und die Wahl zwischen lokalem Rechner und Cloud

10. Oktober 2026 · Überarbeitet am 13. Oktober

Die langen Ferien zum Mittherbstfest und Nationalfeiertag verbrachten wir in Aranya Jinshanling. Das eignet sich gut für einen Familienausflug. Nach der Rückkehr blieben einige freie Tage, und auch die erste Arbeitswoche danach war nicht besonders voll. So konnte ich einige Vorhaben voranbringen.

Rückblickend war letzte Woche einiges dabei: die KI-Laufzeitumgebung pflegen, am Familienfinanzprojekt weiterarbeiten, eine seit Jahren genutzte Aboverwaltung ersetzen, die Zuverlässigkeit des Netzwerkproxys verbessern und automatisierte Abläufe für eigene Medien durchlaufen lassen. Zusammengenommen brachten mich diese Projekte auch dazu, meine KI-Nutzung in diesem Jahr noch einmal anzusehen.

Ich hatte bereits darüber geschrieben, persönliche Angelegenheiten als technische Projekte zu organisieren. Sobald echte Daten darin liegen, reale Konten angebunden sind und alles dauerhaft laufen soll, tauchen viele zuvor wenig beachtete Fragen auf.

## Die KI-Laufzeitumgebung pflegen

Mein Mac Studio steht im Büro. Nach Feierabend und am Wochenende lasse ich ihn häufig aus der Ferne arbeiten. Vor den Nationalfeiertagsferien wollte ich ausprobieren, ob er über zehn und mehr Tage verfügbar bleiben würde, sodass ich ihn unterwegs jederzeit für meine Vorhaben nutzen könnte.

Nach zwei oder drei Tagen klappte das schon nicht mehr richtig. Inzwischen hatten Claude und OpenAI Modelle aktualisiert, einige Clients brauchten manuelle Updates, Anmeldungen liefen ab und verlangten neue Autorisierung. Auf dem Rechner liefen außerdem Aufgaben mit Chrome-Automatisierung; auch der Arbeitsspeicher brauchte Pflege. Jedes Problem für sich war klein. Unterwegs genügte aber ein blockiertes Glied, damit der Rest nicht weitergehen konnte.

Am ersten Tag nach meiner Rückkehr verbrachte ich deshalb viel Zeit mit dem Aufräumen der Umgebung und holte zugleich die Modellentwicklungen der Ferien nach.

**Strom und Netzwerk allein garantieren nicht, dass diese Arbeitsumgebung jederzeit nutzbar ist.**

Danach ergänzte ich tägliche Verwaltungsaufgaben für die KI-Runtimes. Einerseits prüfen sie die in den Werkzeugen konfigurierten Modelle und verfolgen Updates innerhalb derselben Modellreihe. Andererseits prüfen sie die Versionen von Codex, Claude Code, Gemini und anderen Runtimes, damit Konfigurationen und Werkzeugversionen nicht immer weiter auseinanderlaufen.

Früher kümmerte ich mich darum meist erst bei Problemen. Da ich heute gleichzeitig von immer mehr KI-Werkzeugen abhänge, wird ihre Wartung zur festen Aufgabe. Gerade aus der Ferne werden Autorisierungen und Updates, die vor Ort einen Klick kosten, zu echten Blockaden.

## Ein Datenprojekt für die Familienfinanzen

Das Finanzprojekt hatte ich bereits erwähnt und begonnen. Diesmal trieb ich es vier bis fünf Tage lang vor allem mit Claude konzentriert voran. Es ist ungefähr zu achtzig Prozent fertig. Der Aufwand lag deutlich über meiner ersten Erwartung.

Ich möchte die gesamte finanzielle Situation der Familie in einem dauerhaft pflegbaren Projekt abbilden. Es soll Analysen, Überwachung und Rückblicke ermöglichen und bei Bedarf verschiedene Diagramme erzeugen. Bei der Umsetzung zeigte sich, dass Diagramme und Analysen nur ein Teil sind. Die darunterliegenden Daten und Regeln machen den größten Aufwand aus.

Beim Datenschutz denkt man etwa zuerst daran, Beträge zu verbergen. Genauer betrachtet dürfen auch Stückzahlen nicht einfach öffentlich werden: Multipliziert mit dem öffentlichen Nettoinventarwert lassen sie den Marktwert erkennen. Manche Verhältniszahlen verraten zusammen mit anderen Angaben ebenfalls Dinge, die nicht öffentlich sein sollten. Ein einzelnes Feld wirkt oft harmlos; kombiniert sieht es ganz anders aus.

Ein weiteres Beispiel ist die Datenrichtigkeit. Wann ein Ereignis stattfand, wann es erfasst wurde und ob ein Wert beobachtet, berechnet oder geschätzt ist, muss getrennt dokumentiert werden. Wird ein alter Eintrag korrigiert, bleibt die Beziehung zur Korrektur erhalten, statt den alten Inhalt einfach zu überschreiben. Scheitert der Quellenabruf, darf nicht beiläufig ein vollständig wirkendes Ergebnis entstehen. Fehlende Daten dürfen auch nicht mit null aufgefüllt werden.

Diese Regeln müssen schließlich im Programm durchgesetzt werden. Vor einem Commit prüft das Projekt nun die vorgesehenen Inhalte. Es erkennt außerdem das tatsächliche Dateiformat, damit eine geänderte Endung nicht dazu führt, dass ungeeignete Rohdatentabellen im Repository landen. Prompt-Anforderungen brauchen Unterstützung durch Programme. Sonst hängt jede Ausführung allein davon ab, ob das Modell sich zuverlässig genug erinnert.

Einige Fragen hatte ich anfangs gar nicht gesehen. Sie kamen erst in wiederholten Reviews mit Claude zum Vorschein. In der zweiten Hälfte ging viel Zeit in Grenzfälle, zusätzliche Prüfungen und weitere Reviews. Auch ein persönliches Projekt darf diese Arbeit nicht auslassen, wenn es reale Familiendaten enthält, nur weil es wenige Nutzer hat.

Meine Erwartungen sind konkret: Bei den vierteljährlichen Datenupdates möchte ich weniger wiederholen, erklären können, warum sich der Stand gegenüber dem letzten Mal geändert hat, und wissen, woher eine Schlussfolgerung stammt.

**Wenn die Fakten gut gepflegt sind, lassen sich Analysen und Visualisierungen jederzeit neu erstellen.**

## Geräteübergreifende Aboverwaltung

Die Aboverwaltung entstand im Vergleich sehr schnell. Ich wollte ausprobieren, ob ich mit wenig Aufwand ein stark an meine Gewohnheiten angepasstes, plattformübergreifendes Werkzeug mit nahezu nativem Nutzungserlebnis bauen kann.

Zuerst zeichnete ich die Abodaten in der alten Software als Bildschirmvideo auf und ließ ChatGPT die Migrationsdaten daraus extrahieren. Auch hier waren Details wichtig: Übernommen wurden nur aktive Abos, deren Detailansicht ich tatsächlich geöffnet und gezeigt hatte. Die Währungen mussten ebenfalls stimmen. Google One war in Neuen Taiwan-Dollar erfasst, der Telekommunikationsvertrag in Macau-Pataca. Wenn diese Grundfelder falsch sind, helfen später auch schöne Berechnungen nicht.

Danach kamen Oberfläche, Synchronisierung und Bereitstellung. Das Werkzeug läuft auf ChatGPT Sites und nutzt dessen Datenbankfunktionen. Es lässt sich auf Handy, PC und Mac öffnen. Unter iOS verwende ich es als Web-App; das tatsächliche Erlebnis ist deutlich besser als erwartet.

Auch die Weiterentwicklung war direkt. Wenn die Oberfläche nicht meinen Erwartungen entsprach, markierte ich die Stelle, testete ein wenig, ergänzte Anforderungen und ließ weiter anpassen. Für ein persönliches Werkzeug mit klar begrenzten Funktionen passt diese Lieferform gut.

So wurde die seit vielen Jahren genutzte Abo-App ersetzt. Bei fertiger Software musste ich immer Organisationsformen hinnehmen, die mir nicht gefielen. Jetzt kann ich nach meinen Gewohnheiten gestalten, und Änderungen kosten wenig. Daraus muss kein Produkt für alle werden. Schon die gute Lösung meines eigenen Problems hat Wert.

**Das ließ mich auch Web-Apps neu betrachten. Für leichte Werkzeuge und Produktivitätsanwendungen bieten Webseite, Hosting und Datenspeicher zusammen bereits ein ziemlich vollständiges Erlebnis. Mit Apps wie Scriptable lassen sich Systemerinnerungen und Widgets per Skript ergänzen. So kommen die Webdaten an die alltäglichen Einstiegspunkte auf dem Telefon.**

Für eine Aboverwaltung reicht eine Web-App mit einigen nativen Ergänzungen bereits aus, um sehr günstig ein stark angepasstes, nahezu natives Erlebnis zu schaffen. Ein persönliches Werkzeug rechtfertigt nicht automatisch die Entwicklung und Pflege mehrerer Clients.

## Die Zuverlässigkeit des Netzwerkproxys verbessern

Weitere ein bis zwei Tage widmete ich vor allem der Zuverlässigkeit des Netzwerkproxys.

Viele meiner Arbeits- und Produktivitätswerkzeuge hängen inzwischen am internationalen Internet. Sobald ein Anbieter zeitweise ausfällt, leiden Entwicklung, Recherche und Modellaufrufe gleichzeitig. Nach einigen Blockaden wollte ich das gründlich angehen.

Ich entwickelte das Proxykonfigurationsprojekt weiter. Mein eigener Taiwan-Knoten hat erste Priorität, ein Taiwan-Knoten des kommerziellen Anbieters A ist die erste Reserve, einer des Anbieters B die letzte Option. KI-Verkehr läuft ausschließlich über Taiwan. Inländischer, betrieblicher und privater Netzwerkverkehr geht nach den bisherigen Regeln weiterhin direkt. Damit sind Ersatzwege klar, ohne wegen eines einzelnen Werkzeugs den gesamten Rechner über dieselbe Strecke zu schicken.

Die Umschaltung übernimmt der Proxykern. Er prüft alle 30 Sekunden aktiv die Erreichbarkeit, mit drei Sekunden Timeout pro Versuch. Fällt die eigene Verbindung aus, gehen neue Verbindungen an die Reserve. Nach der Erholung erhält die eigene wieder Vorrang. Bestehende Streamingverbindungen lassen sich nicht auf einen anderen Server verschieben und dort fortsetzen; die App muss erneut versuchen. Diese Ebene löst die Frage, ob die nächste Verbindung wieder arbeiten kann.

Ich führte außerdem 468 Runden von HTTPS-Erreichbarkeitsprüfungen durch. Die eigene Verbindung war in 465 Runden erfolgreich, Anbieter A in 459. Mindestens eine der beiden funktionierte in 468 von 468 Runden. In dieser Stichprobe ergänzten sich ihre Ausfälle tatsächlich.

Unter der Annahme voneinander unabhängiger Ausfälle ergibt sich aus den gemessenen Fehlerquoten eine geschätzte gemeinsame Verfügbarkeit von etwa 99,9877 Prozent.

**Unter dieser Annahme erreicht die grobe Schätzung ein 4N-Niveau.**

Das ist eine Näherung aus einer kurzen Stichprobe und der Annahme unabhängiger Ausfälle. Gemeinsame Netzwerkausfälle sowie Lücken durch Erkennung und Umschaltung sind nicht berücksichtigt. Sie ist auch keine gemessene Jahresverfügbarkeit.

Die Abnahme muss der realen Arbeit nahekommen. Eine erreichbare Webseite oder eine erfolgreiche API-Antwort beweist nicht, dass lange Modellgenerierungen stabil laufen. Ich prüfte reale Modellausgaben getrennt über die eigene und die Ersatzverbindung; beide bestanden fast zweiminütige kontinuierliche Streams. In einer isolierten Umgebung simulierte ich Ausfall und Erholung der eigenen Verbindung und prüfte Übernahme sowie Priorität nach der Wiederherstellung. Die tatsächlich laufenden Server wurden dabei nicht abgeschaltet.

Danach band ich den eigenen Knoten an ein festes Abonnement an. Seine Verbindungsparameter werden über Cloudflare verteilt, der eigentliche Proxyverkehr geht weiterhin zum eigenen Server. Der Mac ist bereits angebunden; für Handy und Apple TV gibt es entsprechende Abonnementformate. Import und Aktualisierung müssen auf den Geräten noch einzeln abgenommen werden. Ändern sich später die Knotenparameter, muss nicht jedes Gerät eine neue Konfiguration erhalten. Der Abonnementdownload selbst läuft über die kommerzielle Reserve, damit bei einem Ausfall des eigenen Knotens die aktualisierten Parameter weiterhin erreichbar bleiben.

Anschließend ergänzte ich die koordinierte Verwaltung durch zwei Macs. Sie synchronisieren Verwaltungsaufzeichnungen verschlüsselt. Zu jedem Zeitpunkt darf nur einer Verwaltungsaktionen ausführen, damit sie Abonnements nicht gleichzeitig ändern oder Anfragen doppelt senden.

Nach dem Aufbau des eigenen Knotens überlegte ich auch, ihn an arbeitsfreien Tagen freizugeben und an Arbeitstagen neu aufzubauen, um Kosten zu sparen. Bei der Umsetzung kamen jedoch die vertrauenswürdige Identität neuer Server, der Abgleich nach Zeitüberschreitungen bei Erstellungsanfragen, Zustandswiederherstellung und geräteübergreifende Synchronisierung hinzu. Schließlich verwarf ich die periodische Freigabe und Neuerstellung. Die bestehende Instanz läuft dauerhaft weiter, mit automatischer Umschaltung der Verbindungen.

**Ein komplexeres Gesamtsystem ist nicht unbedingt die derzeit günstigste Wahl, nur um etwas Instanzlaufzeit zu sparen.**

## Ein praktischer Medienworkflow

Ein weiterer Versuch heißt „AI in Wort und Bild“. Ich möchte allgemein verständliche Bild-Text-Inhalte zu KI veröffentlichen und zunächst sehen, wie weit dieser Ansatz trägt.

Mit Multica organisierte ich einen kleinen Multi-Agent-Squad, der Themenwahl, Abgleich mit Originalquellen, Redaktion, Bilder, Prüfung, menschliche Bestätigung und Veröffentlichung verbindet. Inzwischen gibt es offiziell veröffentlichte Inhalte; der Ablauf endet nicht mehr beim Entwurf. Beim WeChat-Kanal bleibt meine Bestätigung am Handy erhalten, und nach dem Publizieren wird das veröffentlichte Ergebnis kontrolliert.

Dabei treten viele kleine Fragen auf: Wiederholt sich das Thema? Erzählt der Artikel nur eine Veröffentlichungsankündigung nach? Passen Bild und Text zusammen? Hat die Plattform wirklich gespeichert? Einzeln sind das keine großen technischen Probleme. Für eine vollständige Lieferung müssen sie aber alle bearbeitet werden.

Der Ablauf funktioniert, die Inhalte selbst stehen noch am Anfang. Es gibt wenige Themen, und die Auswahl wirkt noch etwas unbeholfen. Für Aussagen über Reichweite und Likes fehlt derzeit eine Grundlage. Mich interessiert stärker, ob sich später Ausführungsprotokolle und Inhaltswirkung verbinden lassen: rückblickend verstehen, was sich zu schreiben lohnt und wie man es so ausdrückt, dass Leser es lesen möchten, und damit die nächste Themenwahl verbessern.

Es bleibt viel anzupassen. Ich möchte die derzeitige Koordination zunächst beibehalten und den Ablauf selbst flüssiger machen. Diesen kleinen Versuch weiter zu beobachten ist interessanter, als schnell ein Urteil darüber zu fällen.

## Betriebsgrenzen zwischen lokalem Rechner und Cloud

Diese Arbeiten machten mich aufmerksamer dafür, wo ein persönlicher digitaler Assistent eigentlich läuft. Solche Anwendungen werden immer zahlreicher. Ein Assistent kann in der Cloud Aufgaben empfangen, Werkzeuge aufrufen und für mich handeln. Ob eine vollständig cloudbasierte Ausführungsumgebung produktive Arbeit ebenso leisten kann wie ein eigener lokaler Rechner, hängt aber von konkreten Bedingungen ab.

Zuerst von der Sicherheit der Zugangsdaten. Für echte Arbeit braucht der Assistent Anmeldestatus, Zugangsdaten und Tokens. Wenn sie in die Cloud gehen, muss klar sein, wo sie liegen, wer sie lesen kann, wie weit ihre Befugnisse reichen und ob sie sich widerrufen lassen. Auch lokale Zugangsdaten brauchen Schutz. Ihren Speicherort und Einsatzbereich kann ich aber direkt verwalten. In der Cloud brauche ich ebenso klare Grenzen vom Anbieter.

Zweitens von zuverlässiger Speicherung. Persönliche Projekte hinterlassen Code, Dateien, Ausführungsprotokolle und langfristigen Zustand. Ob diese dauerhaft erhalten bleiben, die Freigabe von Ausführungsressourcen überstehen und beim nächsten Auftrag fortgesetzt werden können, entscheidet über die tatsächliche Nutzbarkeit. Nach einer einzelnen Ausführung ein Ergebnis zurückzusenden und langfristig ein Projekt zu pflegen sind zwei verschiedene Anforderungen.

Drittens vom Netzwerkzugang. Der Netzausgang einer Cloudumgebung kann bestimmte Websites oder Dienste einschränken. Auf meinem Rechner lassen sich manche Zugangsprobleme mit der vorhandenen Proxykonfiguration lösen. In der Cloud muss einzeln geprüft werden, ob dieselben Ziele und Anmeldestatus erreichbar bleiben. Internetzugang bedeutet nicht Zugang zu allen Ressourcen, die eine Aufgabe braucht.

Schließlich von Entwicklungs- und Testumgebung. Für iOS-Apps beispielsweise läuft meine derzeitige Cloud-Ausführungsumgebung auf Linux. Xcode und der iOS-Simulator lassen sich dort nicht direkt ausführen. Kann ein Assistent Code schreiben, besitzt aber weder die passende Toolchain noch den Simulator, ist seine Abnahme eingeschränkt. Für solche Tests brauche ich weiterhin einen Mac oder eine Umgebung mit gleichwertiger macOS-Toolchain.

**Wie weit persönliche digitale Assistenten produktiv arbeiten können, hängt auch davon ab, ob Zugangsdaten, Speicher, Netzwerk und Toolchain ihre Arbeit dauerhaft tragen.**

Ich hoffe, diese Anwendungen bauen die fehlenden Fähigkeiten weiter aus. Erst wenn Dateien erhalten bleiben, Rechte steuerbar sind, Zielressourcen erreichbar bleiben und geschriebene Programme tatsächlich laufen und getestet werden können, lässt sich ihnen ein langfristiges Projekt übertragen.

Meine Aboverwaltung liegt derzeit in der Cloud und ist auf Handy und Computer direkt nutzbar. Aufgaben mit lokalen Zugangsdaten, Netzwerkkonfiguration und Mac-Toolchain laufen weiterhin auf meinem Rechner.