Test RAM Codex CLI :
quels projets finissent en 8, 16 et 32 Go ?

Au 9 septembre 2026, le guide d’installation officiel de Codex écrit toujours : macOS 12+ / Ubuntu 20.04+ (Windows via WSL2), mémoire 4 Go minimum, 8 Go recommandés. Le CLI est un binaire Rust natif ; au repos, il reste souvent à quelques centaines de Mo. Comme Claude Code ou Cursor, ce n’est pas le processus agent qui coûte, c’est la toolchain locale qu’il réveille dès qu’il agit. Pour les paliers d’achat d’un autre agent, voir notre test Claude Code 16 Go / 24 Go / 64 Go ; pour un service de revue de PR auto-hébergé, c’est un autre article : OpenCode Review 4 Go / 8 Go / 16 Go. Ici, une seule question : sur 8 / 16 / 32 Go, quelles classes de projets Codex CLI mène vraiment au bout.

Les 4 Go / 8 Go officiels ne garantissent que le démarrage

Lire « 8 Go recommandés » comme « 8 Go écrivent n’importe quel projet » est le contresens le plus fréquent. Le tableau officiel répond à : l’OS + les dépendances Node/runtime + le processus Codex survivent-ils ? Il ne couvre pas ce travail réel :

• le dépôt contient node_modules, DerivedData, .next ou des dizaines de milliers de sources — l’agent lit par chemin et cherche par outil ;
• vous lui demandez de « réparer ce CI rouge », il lance npm test, pytest ou xcodebuild ;
• Playwright / Chrome DevTools / XcodeBuild MCP sont actifs, et chaque session peut encore tirer un arbre Node ;
• navigateur, IDE et dev server local tournent en parallèle — rien de tout ça n’est dans « 4 Go minimum ».

L’inférence est côté OpenAI : un plus gros GPU local n’aide pas. La RAM décide si la toolchain a un endroit où se tenir. D’où le ressenti inverse de la même phrase officielle sur un dépôt de scripts et sur un monolithe iOS.

La facture mémoire : CLI, index, sous-processus, MCP

La mémoire résidente d’une session interactive, ce sont quatre factures. Séparées, vous savez quoi couper — au lieu d’ajouter de la RAM tout de suite.

