Codex CLI RAM-Test:
Welche Projekte werden mit 8, 16 und 32 GB fertig?

Stand 9. September 2026 steht in der offiziellen Codex-Installationsanleitung weiter: macOS 12+ / Ubuntu 20.04+ (Windows über WSL2), Speicher 4 GB Minimum, 8 GB empfohlen. Die CLI selbst ist ein natives Rust-Binary und liegt im Idle oft nur bei ein paar hundert MB. Wie bei Claude Code und Cursor ist nicht der Agent-Prozess teuer, sondern die lokale Toolchain, die er sofort aufweckt. Wer eher die Kaufstufen eines anderen Agents braucht, nimmt unseren Claude-Code-Test 16 GB / 24 GB / 64 GB; wer einen selbst gehosteten PR-Review-Dienst plant, landet in einem anderen Text: OpenCode Review 4 GB / 8 GB / 16 GB. Hier geht es um eine Frage: Welche Projektklasse bringt Codex CLI auf 8 / 16 / 32 GB wirklich zu Ende?

Offizielle 4 GB / 8 GB garantieren nur den Start

„8 GB empfohlen“ als „8 GB schreiben jedes Projekt“ zu lesen, ist der häufigste Fehlschluss. Die offizielle Tabelle beantwortet: Überleben OS + Node/Runtime-Abhängigkeiten + Codex-Prozess? Sie deckt diese reale Arbeit nicht ab:

• Im Repo liegen node_modules, DerivedData, .next oder zehntausende Quelldateien — der Agent liest per Pfad und sucht per Tool;
• Sie lassen ihn „diesen fehlgeschlagenen CI-Job reparieren“, dann führt er npm test, pytest oder xcodebuild aus;
• Playwright / Chrome DevTools / XcodeBuild-MCP sind an, und jede Session kann einen weiteren Node-Prozessbaum ziehen;
• Parallel laufen Browser, IDE und lokaler Dev-Server — nichts davon steckt in „4 GB Minimum“.

Die Inferenz sitzt bei OpenAI, eine größere GPU hilft lokal nicht. Der Arbeitsspeicher entscheidet, ob die Toolchain überhaupt stehen kann. Deshalb fühlt sich dieselbe offizielle Zeile in einem Skript-Repo und in einem iOS-Monolithen wie das Gegenteil an.

Die Speicherrechnung: CLI, Index, Kindprozesse, MCP

Der residente Speicher einer interaktiven Session ist vier Rechnungen. Getrennt gesehen wissen Sie, was Sie kappen — statt sofort RAM nachzukaufen.

