Aufgaben, die nicht auf einen Laptop passen
Die meiste Codex-Arbeit ist kurz. Eine Frage stellen, zwanzig Sekunden warten, einen Patch bekommen. Das macht man hundertmal am Tag, und ein Laptop kommt damit gut zurecht.
Die Aufgaben, die das Laptop-Modell sprengen, sehen anders aus. Ein nächtliches Refactoring, das fünfzig Dateien umschreibt und nach jedem Durchlauf die Testsuite ausführt. Ein Batch-Review, bei dem der Agent jeden offenen PR liest, eine Zusammenfassung schreibt und sie in Slack postet. Ein Dokumentations-Sweep, der zwei Stunden durch die Codebase läuft und eine frische Referenz produziert. Das sind keine Chat-Turns — das sind Jobs, deren Laufzeit in Stunden gemessen wird.
Der Laptop scheitert bei allen auf die gleiche Weise. Sie schließen den Deckel, wechseln das WLAN, oder der Akku stirbt im Zug, und der Codex-CLI-Prozess geht mit. Der Kontext, den der Agent aufgebaut hatte, ist weg. Sie kommen morgens zurück und finden ein totes Terminal und nichts, was die sechs Stunden wert gewesen wäre, die Sie ihn laufen lassen wollten.
Was „langlaufend" für Codex tatsächlich bedeutet
Eine Codex-Aufgabe ist langlaufend, wenn einer der folgenden Punkte zutrifft:
- Die Laufzeit überschreitet eine typische Laptop-Session. Alles über ~2 Stunden läuft in Schlaf, Pendeln oder ein Meeting mit geschlossenem Deckel
- Die Aufgabe muss Netzwerkwechsel überleben. Café → Zuhause → Büro bedeutet, dass sich die Laptop-IP dreimal ändert; jeder Wechsel kann die Codex-Session trennen
- Sie hängt von Zustand ab, den der Agent vorher aufgebaut hat. Hat der Agent eine Stunde damit verbracht, Dateien zu lesen und zusammenzufassen, kostet der Verlust dieses Kontexts die Stunde — nicht nur die letzte Anfrage
- Sie wollen, dass der Agent auf externe Ereignisse reagiert. GitHub-Webhooks, Cron-Trigger, eine Datei, die in S3 landet — all das wartet nicht, bis Sie den Laptop wieder aufklappen
Sobald eine Aufgabe eine dieser Linien überschreitet, brauchen Sie einen Host, der online bleibt, wenn Sie es nicht sind.
Vier Muster, die stundenlang tragen
Jeder langlaufende Codex-Workflow, den wir bei Office Claws fahren, passt in eines von vier Mustern. Keines davon funktioniert auf einem Laptop, alle funktionieren auf einem VPS.
| Muster | Typische Laufzeit | Was auf einem Laptop abbricht |
|---|---|---|
| Nächtliches Refactoring | 4–10 Stunden | Schlaf, Akku, Hotel-WLAN |
| Batch-Review / Triage | 30 Min. – 2 Std. | Deckel zwischen Meetings zu |
| Kontinuierlicher Watcher | Läuft 24/7 | Alles, was kein Server ist |
| Geplanter Job | Minuten, aber um 03:00 | Sie schlafen |
Der rote Faden: Der Agent muss erreichbar sein, laufen und Kontext halten — in einem Moment, der nichts damit zu tun hat, wann Sie gerade tippen.
Das VPS-Setup, das wirklich funktioniert
Bei Office Claws lebt jeder Agent auf seinem eigenen DigitalOcean-Droplet, in etwa zweieinhalb Minuten aus einem vorgefertigten Snapshot provisioniert. Codex CLI ist installiert, in Ihr ChatGPT-Plus- oder Pro-Abo eingeloggt und über Tailscale erreichbar. Das Droplet kostet 4 $/Monat auf dem Self-Hosted-Plan (4,99 $/Monat für die App, 2,99 $ für unsere ersten 100 Nutzer) oder ist in 14,99 $/Monat auf Managed enthalten.
Der Workflow, den wir für lange Aufgaben nutzen, sieht so aus:
# From your laptop, over Tailscale — connects to the droplet
ssh office-claws-agent
# Start the task in a persistent session so it survives the SSH drop
tmux new -s refactor
codex "rewrite backend/services/* to use the new context shape; \
after each file, run go test ./...; if tests fail, revert that file"
# Detach: Ctrl+b, then d. Close the laptop. Go to bed.Am nächsten Morgen tmux attach -t refactor, und das komplette Log wartet. Der Agent ist die ganze Nacht gelaufen. Ihr Abo hat die Tokens abgedeckt. Das Droplet hat Sie für die acht Stunden etwa zwölf Cent gekostet.
Drei Fehler, die das Setup verschenken
Die meisten Ausfälle, die wir gesehen haben, clustern sich um dieselben drei Dinge:
- Codex in einer reinen SSH-Session statt in tmux oder screen laufen lassen. Die SSH-Verbindung bricht ab und Codex stirbt mit ihr. Eine lange Aufgabe immer in eine persistente Session wickeln — tmux, screen, oder ein systemd-Dienst, wenn sie vollständig unbeaufsichtigt laufen soll
- Die VPS-Platte volllaufen lassen. Lange Refactorings erzeugen Logdateien und Test-Artefakte. Eine volle Platte killt die Aufgabe in Stunde sechs. Legen Sie einen
cron-Job an, der~/.codex/logswöchentlich kürzt - Rate Limits ignorieren. ChatGPT Plus deckelt nach Nachrichtenzahl in einem rollierenden Fenster. Eine Aufgabe, die die API pausenlos hämmert, trifft das Limit um Stunde drei. Für wirklich harte Nachtarbeit auf Pro wechseln — die 200 $/Monat werden selbst bei aggressiven Workloads fast nie ausgeschöpft
Wann ein geplanter Job die bessere Wahl ist
Nicht jede lange Aufgabe muss interaktiv sein. Hat der Job keine Mehrdeutigkeit — „jeden Montag um 06:00 die Commits der letzten Woche zusammenfassen und in Slack posten" — sparen Sie sich den tmux-Tanz und legen ihn als Cron-Eintrag auf dem Droplet an. Codex CLI läuft headless problemlos mit einem Prompt auf stdin. Der VPS wird zum Scheduler, Sie bekommen eine E-Mail bei Fehler, und es gibt nichts, woran man sich wieder anhängen müsste.
Wir behandeln das vollständige Muster für Batch- und geplante Workloads in einem separaten Guide, aber die Kurzfassung: Wenn der Prompt jedes Mal derselbe ist und die Ausgabe maschinenlesbar, gehört er in Cron, nicht in ein Chatfenster.
Was das für Ihre Arbeitsweise ändert
Sobald lange Aufgaben keinen Laptop mehr brauchen, verschiebt sich die Frage. Sie fragen nicht mehr „Habe ich jetzt Zeit, das laufen zu lassen?", sondern „Will ich das Ergebnis bis morgen früh oder bis Ende der Woche?". Der Agent wird ein Hintergrund-Worker, kein Vordergrund-Werkzeug. Der Laptop wird zur Schnittstelle für etwas, das bereits lief, bevor Sie ihn geöffnet haben.
Das ist der ganze Pitch dafür, Codex auf einen VPS zu stellen. Die Token-Rechnung bleibt gleich. Das Modell bleibt gleich. Was sich ändert, ist, dass die Uhr weiterläuft, wenn Sie aufhören.
Weiterlesen
- Codex-Abo vs. API: Welche Rechnung ist wirklich günstiger? — warum ein 20-$-Plus-Abo auf einem VPS für die meisten Workloads die API schlägt
- AI-Agenten auf einem VPS verwalten, ohne ein Ops-Chaos zu erzeugen — die operative Seite, um langlaufende Agenten gesund zu halten
- Self-Hosted vs. Managed — den Office-Claws-Plan wählen, der zu einem langlaufenden Workflow passt