Deine AI-Agenten gehören NICHT in die Cloud: der Mac mini als Bodenstation

ChatGPT hat jetzt Dots, Claude hat Cloud-Sessions: KI-Agenten, die in der Cloud laufen, während du dich um nichts kümmern musst. Bequem, keine Frage. Und trotzdem mag ich diese Angebote nicht.

Die Gespräche mit deinem Agenten sind dein Kapital, und das gehört auf deine eigene Platte, nicht in eine fremde Cloud. Meine Antwort ist ein Mac mini als immer laufende „Bodenstation": eine Maschine, die dir gehört, eine dedizierte Sandbox, erreichbar von überall. Deine Agenten arbeiten weiter, während du vom MacBook, aus dem Browser oder sogar vom Handy aus zusiehst und eingreifst.

Die Kiste stand zunächst aus einem ganz anderen Grund im Regal: ein aktueller Mac mini M4 mit 32 GB, den ich mir eigentlich für den Clawdbot-Hype (heute OpenClaw) geholt hatte, den eigenen Agenten per Signal vom Handy steuern, das hatte was. Cool war es genau so lange, wie diese Fernsteuerung der eigentliche Reiz war. Seit Claude Code das mit /remote-control von Haus aus kann, hat der Clawdbot für mich viel von seinem Charme verloren, und der mini langweilte sich ohnehin ein wenig (dazu vielleicht ein andermal mehr). Also bekam er eine neue, dauerhafte Aufgabe.

Dieser Artikel zeigt die Idee, die Bausteine und, in How-to-Kästen, wie man sie selbst nachbaut.

🛰️ Der Spitzname für das Setup war schnell gefunden: Ground Control to Major Tom. Der Mac mini ist die Bodenstation, das MacBook die mobile Rakete, die andockt und wieder abhebt.

Inhalt

• Das Problem: Agenten wollen laufen, ich will weg
• Warum nicht einfach die Cloud?
• Deine Chats sind dein Kapital
• Die Architektur: Bodenstation und mobiler Spiegel
• Eine dedizierte Sandbox
• Verbindungsabbrüche überstehen
• Andocken von überall: bis hin zum Handy
• Alles doppelt: immer synchron
• Dienste headless betreiben
• Die Arbeit des Agenten im Browser ansehen
• Praxis: ein Tag mit der Bodenstation
• Wenn man doch mal lokal arbeiten muss
• Ein Prinzip: Erzähl den Agenten nie vom rosa Elefanten
• Fazit: Lohnt sich das?

Das Problem: Agenten wollen laufen, ich will weg

Agentic Coding (agentisches Programmieren) funktioniert anders als ein Chatfenster: Man gibt die Richtung vor, und der Agent liest Code, schreibt Dateien, führt Tests aus und plant selbstständig die nächsten Schritte. Solche Läufe dauern: Minuten, manchmal Stunden. Und genau da beißt sich das mit einem Laptop, den man zuklappt, ins Café trägt oder im Zug in den Ruhemodus schickt.

Auf dem Laptop passiert Folgendes:

• Ich klappe ihn zu → der Prozess schläft ein, der Agent friert mitten im Lauf ein.
• Ich will abends vom Sofa aus nur kurz nachsehen, wie weit er ist, und müsste den Laptop wieder hochfahren.

Das erste Problem lässt sich mit caffeinate -s umgehen: Der Laptop bleibt am Netz einfach an, auch wenn der Deckel zugeklappt ist. Genau so habe ich im Winter und Frühling gearbeitet. Bei sommerlichen Temperaturen wird die Kiste dabei aber schnell viel zu heiß, und ich möchte sie ja noch eine ganze Weile behalten. Ein Laptop, der monatelang durchheizt, ist keine gute Dauerlösung.

Dazu kommt ein Muster, das ich an mir selbst beobachte: Meine besten Ideen habe ich selten am Schreibtisch, sondern unterwegs, beim Gassigehen zum Beispiel. Genau dann will ich dem Agenten kurz etwas zurufen oder nachsehen können, wie er vorankommt, ohne erst nach Hause an den Laptop zurückzukehren.

Die Lösung ist konzeptionell simpel: Der Agent läuft nicht auf dem Gerät in meiner Nähe, sondern auf einer dedizierten Maschine, die nie ausgeht und immer an ist. Das Gerät in meiner Hand ist nur noch ein Fenster darauf.

Warum nicht einfach die Cloud?