Aus der Community kommen bereits laute Signale: Auf einem lokalen Repo von etwa 1.2 GB ist der anonyme RSS der nativen Codex-Runtime auf 18 GB bis 29 GB gestiegen, bis das cgroup den Prozess gekillt hat (openai/codex#21233). Die zweite Klasse ist der MCP-Lebenszyklus: Session hängt oder Sub-Agent ist fertig, aber npx / Playwright / xcodebuildmcp bleiben stehen — eine 16-GB-Maschine wird von Waisen in den Swap gezogen. Deshalb gilt „32 GB ist immer sicher“ auch nicht: Sie kaufen nur längere Reaktionszeit.

Das unterscheidet diesen Text von „welchen Rechner soll ich kaufen“-Artikeln: Wir buchen nach Projekt-Toolchain, nicht nach Chip-Codenamen.

So haben wir gemessen: drei Caps, sechs Projekte

Dieselbe Codex CLI (ChatGPT-Login, Standard-Coding-Modell), sechs feste Aufgaben, jeweils bei 8 / 16 / 32 GiB verfügbarem Speicher. Unter Linux systemd-run --scope -p MemoryMax=; unter macOS Speicherdruck und Swap in der Aktivitätsanzeige. Vier Kennzahlen: Peak-RSS von Codex plus Kindprozessen, ob aggressives Paging beginnt, ob der Task fertig wird, Wall-Clock-Zeit.

Die sechs Projekte sind Arbeit, die Entwickler einem Agenten wirklich geben — kein Hello World:

1. P0 Leere Session: Kaltstart codex, eine Frage zur Repo-Struktur, keine Tests.
2. P1 Kleines Python-CLI: rund 180 Quelldateien, einen Parse-Bug fixen, pytest -q.
3. P2 Mittleres Next.js: rund 800 Quelldateien, eine API-Route ergänzen, npm test (ohne E2E-Browser).
4. P3 P2 + Docker Compose: Postgres + App-Container; Codex ändert eine Migration und startet den Stack neu.
5. P4 iOS-App: mittleres UIKit-Projekt, eine UI-Stelle ändern und xcodebuild (ohne das volle Simulator-Paket).
6. P5 P2 + Playwright-MCP: Browser-MCP an, Komponente gegen die gerenderte Seite anpassen.

Die Zahlen sind Peak-Intervalle, keine Kalibrierung. Im Umfeld bleiben OS und ein schlankes Terminal; nicht 40 Chrome-Tabs. Laufen bei Ihnen noch Slack, Figma und drei Dev-Server, schätzen Sie jede Stufe in der Tabelle eine höher.

Querschnitt: fertig, festgefahren, gekillt

Zwei Dinge aus der Tabelle festhalten. Erstens: P2 liegt schon an der 8-GB-Decke — nicht weil Codex 8 GB frisst, sondern weil node-Testprozesse plus Dateilesen den Rest-Idle auffressen. Zweitens: P4 / P5 scheitern selten daran, dass „das Modell kein Swift kann / die Seite nicht klickt“. Compiler und Browser erdrücken die Maschine, bevor der Agent den letzten Schritt sieht.

Welche Projekte auf 8 GB laufen

8 GB ist die offizielle „Empfehlung“ und die Realität vieler Ultrabooks, Einstiegs-VPS und älterer Unified-Memory-Macs. Die Projekte, die dort fertig werden, haben ein klares Profil: wenig Quelldateien, keine Container, kein IDE-Simulator, Tests bleiben im Prozess.

Was Sie 8 GB zumuten können

• Skripte, Crawler, kleine Tools, Single-File-Refactors;
• Text- und Config-Änderungen an Doku-Sites (Astro / VitePress / Docusaurus);
• kleines Flask / Express / FastAPI, Tests mit pytest oder wenigen Node-Unit-Tests, ohne Browser;
• Einmal-Patches mit codex exec: ein paar Dateien lesen, ändern, sofort beenden — kein interaktives TUI;
• Review-Kommentare, Commit-Messages, Fehlerlogs in Patch-Entwürfe übersetzen.

Was Sie auf 8 GB direkt lassen

• jeden Full-Stack, der Docker Desktop / Compose braucht;
• Xcode, iOS-Simulator, Android-Emulator;
• Playwright, Cypress, Chrome-DevTools-MCP;
• volle Testläufe in großen pnpm- / npm-Monorepos;
• „VS Code plus ein Dutzend Tabs, und Codex ändert das Repo“ — das System paget zuerst. Sie denken, der Agent wird langsam; in Wahrheit arbeitet die Disk als RAM.

Der wirksamste 8-GB-Einsatz ist nicht „das große Repo ertragen“, sondern große Repos in kleine Tasks zerlegen: nur ein Unterverzeichnis öffnen, MCP aus, mit codex exec fertig werden und gehen. Lange interaktive Sessions sind der natürliche Feind von 8 GB — je länger die Session, desto eher bleiben interner State und Kindprozesse liegen.

Welche Projekte auf 16 GB laufen

16 GB ist unsere Alltags-Default-Stufe für Web. Ein P2 — mittleres Frontend / Full-Stack plus Unit-Tests — kämpft hier nicht mehr um Swap-Zeit. Die Einstiegs-SKU der Nuvcloud-Cloud-Mac-minis ist ebenfalls 16 GB Unified Memory und liegt auf dieser Stufe: Reicht das Ultrabook nicht, ziehen Sie Codex-Session plus Toolchain auf einen dedizierten Knoten, statt 8 GB Notebook zu quälen.

Wo 16 GB sich wohl anfühlt

• mittleres Next.js / Nuxt / Rails / Django, Unit-Tests + lokaler Dev-Server;
• ein Datenbank-Container oder ein sehr schlankes docker-compose (nicht noch Redis + Elasticsearch + Browser oben drauf);
• VS Code / Zed + Codex im Terminal, 2–3 GB fürs System übrig;
• mittlere Python-Datenskripte (pandas, mittlere Tabellen, kein volles lokales LLM);
• kurz ein MCP (etwa Git oder Doku-Suche), danach sofort wieder aus.

Was 16 GB schafft — wenn Sie Regeln einhalten

P3 „kommt durch“ auf 16 GB, wenn Sie gelben Speicherdruck akzeptieren und keinen zweiten Container-Stack parallel fahren. Kleine iOS-Änderungen mit einem einzelnen xcodebuild-Target pressen sich manchmal durch; Simulator an, und Sie sind zurück bei „Swap + Freeze“. Playwright-MCP in kurzen Sessions (zehn bis fünfzehn Minuten) geht; Ctrl+Z auf die Session oder eine Kette von spawn_agent hinterlässt Waisen-Node-Prozesse, die 16 GB auffressen — in der Community auf 16 GB + 8 GB zram bereits als „ganze Maschine tot“ reproduziert.

Ein Satz: 16 GB passt zu „ein Hauptprojekt + eine Testsuite“; nicht zu „Hauptprojekt + Container-Vollsortiment + Browser-Agent + IDE-Index“.

Projekte, für die 32 GB Pflicht sind

32 GB ist keine Protz-Config, sondern die Eintrittskarte für die folgenden Projekte. Gemeinsam ist ihnen: Codex ist nur ein schmaler Posten, Compiler und Runtime sind der Brocken.

• Monolith / Multi-Package-Repo: ein npm test oder turbo run test zieht eine Reihe Node-Worker;
• iOS- / macOS-Projekte: xcodebuild, DerivedData, Code-Index — Peaks locker im zweistelligen GB-Bereich; UI gegen Simulator halten Sie besser mit 32 GB;
• Codex + mehrere Docker-Services: App, Datenbank, Queue gleichzeitig, Agent ändert Migrationen und startet den Stack neu;
• Browser-MCP / E2E: Playwright oder Chrome DevTools kopiert noch einen Prozessbaum; kurze Sessions tragen 32 GB, lange Sessions brauchen trotzdem manuelles Aufräumen;
• parallele Sessions: zwei Codex auf zwei Repos, oder eine interaktive Session plus ein codex exec-Batch.

32 GB stoppt bekanntes unbegrenztes Wachstum nicht. Hat das Repo selbst schon einen Workspace im 1-GB-Bereich, setzen Sie Codex ein Speicherlimit — lieber ein fehlgeschlagener Task als ein eingefrorener Desktop. Unter Linux so einwickeln:

# 32-GB-Maschine: 20G für Codex, Rest für System / IDE / Container
systemd-run --user --scope \
  --same-dir \
  --unit="codex-$(date +%H%M%S)" \
  -p MemoryMax=20G \
  -p MemorySwapMax=2G \
  -p CPUQuota=300% \
  codex

macOS hat kein gleich bequemes User-cgroup. Realistischer: schwere Jobs auf einen dedizierten Cloud-Mac, lokal nur Editor und Browser. Nuvcloud verkauft derzeit Bare-Metal-Stufen 16 GB und 24 GB — 24 GB deckt die meisten P3; soll P4 den Simulator mitnehmen, gehören Xcode und Codex auf die dauerhaft laufende Remote-Maschine, nicht auf ein 16-GB-Notebook, das beides jongliert. Den Agent-Knoten getrennt zu rechnen hilft auch beim Abgleich mit den Hosted- vs. Self-hosted-Kosten von GitHub-Actions-macOS-Runnern: CI auf Einweg-Runnern, interaktives Codex auf einem Mac mini nach Tag — zwei Bücher, nicht ein überladenes Notebook.

Stufe nach Repo und Toolchain wählen

Fragen Sie nicht zuerst „16 oder 32 kaufen“, sondern was das Repo aufweckt. Die Tabelle ist in Entscheidungsreihenfolge: erste zutreffende Zeile, dann Stopp.

Eine oft übersehene Variable: Disk und File-Deskriptoren. Bei MCP-Leaks kann das macOS-Default-Softlimit von 256 Deskriptoren zuerst Too many open files werfen — wirkt wie „Codex ist kaputt“, sind aber Pipes und Waisen, die das Kontingent auffressen. Bevor Sie RAM diskutieren: ulimit -n und in ps zählen, wie viele npx / mcp noch leben.

Überlebenskonfiguration auf knappen Maschinen

Wenn Sie vorerst auf 8 GB oder einem knappen 16 GB bleiben, ändern Sie Verhalten vor dem Upgrade. Die Liste ist nach Nutzen zu Schmerz sortiert.

1. Standard: null MCP. Browser- oder Xcode-Tools nur anmachen, wenn nötig, danach aus ~/.codex/config.toml wieder entfernen. xcodebuildmcp und Playwright gehören nicht in die globale Default-Config.
2. Interaktive Sessions kurz, Batches mit codex exec. Ein Einmal-Patch braucht kein TUI; Batch spart eine Schicht UI-State.
3. Codex nicht mit Ctrl+Z suspendieren. MCP-Kinder laufen danach oft weiter. Beenden, oder in tmux detach.
4. Arbeitsverzeichnis verkleinern. Im Subpackage starten, nicht an der Wurzel eines 40.000-Dateien-Monorepos; dist, coverage, .next aus dem Lesebereich halten.
5. Tool-Output begrenzen. In der Praxis setzt man tool_output_token_limit, damit ein volles Log nicht Kontext und lokalen Puffer zusammen sprengt.
6. Prozesse ansehen, nicht nur „ist langsam“. Stehen in ps aux | egrep 'codex|npx|mcp|node' ein Dutzend doppelter MCP-Bäume, zuerst Waisen killen, dann weiterarbeiten.

ps aux | egrep 'codex|npx|playwright|mcp-server|xcodebuildmcp' | grep -v egrep
# Nach der Session: wenn sie noch laufen, zuerst Waisen killen, dann die nächste Runde
# Unter macOS in der Aktivitätsanzeige nach „Speicher“ sortieren und node plus Codex beobachten

Das macht aus P4 kein 8-GB-Projekt. Es macht aus P1 / P2 „startet“ ein „wird fertig“. Mehr RAM löst Peaks; Config löst Leaks und Parallelität.

Wann Codex auf einen Cloud-Mac gehört

Zwei beliebige Punkte zutreffend — dann gehören Codex und die schwere Toolchain vom Notebook runter:

• lokal nur 8 GB oder 16 GB, der Task ist aber schon P3 / P4 / P5;
• dieselbe Session soll im Zug, auf einem Windows-Host oder einem geteilten Rechner weiterlaufen;
• die Xcode-Version muss vom Alltag auf dem Laptop isoliert sein (SDK-Wochen, Beta-Wochen besonders);
• jemand im Team hat MCP global als Default gesetzt, und die Shared Machine läuft nachmittags voll mit Waisen.

Der Cloud-Mac-mini ist nicht „teureres Codex“. Er ist dedizierter Unified Memory, native Unix-Toolchain, schmutzige Umgebung, die Sie nach Tag wegwerfen. Das 8-GB-Notebook schreibt weiter Mails und liest Docs; der 16-GB- oder 24-GB-Remote-Knoten fährt Codex, Tests und Xcode. Apple Silicon im Idle ist sparsam genug für Nachtjobs; SSH / VNC ist ehrlicher als auf einem schon pagenden Laptop den Spinner anzustarren.