Codex CLI zu skalieren bedeutet nicht, eine riesige Maschine zu kaufen. Es bedeutet, jeden Agenten langweilig, isoliert und leicht stoppbar zu halten, wenn er sich verirrt.
Wir sehen meistens denselben Fehler: Eine erfolgreiche Codex-Sitzung wird zu drei, dann zu sechs, und plötzlich ist ein VPS voll mit halbfertigen Branches, versteckten tmux-Panes und Logs, die niemand liest. Die Lösung ist eine Skalierungsform, keine Heldentat.
Mit der Skalierungseinheit beginnen
Die Skalierungseinheit sollte ein Agent-Runner sein: ein Arbeitsverzeichnis, ein Branch, eine Aufgabe, ein Log-Stream. Wenn zwei Agenten denselben Checkout teilen, überschreiben sie sich irgendwann oder führen Tests gegen einen gemischten Zustand aus.
# keep each runner boring and observable
export CODEX_WORKDIR=/srv/agents/$AGENT_NAME
export CODEX_BRANCH=agent/$AGENT_NAME/$TASK_ID
export CODEX_LOG=/var/log/office-claws/$AGENT_NAME.log
export CODEX_TIMEOUT_MINUTES=90Das wirkt einfach, weil es einfach sein sollte. Bevor du mehr VPS-Kapazität hinzufügst, muss jeder Runner vier Fragen beantworten:
- wo liegt der Repo-Checkout?
- welcher Branch besitzt diese Aufgabe?
- wohin gehen die Logs?
- wer darf ihn stoppen?
Parallelität langsam erhöhen
Der billigste Skalierungsfehler ist, zu viele Agenten zu starten, bevor du den Engpass kennst. Codex-CLI-Arbeit stößt meist an eine von vier Grenzen: CPU während Tests, RAM während Builds, Festplatte bei Dependency-Installationen oder menschliche Review-Kapazität nach dem Abschluss.
| Stage | Good default | Watch first |
|---|---|---|
| Kleines Repo, leichte Tests | 1-2 Agenten pro 2GB VPS | RAM und Swap |
| Web-App mit Builds | 1 Agent pro 2GB VPS | Build-Zeit |
| Schweres Monorepo | 1 Agent pro 4GB+ VPS | CPU und Disk-IO |
| Review-lastiger Workflow | weniger Agenten als Reviewer | offene PRs |
Office Claws macht das in der Desktop-App sichtbar, statt dich merken zu lassen, welches Terminal zu welcher Aufgabe gehört. Self-Hosted bleibt bei $4.99/Monat, wenn du dein eigenes DigitalOcean-Konto mitbringst; Managed startet bei $14.99/Monat, wenn wir die VPS-Seite betreiben sollen.
Arbeit nach Risiko aufteilen
Skaliere nicht, indem du denselben Prompt in fünf Agenten kopierst. Skaliere, indem jeder Agent ein anderes Risikoprofil bekommt.
Ein Muster, das hält:
- Safe lane — Doku, Tests, kleine Refactorings, Dependency-Cleanup.
- Medium lane — Feature-Branches mit klaren Akzeptanzkriterien.
- Risky lane — Migrationen, Auth, Billing, Deploy-Skripte, alles mit langsamerem Review.
Lege die riskante Spur auf den ruhigsten Runner. Gib ihr längere Timeouts, weniger gleichzeitige Nachbarn und einen menschlichen Checkpoint, bevor sie produktionsnahen Code berührt.
Wissen, wann ein weiterer VPS nötig ist
Ein größerer VPS ist nützlich, bis er zum gemeinsamen Explosionsradius wird. Wir fügen lieber einen weiteren kleinen Runner hinzu, wenn Isolation wichtiger ist als rohe Geschwindigkeit.
Füge Kapazität hinzu, wenn:
- Tests hinter unabhängiger Arbeit warten
- eine kaputte Dependency-Installation jeden Agenten blockiert
- Logs zu laut sind, um schnell zu debuggen
- die Review-Warteschlange gesund ist, aber Agenten warten
Füge keine Kapazität hinzu, wenn Menschen mit Reviews bereits hinterherhängen. Mehr Agenten erzeugen dann nur mehr abgestandene Branches.
Was als Nächstes kommt
Wenn du Agent-Frameworks vergleichst, beginne mit unserem OpenClaw-vs-Codex-Vergleich. Wenn du bereits weißt, dass die Arbeit repo-förmig ist, gibt dir der Pfad Office Claws for OpenClaw users persistente Codex-Runner, ohne Skalierung in Terminal-Archäologie zu verwandeln.
Unsere Empfehlung ist einfach: Skaliere Codex CLI jeweils um einen Runner, halte jeden Branch isoliert und füge keine Agenten mehr hinzu, sobald Review der Engpass wird.