An dieser Stelle liegt der Einwand nahe: Genau dafür gibt es doch längst fertige Cloud-Angebote. Dein Agent läuft auf fremder Infrastruktur, immer an, und du musst nichts administrieren. Prinzipiell eine super Sache. Nur: Diese Angebote gefallen mir nicht, und das hat handfeste Gründe. Die folgenden Zahlen und Zitate sind Stand Oktober 2026.

ChatGPT Dots (OpenAI schreibt sie klein). Jeder Dot ist laut OpenAI „frontier intelligence", „Powered by GPT‑6 Astra", und hat „their own cloud computer". Sie rollen „today in ChatGPT to Pro and Business Premium users in eligible markets" aus; Enterprise-Nutzer bekommen eine Beta, wenn der Workspace-Admin sie freischaltet. Ein Dot setzt also ein kostenpflichtiges Abo voraus: „Your first dot is included in your Pro or Business Premium plan at no extra cost." Der erste ist damit inklusive, und „in the future, you'll be able to add more dots, and scale the output of each dot", mehr Agenten und mehr Leistung kosten dann obendrauf. Entscheidend für mich: Der Agent und seine Daten sitzen auf OpenAIs Rechnern, nicht auf meinen.

Claude-Code-Cloud-Sessions. Die laufen in einer von Anthropic verwalteten VM mit, laut Doku, „approximate resource ceilings": „4 vCPUs" und „16 GB of RAM". Das ist mickrig. Und die Doku sagt selbst, was dann zu tun ist: „The VM may stop tasks that need significantly more memory … For workloads beyond these limits, use Remote Control to run Claude Code on your own hardware." Wer also ernsthaft Ressourcen braucht, wird von der Doku ohnehin auf eigene Hardware geschickt. Fair bleibt: „There is no separate compute charge for the cloud VM", und die Cloud-Sessions teilen sich das Nutzungslimit mit deiner übrigen Claude-Nutzung. Zum Klonen von Code braucht es GitHub. Und ja, man kann eine Cloud-Session per Teleport ins eigene Terminal holen, losgelaufen ist sie aber zuerst in der Cloud.

Kommerziell gibt es dasselbe als gemietete Dev-Umgebung (GitHub Codespaces, Coder, Google Cloud Workstations) oder als gehosteten Agenten-Dienst (Devin, Google Jules), abgerechnet laufend pro Compute-Stunde oder Seat (Nutzerplatz).

Nüchtern betrachtet steckt dahinter auch ein handfestes Geschäftsinteresse. Die monatlichen Subscriptions lassen sich kaum weiter anheben, ohne dass die Kunden jede Preiserhöhung hassen. Ein zusätzlicher Cloud-Dienst, abgerechnet pro Nutzung oder pro Seat, ist aus Anbietersicht eine elegante neue Einnahmequelle. Das ist meine Lesart, aber sie erklärt den Drang in die Cloud ziemlich gut.

So unterschiedlich diese Angebote sind, sie teilen den einen Haken, der mich am meisten stört: Deine Gespräche mit dem Agenten liegen dann irgendwo in einer fremden Cloud. Und genau die sind mir zu wertvoll dafür.

Deine Chats sind dein Kapital

Die Frage, die mich am meisten beschäftigt: Wo liegen die Chats? Das Wissen, das ich mit dem Agenten angehäuft habe, die Entscheidungen, die Begründungen, die Sackgassen, das ist mein Kapital. Ich will es zwischen mehreren Maschinen synchronisieren, ich will es sichern können, und ich will noch in einem Jahr nachschauen können, was ich damals besprochen habe. Nichts davon geht gut, wenn es in einer fremden Cloud liegt.

Claude Code legt seine Gesprächsprotokolle lokal unter ~/.claude/projects/ ab, eine .jsonl-Datei pro Session. Im selben Projektordner liegt außerdem der Unterordner memory/, in dem sich der Agent dauerhaft Notizen macht. Genau dieser Fundus soll mir erhalten bleiben, auf meiner eigenen, verschlüsselten Platte.

⚠️ Unbedingt anpassen: cleanupPeriodDays. Claude Code räumt die Gesprächsprotokolle unter ~/.claude/projects/ standardmäßig nach 30 Tagen weg. Wer sie als Nachschlage-Fundus behalten will, setzt in ~/.claude/settings.json den Wert cleanupPeriodDays deutlich höher, bei mir auf 365. Sonst löscht ein aufgeräumter Rechner die Historie.