La communauté envoie déjà des signaux clairs : sur un dépôt local d’environ 1.2 Go, le RSS anonyme du runtime natif Codex est monté à 18 Go voire 29 Go jusqu’au kill par cgroup (openai/codex#21233). L’autre famille de problèmes, c’est le cycle de vie MCP : session suspendue ou sous-agent terminé, mais npx / Playwright / xcodebuildmcp restent — une machine 16 Go se fait tirer dans le swap par des orphelins. Donc « 32 Go = toujours sûr » est faux aussi : vous n’achetez qu’un plus long délai de réaction.

C’est aussi ce qui distingue ce texte des articles « quelle machine acheter » : on comptabilise par toolchain de projet, pas par nom de puce.

Méthode : trois plafonds, six projets

Le même Codex CLI (login ChatGPT, modèle de code par défaut), six tâches fixes, plafonnées à 8 / 16 / 32 GiB de mémoire disponible. Côté Linux, systemd-run --scope -p MemoryMax= ; côté macOS, pression mémoire et swap dans le Moniteur d’activité. Quatre indicateurs : RSS pic de Codex + sous-processus, apparition d’un swap agressif, tâche terminée ou non, temps mur.

Les six projets sont du travail qu’un développeur donne vraiment à un agent — pas un Hello World :

1. P0 Session vide : démarrage à froid de codex, une question sur la structure du dépôt, aucun test.
2. P1 Petit CLI Python : environ 180 fichiers sources, corriger un bug de parsing, pytest -q.
3. P2 Next.js moyen : environ 800 fichiers sources, ajouter une route API, npm test (sans navigateur E2E).
4. P3 P2 + Docker Compose : Postgres + conteneur applicatif ; Codex modifie une migration et relance la stack.
5. P4 App iOS : projet UIKit moyen, modifier un écran et lancer xcodebuild (sans la suite complète de simulateurs).
6. P5 P2 + Playwright MCP : MCP navigateur ouvert, ajuster un composant face à la page.

Les chiffres sont des intervalles de pic, pas une calibration d’instrument. L’environnement garde l’OS et un terminal léger ; pas 40 onglets Chrome. Si Slack, Figma et trois dev servers tournent encore, remontez chaque palier d’un cran.

Matrice : succès, blocage, kill

Deux lectures de ce tableau. D’abord, P2 est déjà au plafond de 8 Go — pas parce que Codex a mangé 8 Go, mais parce que les processus de test node plus la lecture de fichiers vident le peu de RAM libre. Ensuite, P4 / P5 échouent rarement parce que « le modèle ne sait pas écrire du Swift / cliquer la page ». Le compilateur et le navigateur étouffent la machine avant le dernier pas de l’agent.

Ce que 8 Go peut vraiment finir

8 Go est le palier « recommandé » officiel, et la réalité de beaucoup d’ultrabooks, VPS d’entrée et vieux Mac à mémoire unifiée. Les projets qui y aboutissent ont un profil net : peu de sources, pas de conteneur, pas de simulateur d’IDE, tests dans le processus.

Projets à confier à 8 Go

• scripts, crawlers, petits outils, refactors d’un fichier ;
• texte et config d’un site de documentation (Astro / VitePress / Docusaurus) ;
• petit Flask / Express / FastAPI, tests pytest ou quelques unitaires Node, sans navigateur ;
• correctifs ponctuels avec codex exec : lire quelques fichiers, modifier, sortir — pas de TUI interactif ;
• commentaires de revue, messages de commit, journaux d’erreur traduits en brouillon de patch.

À abandonner tout de suite sur 8 Go

• tout full-stack qui exige Docker Desktop / Compose ;
• Xcode, simulateur iOS, émulateur Android ;
• Playwright, Cypress, Chrome DevTools MCP ;
• suite de tests complète d’un gros monorepo pnpm / npm ;
• « VS Code plus une dizaine d’onglets, et Codex modifie le dépôt » — le système pagine d’abord. Vous croyez l’agent lent ; c’est le disque qui fait office de RAM.

Le meilleur usage de 8 Go n’est pas « tenir le gros dépôt », c’est découper le gros dépôt en petites tâches : n’ouvrir qu’un sous-répertoire, MCP éteint, finir avec codex exec et partir. Les longues sessions interactives sont l’ennemi naturel de 8 Go — plus la session dure, plus l’état interne et les sous-processus restent.

Ce que 16 Go peut vraiment finir

16 Go est notre palier Web quotidien par défaut. Un P2 — frontend / full-stack moyen + unitaires — n’y dispute plus son temps au swap. L’entrée de gamme des Mac mini cloud Nuvcloud est aussi 16 Go de mémoire unifiée, alignée sur ce palier : si l’ultrabook ne suffit plus, déplacez la session Codex et sa toolchain sur un nœud dédié plutôt que de forcer un portable 8 Go.

Là où 16 Go est confortable

• Next.js / Nuxt / Rails / Django moyen, unitaires + dev server local ;
• un conteneur base de données, ou un docker-compose très mince (pas Redis + Elasticsearch + navigateur en plus) ;
• VS Code / Zed + Codex en terminal, 2–3 Go laissés au système ;
• scripts data Python moyens (pandas, tables moyennes, pas de LLM local complet) ;
• un MCP ouvert brièvement (Git ou recherche doc), puis coupé tout de suite.

Ce que 16 Go tient — avec des règles

P3 « termine » sur 16 Go si vous acceptez la pression mémoire jaune et ne lancez pas une deuxième stack de conteneurs en parallèle. Un petit changement iOS avec un seul target xcodebuild passe parfois en force ; simulateur allumé, vous revenez dans « swap + freeze ». Playwright MCP tient une session courte (dix à quinze minutes) ; Ctrl+Z sur la session ou une série de spawn_agent laisse des Node orphelins qui transpercent 16 Go — déjà reproduit sur 16 Go + 8 Go de zram comme machine entière inutilisable.

Une phrase : 16 Go va à « un projet principal + une suite de tests » ; pas à « projet principal + famille complète de conteneurs + agent navigateur + index IDE ».

Les projets qui justifient 32 Go

32 Go n’est pas une config de prestige : c’est le ticket d’entrée des projets ci-dessous. Leur point commun : Codex n’est qu’une fine ligne de la facture ; le compilateur et le runtime sont le gros poste.

• Monolithe / dépôt multi-packages : un npm test ou turbo run test lève une rangée de workers Node ;
• Projets iOS / macOS : xcodebuild, DerivedData, index — pics facilement à plus de 10 Go ; pour tenir l’UI face au simulateur, prévoyez 32 Go ;
• Codex + plusieurs services Docker : app, base, file, et l’agent qui change une migration puis relance la stack ;
• MCP navigateur / E2E : Playwright ou Chrome DevTools recopie encore un arbre de processus ; 32 Go tiennent une session courte, une session longue demande encore un ménage manuel ;
• Sessions en parallèle : deux Codex sur deux dépôts, ou une session interactive plus un batch codex exec.

32 Go n’arrête pas une croissance non bornée déjà connue. Si le workspace du dépôt est déjà de l’ordre de 1 Go, posez un plafond mémoire à Codex : mieux vaut une tâche en échec qu’un bureau gelé. Sous Linux, encapsuler ainsi :

# Machine 32 Go : 20G pour Codex, le reste au système / IDE / conteneurs
systemd-run --user --scope \
  --same-dir \
  --unit="codex-$(date +%H%M%S)" \
  -p MemoryMax=20G \
  -p MemorySwapMax=2G \
  -p CPUQuota=300% \
  codex

macOS n’a pas d’équivalent cgroup utilisateur aussi commode. Le plus réaliste : mettre le lourd sur un Mac cloud dédié, garder en local l’éditeur et le navigateur. Nuvcloud propose aujourd’hui du bare metal 16 Go et 24 Go — 24 Go couvre la plupart des P3 ; si P4 doit ouvrir le simulateur, Xcode et Codex vont sur la machine distante allumée en permanence, pas sur un portable 16 Go qui jongle les deux. Facturer le nœud agent à part aide aussi à comparer aux coûts hosted vs self-hosted des runners macOS GitHub Actions : CI sur runner jetable, Codex interactif sur Mac mini à la journée — deux comptes, pas un portable saturé.

Choisir le palier selon le dépôt et la toolchain

Ne commencez pas par « 16 ou 32 à acheter ». Demandez ce que le dépôt réveille. Le tableau est dans l’ordre de décision : première ligne vraie, puis stop.

Une variable trop souvent oubliée : le disque et les descripteurs de fichiers. Quand un MCP fuit, la limite souple macOS de 256 descripteurs peut d’abord lever Too many open files — ça ressemble à « Codex est cassé », ce sont les pipes et orphelins qui ont mangé le quota. Avant de parler RAM, regardez ulimit -n et, dans ps, combien de npx / mcp vivent encore.

Config de survie sur petite mémoire

Si vous restez pour l’instant sur 8 Go ou un 16 Go juste, changez le comportement avant de parler upgrade. La liste est triée par gain / douleur.

1. Zéro MCP par défaut. N’allumez navigateur ou outils Xcode qu’au besoin, puis retirez-les de ~/.codex/config.toml. xcodebuildmcp et Playwright n’ont rien à faire dans la config globale.
2. Sessions interactives courtes, lots avec codex exec. Un correctif unique n’a pas besoin du TUI ; le batch économise une couche d’état d’interface.
3. Ne suspendez pas Codex avec Ctrl+Z. Les enfants MCP survivent souvent. Quittez, ou detachez dans tmux.
4. Réduire le répertoire de travail. Démarrer dans le sous-paquet, pas à la racine d’un monorepo de 40 000 fichiers ; tenir dist, coverage, .next hors de la lecture.
5. Limiter la sortie des outils. En pratique on plafonne tool_output_token_limit pour qu’un journal entier n’explose pas le contexte et le tampon local ensemble.
6. Regarder les processus, pas seulement « c’est lent ». Si ps aux | egrep 'codex|npx|mcp|node' montre une dizaine d’arbres MCP en double, tuez les orphelins avant de continuer.

ps aux | egrep 'codex|npx|playwright|mcp-server|xcodebuildmcp' | grep -v egrep
# Après la session : s’ils sont encore là, ramasser avant le tour suivant
# Sous macOS, trier le Moniteur d’activité par « Mémoire » et surveiller node et Codex

Ça ne transforme pas P4 en projet ami de 8 Go. Ça fait passer P1 / P2 de « ça démarre » à « ça se termine ». Plus de RAM règle le pic ; la config règle les fuites et la concurrence.

Quand envoyer Codex sur un Mac cloud

Deux critères vrais parmi ceux-ci — alors Codex et la toolchain lourde quittent le portable :

• 8 Go ou 16 Go en local, mais la tâche est déjà P3 / P4 / P5 ;
• vous devez reprendre la même session dans le train, sur un hôte Windows ou un poste partagé ;
• la version Xcode doit rester isolée du quotidien du portable (semaines SDK et beta surtout) ;
• quelqu’un de l’équipe a mis les MCP en défaut global, et la machine partagée se remplit d’orphelins l’après-midi.

Le Mac mini cloud n’est pas « un Codex plus cher ». C’est de la mémoire unifiée dédiée, une toolchain Unix native, un environnement sale que vous jetez à la journée. Le portable 8 Go continue le mail et la doc ; le nœud distant 16 Go ou 24 Go fait tourner Codex, les tests et Xcode. Apple Silicon au repos tient une nuit de jobs ; SSH / VNC est plus honnête que de regarder tourner un portable déjà en pagination.