Auf der Bodenstation liegen diese Dateien auf meiner Platte und werden auf mein MacBook gespiegelt (wie genau, zeige ich im Abschnitt Alles doppelt). Damit kann ich eine Session, die ich auf dem mini begonnen habe, auf dem MacBook fortsetzen: Kontext, Verlauf, alles da.

Für mich ist deshalb jedes reine Cloud-Angebot ein Showstopper. Diese Haltung zieht sich durch mein ganzes Setup; auch beim Auto-Account-Switch ging es mir genau darum, die Kontrolle über die eigenen Daten zu behalten.

Die Architektur: Bodenstation und mobiler Spiegel

Zwei Maschinen, ein gemeinsamer Nenner:

Der entscheidende Trick: Beide Rechner nutzen denselben Benutzernamen und damit dasselbe Home-Verzeichnis /Users/<name>. Alle Pfade, alle Repos, alle Keys und, wie wir gleich sehen, alle Agenten-Sessions liegen auf beiden Maschinen unter identischen Pfaden. Das macht den Übergang mühelos: Was auf dem mini gilt, gilt eins zu eins auf dem MacBook Pro.

Streng genommen kommt eine dritte Rolle dazu: Geräte, die nur als Terminal arbeiten, kein eigenes Dev-Environment, keine Datenkopie, nur ein Fenster in die Bodenstation. Das ist einerseits das Handy (per Termux), andererseits ein kleines MacBook, das ich ausschließlich als Terminal dabeihabe, ich nenne es schlicht „Mac Terminal". Voller Spiegel ist damit nur das große MacBook Pro: Es kann beides, eigenständig arbeiten oder bloß als Fenster dienen. Alles andere ist reines Terminal.

Der mini steht ohne Monitor und ohne Tastatur bei meiner übrigen Haustechnik, neben NAS, Fritzbox, dem dicken Switch und dem ganzen Kabelsalat, den man sonst so im Netz hängen hat. Erreichbar ist er nur übers Netzwerk. Das klingt nach Einschränkung, ist aber der halbe Trick: Was headless läuft (ohne Bildschirm und ohne sichtbare Fenster), läuft auch, wenn niemand eingeloggt ist.

Warum ausgerechnet ein Mac mini? Für diese Rolle ist er fast perfekt: Apple Silicon liefert richtig viel Leistung fürs Geld, er ist winzig und passt in jede Ecke, läuft absolut leise (den Lüfter höre ich im Alltag nie) und ist so stromsparend, dass der Dauerbetrieb kaum auf der Rechnung auffällt. Im Leerlauf zieht er nur eine Handvoll Watt. Genau das, was man für eine Maschine will, die nie ausgeht.

Eine dedizierte Sandbox

Neben den Chats ist das der zweite Grund für eine eigene Maschine. Der mini ist nicht mein Alltags-Laptop, auf dem ich alles Mögliche mache, sondern eine Maschine mit genau einem Zweck: dem Programmieren. Auf der Bodenstation läuft nur, was für die Arbeit nötig ist. Sonst bin ich dort nirgends eingeloggt, nicht einmal mein üblicher Passwort-Manager ist installiert.

Damit ist der ganze Mac mini im Grunde eine Sandbox: Was ein Agent dort anrichten könnte, bleibt eng begrenzt. Für Agenten, die zunehmend selbstständig Befehle ausführen, ist das ein beruhigender Gedanke, und er kostet mich nichts extra, weil die Maschine ohnehin nur diese eine Aufgabe hat.

Verbindungsabbrüche überstehen

Der Umzug auf eine entfernte Maschine handelt sich allerdings ein Problem ein, das es lokal nie gab: Die Verbindung dorthin kann abreißen. Ein WLAN-Wechsel (Büro → Bahn → Zuhause) genügt, und ein normales SSH-Terminal ist tot. Die Antwort darauf ist tmux, ein Terminal-Multiplexer. Statt meine Programme direkt in der SSH-Sitzung zu starten, laufen sie innerhalb von tmux auf dem mini. Reißt die Verbindung, läuft tmux, und alles darin, einfach weiter. Beim nächsten Andocken hänge ich mich wieder an, als wäre nichts gewesen. tmux ist der zentrale Baustein in diesem Setup, erst dadurch überstehen die Agentenläufe alles, was zwischen mir und dem mini passieren kann.

Zwei Dinge machen das komfortabel:

• Auto-attach beim Login: Jede interaktive Anmeldung landet automatisch in derselben Session (main). Ich muss nichts von Hand starten.
• tmux-continuum speichert das Layout alle 15 Minuten und stellt es nach einem Reboot wieder her.

Wichtig zu verstehen: tmux rettet die Verbindung, nicht den Strom. Ein Reboot beendet die laufenden Prozesse trotzdem, aber das Layout und die Fenster kommen zurück, und die Agenten-Session lässt sich fortsetzen (dazu gleich mehr).

🛠️ Selbst nachbauen: Auto-attach in ~/.zshrc

# Beim interaktiven Login automatisch in die tmux-Session 'main'
if [[ -z "$TMUX" && -n "$SSH_CONNECTION" ]]; then
  tmux attach -t main 2>/dev/null || tmux new -s main
fi

Der wichtigste Reflex danach: mit Ctrl-b d detachen (läuft weiter!), nie mit exit raus, das killt das Fenster.

Andocken von überall: bis hin zum Handy

Für den Zugriff setze ich durchgehend auf mosh (Mobile Shell), zu Hause wie unterwegs, immer derselbe Befehl. So muss ich nie zwischen ssh und mosh überlegen oder umschalten.

Und mosh ist großartig. Es ist das bessere SSH für alles, was nicht am festen Kabel hängt: Wechselt das Netz oder bricht es kurz weg, lebt die Verbindung roaming-fest weiter, kein eingefrorenes Terminal, kein „broken pipe". Getippte Zeichen erscheinen sofort per lokalem Echo, auch bei mieser Latenz im ICE. Netz weg, Netz wieder da, mosh macht ohne Neuverbinden einfach weiter. Unterbau ist ein ganz normaler SSH-Login mit Key-Auth, kein Passwort.

Einen Haken hat mosh: Es braucht freie UDP-Ports (zwischen 60000 und 61000) und überträgt nur den sichtbaren Bildschirm, der Scrollback bleibt lückenhaft. Den Verlauf hält in meinem Setup ohnehin tmux.

Und wie kommt das Handy von unterwegs überhaupt an die Kiste zu Hause? Angefangen habe ich mit dem WireGuard-VPN der Fritzbox, inzwischen läuft alles über Tailscale (ein Mesh-VPN auf WireGuard-Basis). Der Grund: Tailscale kommt auch mit IPv6 und ständig wechselnden Anschlüssen bestens klar, du erreichst die Bodenstation zuverlässig, egal aus welchem Netz. Man kommt immer nach Hause.

Und die Kür: Vom Handy. Auf Android läuft die Terminal-App Termux, darin mosh, darin tmux, darin der Agent. Damit komme ich notfalls von überall an die rohe Session heran.

Diesen direkten Terminal-Weg nutze ich aber selten. Meist arbeite ich auf dem Handy bequemer über die Remote-Control-Funktion der Claude-App. Bis man drin ist, gehört ein kleines Ritual dazu: ein neues tmux-Fenster öffnen (Ctrl-b c), claude starten, mit /rc die Remote-Steuerung freigeben und die Session mit /rename benennen. Dann erst wechsle ich in die App und tippe dort weiter. Beim ersten Mal fummelig, aber man gewöhnt sich dran.

🛠️ Selbst nachbauen: ein Kurzname, immer mosh In ~/.ssh/config einen Alias anlegen (mosh nutzt ihn genauso wie ssh):

Host mini
  HostName mini    # LAN-Name oder der Tailscale-Name des mini
  User deinbenutzer

Dann genügt von überall derselbe Befehl:

mosh mini

Von außen sorgt ein Mesh-VPN wie Tailscale dafür, dass mini immer erreichbar ist, auch über IPv6.

📱 Handy-Kniff (Termux): Termux hat keine Strg-Taste. Sie liegt auf Leiser (Volume-Down), also Vol-Down + C für Ctrl-C, Vol-Down + R für Ctrl-R. Die Extra-Tastenzeile (ESC/CTRL/TAB/Pfeile) blendet man mit einem Wisch nach oben ein. Dankt mir später! 😄

Alles doppelt: immer synchron

Bis hierher könnte ich von überall auf den mini zugreifen. Der Clou ist aber, dass mein großes MacBook Pro ein vollwertiger Spiegel ist: Es hat dieselben Dateien und kann jederzeit die Arbeit des mini übernehmen, auch offline. Warum mir das so wichtig ist? Bei einem kompletten Stromausfall will ich nicht mit heruntergelassenen Hosen dastehen, großer Mac und mini sind ja immer synchron. Ganz nebenbei wirkt dieser Spiegel wie ein permanentes, sekundenscharfes Backup. Geiler Scheiß, mit einem wichtigen Aber, zu dem ich unten komme.

Dafür sorgt Syncthing, ein Peer-to-Peer-Sync ohne Cloud dazwischen. Es spiegelt bidirektional:

• ~/Work: alle Projekte und Repos
• ~/.claude: die Agenten-Sessions und das memory/-Verzeichnis aus dem Abschnitt Deine Chats sind dein Kapital. Erst der Sync macht sie auf beiden Maschinen verfügbar.
• ~/Shots: Screenshots (praktisch, gleich mehr dazu)

Gesynct wird Quellcode, keine Artefakte. node_modules, dist, build, target und Caches stehen in .stignore und werden pro Maschine neu gebaut (npm ci, cargo build). Kompilierte Binaries über Rechner zu kopieren bricht sowieso irgendwann am Library-Linking, lieber sauber neu bauen.

🛠️ Selbst nachbauen: Artefakte vom Sync ausschließen (.stignore)

node_modules
dist
build
target
.angular
.next
// Caches nach Bedarf ergänzen

Faustregel: Was ein npm ci oder cargo build in Sekunden wiederherstellt, gehört nicht in den Sync.

Der Screenshot-Trick als Bonus: Weil beide Macs dasselbe Home haben, liegt ein Screenshot unter demselben Pfad auf beiden Rechnern. Ich stelle den macOS-Screenshot-Ordner auf ~/Shots (defaults write com.apple.screencapture location ~/Shots && killall SystemUIServer), mache am MacBook einen Screenshot und ziehe ihn in eine remote laufende Agenten-Session auf dem mini. Der Pfad existiert dort dank Sync ebenfalls, der Agent liest das Bild, obwohl es „auf dem anderen Rechner" entstand.

⚠️ Die eine Disziplin: Vor dem Gerätewechsel „auf grün warten". Wechselt man die Maschine, während Syncthing noch überträgt, riskiert man Konfliktdateien. Kurz prüfen, dass der Sync idle ist, dann ist der Übergang sauber.

⚠️ Und das versprochene Aber: ein Spiegel ist kein Backup. Ein bidirektionaler Sync repliziert eben auch Löschungen und kaputte Dateien originalgetreu. Die neuere Version gewinnt, notfalls auch eine leere. Die Absicherung dagegen ist Syncthings Datei-Versionierung (.stversions): Vor jedem Überschreiben legt sie den alten Stand mit Zeitstempel ab. Und weil diese Historie pro Gerät lokal liegt und nicht mitgesynct wird, hat im Ernstfall die eine Maschine noch, was die andere schon verloren hat. Ein echtes Off-Device-Backup ersetzt das nicht, aber es holt eine verloren geglaubte Chat-Historie zurück.

Dienste headless betreiben

Ein Agent ist nur so gut wie die Umgebung, in der er arbeiten darf. Auf dem mini soll er einen vollständigen Dev-Stack vorfinden: Datenbank, Docker, Browser. Und zwar ohne dass sich jemand am Bildschirm anmeldet. Denn der mini hat gar keinen angemeldeten Desktop.

Drei Bausteine:

FileVault und der Boot. Die Platte ist mit FileVault verschlüsselt. Nach einem Neustart hängt der mini im Pre-Boot-Lock, noch bevor es Netzwerk gibt, ein SSH-Login hilft also nicht. Ich entsperre ihn aus der Ferne über ein KVM-over-IP-Gerät (Keyboard, Video, Mouse) und tippe das Passwort einmal ein. Wie das genau geht, dazu verschlüsselte Backups und eine USV (unterbrechungsfreie Stromversorgung) gegen Stromausfall, steht im Folgeartikel Mac mini Hardening.

Docker ohne Docker Desktop. Docker Desktop braucht einen GUI-Login, auf einer headless Maschine ein K.-o.-Kriterium. Stattdessen läuft colima als System-Dienst (LaunchDaemon), der schon beim Booten startet. Unter der Haube dieselbe Technik wie Docker Desktop (Apples Virtualization.framework), mit Rosetta für Intel-Images, also für den ollen SQL Server, der leider nie nach ARM portiert wurde. Danke, Microsoft. So bekommt der Agent ein docker und docker compose, das einfach da ist.

Ein echter Browser für den Agenten. Über einen selbstgebastelten headless Playwright-MCP-Server kann der Agent eine echte Chrome-Instanz fahren: Seiten öffnen, klicken, Formulare ausfüllen, Screenshots machen. „Headless" heißt hier: kein sichtbares Fenster, kein GPU-/Display-Kontext nötig (--disable-gpu), damit es auf der monitorlosen Kiste stabil läuft.

🛠️ Selbst nachbauen: colima als Autostart-Dienst Einmalig die VM anlegen (schlank halten reicht für die meisten Fälle):

colima start --vm-type vz --vz-rosetta --cpu 6 --memory 4 --disk 60

Damit sie beim Boot ohne Login hochkommt, einen LaunchDaemon unter /Library/LaunchDaemons/ einrichten, der colima start als dein Benutzer ausführt. Container mit restart: always in der docker-compose.yml starten dann automatisch mit.

Diesen Playwright-MCP so einzurichten, dass er unauffällig bleibt, Updates übersteht und nicht in die groben Bot-Filter gerät, ist ein Thema für sich. Den ganzen Weg beschreibe ich im eigenen Artikel:

Die Arbeit des Agenten im Browser ansehen

Der Agent hat das Frontend umgebaut, jetzt will ich es sehen, in einem echten Browser, von meinem Laptop oder Handy aus. Der Dev-Server läuft aber auf dem mini und lauscht dort brav nur auf localhost.

Meine Lösung ist ein nginx-Reverse-Proxy auf dem mini, der genau ein Problem elegant löst: Er macht jeden lokalen Dev-Server im Netz sichtbar, ohne pro Projekt etwas zu konfigurieren. nginx bindet die LAN-IP des mini und schreibt den Host-Header auf localhost um. Dadurch greifen die Host-Prüfungen moderner Dev-Server (Angular, Vite) nicht, und ich muss weder --host 0.0.0.0 setzen noch an allowedHosts herumschrauben. Im Browser tippe ich einfach http://mac-mini.fritz.box:4200, fertig.

🛠️ Selbst nachbauen: nginx-Dev-Proxy (Kern)

server {
  listen 192.168.178.50:4200;     # LAN-IP des mini : Dev-Port
  location / {
    proxy_pass http://127.0.0.1:$server_port$request_uri;
    proxy_set_header Host localhost:$server_port;   # <- entscheidend: 'localhost', nicht die IP!
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;         # Hot Module Replacement (HMR)
    proxy_set_header Connection upgrade;
    # Fallback für Dev-Server, die nur auf IPv6 (::1) lauschen (Node 24 / Angular 22):
    proxy_intercept_errors on;
    error_page 502 504 = @ipv6;
  }
  location @ipv6 { proxy_pass http://[::1]:$server_port$request_uri; proxy_set_header Host localhost:$server_port; }
}

Zwei Fallen aus der Praxis: Es muss localhost im Host-Header stehen (Vite blockt unbekannte Hostnamen mit HTTP 403, „Blocked request“), und neuere Dev-Server binden localhost manchmal nur auf IPv6 (::1), daher der @ipv6-Fallback.

Manche Apps rufen ihr Backend allerdings fest auf http://localhost:PORT, aus dem Browser heraus zeigt „localhost" dann auf mein Gerät, nicht auf den mini, und die API-Calls laufen ins Leere. Für diesen Sonderfall gibt es keinen Proxy-Zauber, aber einen sauberen Trick: einen SSH-Tunnel, der die betreffenden Ports auf den mini spiegelt. Dann stimmt die localhost-Annahme der App wieder.

🛠️ Selbst nachbauen: App mit hartcodiertem localhost-Backend

# Frontend (4200) UND Backend (5001) auf den mini tunneln, dann per localhost öffnen
ssh -N -L 4200:localhost:4200 -L 5001:localhost:5001 mini
# Browser: http://localhost:4200  (nicht die Hostname-Variante)

Aus Sicht des Browsers ist dann alles localhost, genau wie es die App erwartet.

Praxis: ein Tag mit der Bodenstation

Wie fühlt sich das im Alltag an? Ungefähr so:

Gottlos früh, beim Gassigehen. Schlaftrunken mit dem Hund unterwegs lese ich die Mails und sehe, dass irgendein Nightly Build rot ist. Mist. „Claude, bitte fixen!" Am Ende der Runde ist der Build grün. Erstes Erfolgserlebnis des Tages. Schön.

Morgens am Schreibtisch. Ich docke vom MacBook per mosh mini an, lande in tmux, starte in einem Projekt einen Agenten mit einer größeren Aufgabe, sagen wir, eine Testabdeckung nachziehen. Er legt los. Am großen Monitor arbeite ich übrigens immer noch am liebsten: Die Diffs, die Claude Code ständig zeigt, geben einen guten Überblick, was gerade passiert, man hat das Gefühl, die Kontrolle zu behalten.

Mittags unterwegs. Ich klappe das MacBook zu und fahre los. Der Agent? Läuft weiter, er sitzt ja auf dem mini, nicht im Laptop. In der Bahn hole ich das Handy raus, öffne die Claude-App und arbeite auf dem kleinen Bildschirm weiter: Der Agent hat drei von fünf Modulen durch und wartet auf eine Entscheidung, ich beantworte die Rückfrage mit dem Daumen, er macht weiter. Das Kontrollgefühl ist hier geringer, für die Diff-Ansicht muss man eigens drauftippen, aber irgendeinen Tod muss man sterben.

Nachmittags im Café. Das MacBook ist wieder auf, dank Sync sind alle Dateien und die Session-Historie auf dem aktuellen Stand. Ich öffne das umgebaute Frontend im Browser über den Dev-Proxy und schaue es mir an, auf dem echten Bildschirm, nicht im Terminal. Dabei trinke ich einen Iced Matcha Latte … Kleiner Scherz: Ich bin doch nicht im Café wie so ein AI-Influencer. Ich sitze längst wieder im Keller, dort ist es schön kühl, und ich habe drei Monitore.

Abends auf dem Sofa. Kurzer Blick vom Handy, ob die CI durch ist. Ist sie. Merge.

Kein einziges Mal musste der Agent „von vorne anfangen", weil der Akku alle war. Kein zugeklappter Deckel hat ihn pausiert. Das ist der Gewinn: Die Arbeit ist entkoppelt vom Gerät in meiner Hand.

Das war ein bewusst vereinfachtes Beispiel. Die eigentliche Arbeit beginnt nämlich erst bei vielen parallelen Sessions mit ebenso vielen parallelen git-worktrees (mehrere Arbeitskopien desselben Repos nebeneinander, mehr dazu im Worktree-Artikel). Weil ein Frontier-Modell (ein Modell an der aktuellen Leistungsspitze) mit all seinen Unter-Agenten verdammt langsam sein kann (Kommandos wie /simplify oder /code-review mit ordentlich /effort laufen schon mal absurd lange), parallelisiert man fast zwangsläufig. Der ständige Context-Switch und der Mental Load dabei sind nicht zu unterschätzen, aber das hat mit dem Setup nichts zu tun, das hätte man auf einem einzelnen Rechner genauso.

Wenn man doch mal lokal arbeiten muss

Nicht jede Session lässt sich remote fahren, einige funktionieren nur lokal. Bei mir vor allem wohnfunke.app: Die kann nicht im Kabelschrank laufen, denn das „magische" USB-Kabel muss meinen Laptop physisch mit dem Wohnwagen verbinden. (Ich nenne es das magische Kabel, weil es dieses Kabel so nicht im Handel gibt.) Ohne diese Verbindung komme ich nicht an die serielle Schnittstelle des Lichtsteuergeräts.

Und hier ist das Vorgehen richtig nice: Ich beende die Session auf dem mini mit /exit, warte, bis das ~/.claude-Verzeichnis durchgesynct ist, und starte Claude auf dem Laptop mit --resume neu, schon bin ich wieder in derselben Unterhaltung. Dann sage ich einfach: „Du bist jetzt im Wohnwagen, verbinde dich mit dem Lichtsteuergerät." Claude macht artig weiter und nutzt ab da meine lokale Peripherie.

Der ganze Kontext bleibt erhalten, nur der Unterbau wechselt vom mini auf den Laptop, die Bodenstation reicht die Session an die Rakete weiter, diesmal weil die Rakete am Kabel hängen muss.

Ein Prinzip: Erzähl den Agenten nie vom rosa Elefanten

Ein Kniff, der sich mit der Zeit herausgeschält hat: Ich halte genau eine Session, die das ganze Setup kennt, meine Ground-Control-Session. Sie hilft bei Problemen, nimmt die Meldungen der anderen Sessions entgegen (etwa wenn wirklich mal etwas durch den Wechsel der Arbeitsstation passiert ist) und kennt als Einzige die volle Wahrheit.

Alle normalen Arbeits-Sessions wissen davon nichts. Sie merken nicht, dass sie eben noch auf Rechner A liefen und jetzt auf Rechner B, dank identischem Home und identischen Pfaden sieht für sie alles exakt gleich aus. Und das ist volle Absicht.

Denn: Erzähl den Agenten nie vom rosa Elefanten. Sobald eine Session weiß, dass sie auf einem exotischen Setup sitzt, erklärt sie sich jedes kleine Problem in den End-to-End-Tests zuerst genau damit: „liegt bestimmt am Sync", „bestimmt der Proxy", „bestimmt die entfernte Maschine". Weiß sie nichts davon, sucht sie die Ursache wieder dort, wo sie meistens sitzt: im Code. Den Elefanten sehen darf nur Ground Control.

Fazit: Lohnt sich das?

Ein Mac mini im Regal, ein bisschen Unix-Handwerk, und plötzlich hat man eine persönliche, immer laufende Basis für agentisches Arbeiten, die man von überall bedient. Die Bausteine sind alle Standard und quelloffen: tmux, mosh, Syncthing, colima, nginx. Nichts davon ist exotisch; das Besondere ist die Kombination.

Ein Nebeneffekt, den ich unterschätzt hatte: Ein dedizierter Rechner ohne GUI und ohne sonstige Prozesse hat spürbar mehr nutzbare Power. Auf meinem normalen Arbeitsrechner kratzte der Arbeitsspeicher bei gleicher RAM-Bestückung ständig am Limit. Swapping ohne Ende. Super nervig, wenn man überlegen muss, welchen Prozess man jetzt abschießt; den Agenten will man ja ganz sicher nicht unterbrechen. Auf dem mini ist dieses Problem einfach weg.

Die Grenzen des Setups:

• Es braucht Pflege. Headless-Betrieb, FileVault-Remote-Unlock, Autostart-Dienste, das ist einmal Einrichtungsaufwand und gelegentlich Debugging.
• Sicherheit ist Pflicht, kein Bonus. Zugriff ausschließlich übers VPN, Key-Auth, FileVault an. Ein always-on Rechner ist nur so vertrauenswürdig wie sein Zugang.
• Reboots kosten laufende Prozesse. tmux rettet das Layout, nicht den Zustand mitten im Lauf. Für lange Läufe plane ich Neustarts entsprechend.

Und wie machen es eigentlich alle anderen? Die meisten lassen ihren Agenten (Claude Code, Cursor, GitHub Copilot, Antigravity) lokal auf dem Laptop laufen. Kein Keller, kein Server. Für die meisten ist das genau richtig. Wer den Schritt in die Cloud geht, gibt dafür die Kontrolle über seine Daten und seine Chats aus der Hand, und genau das will ich nicht.

Mein Setup zielt auf den Sonderfall: immer an, von überall, und trotzdem komplett bei mir. Bei mir sind es allein die Max-Subscription von Claude und Hardware, die ich ohnehin hatte. Und weil der Agent jederzeit erreichbar ist, reize ich deren großzügige Limits inzwischen gnadenlos aus, das gelingt kaum so gut, wenn man an einen physischen Ort gebunden ist.

Für mich überwiegt der Gewinn deutlich: Agenten, die weiterarbeiten, während ich lebe und mich bewege, die Chats auf meiner eigenen Platte, eine Maschine, die mir gehört. Deine Maschine, deine Schätze. Du hast die Kontrolle und nicht die Cloud.

Übrigens: Beim Schreiben dieses Artikels hatte ich den Song permanent im Ohr. Bitte sehr, hier ist dein neuer Ohrwurm, Ground Control to Major Tom:

Falls der Player nicht lädt: direkt auf YouTube ansehen.

Fragen, Feedback, eigene Basteleien? Immer her damit, ich freue mich über jede Nachricht. Und wenn genug Interesse besteht, mache ich das Ground-Control-Repo mit der kompletten Konfiguration öffentlich. Ein Wort von dir genügt.

Neugierig auf agentisches Arbeiten in der Praxis? In den Workshops von agentic.schule und angular.schule zeigen wir, wie moderne KI-Agenten die tägliche Entwicklung verändern.