Тест RAM для Codex CLI:
какие проекты доходят до конца на 8, 16 и 32 ГБ

На 9 сентября 2026 в официальной инструкции по установке Codex по-прежнему написано: macOS 12+ / Ubuntu 20.04+ (Windows через WSL2), память минимум 4 ГБ, рекомендовано 8 ГБ. Сам CLI — нативный бинарник на Rust; в простое часто занимает лишь несколько сотен МБ. Как у Claude Code и Cursor, дорого не «процесс агента», а локальный toolchain, который он будит, едва начинает работать. Если вам нужны ступени покупки другого агента — наш замер Claude Code 16 ГБ / 24 ГБ / 64 ГБ; если нужен свой сервис ревью PR — это другая статья: OpenCode Review 4 ГБ / 8 ГБ / 16 ГБ. Здесь один вопрос: какие классы проектов Codex CLI реально доводит на 8 / 16 / 32 ГБ.

Официальные 4 ГБ / 8 ГБ гарантируют только запуск

Читать «рекомендовано 8 ГБ» как «на 8 ГБ пишется любой проект» — самая частая ошибка. Официальная таблица отвечает: выживут ли ОС + зависимости Node/рантайма + процесс Codex. Она не покрывает такую работу:

• в репозитории лежат node_modules, DerivedData, .next или десятки тысяч исходников — агент читает по путям и ищет инструментами;
• вы просите «починить упавший CI» — он запускает npm test, pytest или xcodebuild;
• включены Playwright / Chrome DevTools / XcodeBuild MCP, и каждая сессия может поднять ещё одно дерево Node;
• рядом крутятся браузер, IDE и локальный dev server — ничего из этого нет в «минимум 4 ГБ».

Инференс идёт у OpenAI, более мощный GPU локально не поможет. Локальная память решает, есть ли toolchain где стоять. Поэтому одна и та же официальная строка на скриптовом репозитории и на iOS-монолите ощущается противоположно.

Счёт за память: CLI, индекс, дочерние процессы, MCP

Резидентная память интерактивной сессии — четыре статьи счёта. Если смотреть их по отдельности, понятно, что резать, а не сразу докупать RAM.

В сообществе уже достаточно громких сигналов: на локальном репозитории около 1.2 ГБ анонимный RSS нативного рантайма Codex вырастал до 18 ГБ и даже 29 ГБ, пока cgroup его не убил (openai/codex#21233). Второй класс проблем — жизненный цикл MCP: сессия зависла или субагент закончил, а npx / Playwright / xcodebuildmcp остаются — машину на 16 ГБ сироты затаскивают в своп. Поэтому «32 ГБ всегда безопасно» тоже неверно: вы покупаете только больше времени на реакцию.

Этим текст отличается от статей «какой компьютер купить»: мы считаем по toolchain проекта, а не по кодовому имени чипа.

Как мерили: три потолка, шесть проектов

Один и тот же Codex CLI (вход через ChatGPT, модель кодирования по умолчанию), шесть фиксированных задач, потолок 8 / 16 / 32 GiB доступной памяти. На Linux — systemd-run --scope -p MemoryMax=; на macOS — давление памяти и своп в «Мониторинге системы». Четыре метрики: пиковый RSS Codex + дочерних процессов, начался ли жёсткий своп, доведена ли задача, wall-clock время.

Шесть проектов — работа, которую разработчик реально отдаёт агенту, не Hello World:

1. P0 Пустая сессия: холодный старт codex, вопрос про структуру репозитория, без тестов.
2. P1 Небольшой Python CLI: около 180 исходников, починить баг парсера, pytest -q.
3. P2 Средний Next.js: около 800 исходников, добавить API-маршрут, npm test (без E2E-браузера).
4. P3 P2 + Docker Compose: Postgres + контейнер приложения; Codex меняет миграцию и перезапускает стек.
5. P4 iOS-приложение: средний UIKit-проект, правка интерфейса и xcodebuild (без полного набора симуляторов).
6. P5 P2 + Playwright MCP: браузерный MCP включён, компонент правят по открытой странице.

Цифры — интервалы пика, не калибровка прибора. В окружении остаются ОС и тонкий терминал; не 40 вкладок Chrome. Если у вас ещё Slack, Figma и три dev server, каждую ступень в таблице оценивайте на одну выше.

Сводка: успех, зависание, kill

Из таблицы держите две вещи. Первое: P2 уже у потолка 8 ГБ — не потому что Codex съел 8 ГБ, а потому что тестовые процессы node плюс чтение файлов доедают остаток свободной памяти. Второе: P4 / P5 почти никогда не валятся из‑за того, что «модель не умеет Swift / не кликает страницу». Компилятор и браузер душат машину раньше, чем агент доходит до последнего шага.

Какие проекты тянет 8 ГБ

8 ГБ — официальная «рекомендация» и реальность многих ультрабуков, входных VPS и старых Mac с унифицированной памятью. Проекты, которые там доходят до конца, узнаются сразу: мало исходников, нет контейнеров, нет симулятора IDE, тесты живут внутри процесса.

Что можно отдать 8 ГБ

• скрипты, краулеры, мелкие утилиты, рефакторинг одного файла;
• правки текста и конфигов документационных сайтов (Astro / VitePress / Docusaurus);
• небольшой Flask / Express / FastAPI, тесты через pytest или несколько Node-юнитов, без браузера;
• разовые патчи через codex exec: прочитать несколько файлов, поменять, выйти — без интерактивного TUI;
• комментарии к ревью, сообщения коммитов, перевод логов ошибок в черновик патча.

Что на 8 ГБ сразу бросать

• любой fullstack, которому нужен Docker Desktop / Compose;
• Xcode, симулятор iOS, эмулятор Android;
• Playwright, Cypress, Chrome DevTools MCP;
• полный прогон тестов большого pnpm- / npm-монорепозитория;
• «VS Code плюс десяток вкладок, а Codex правит репозиторий» — система сначала уходит в подкачку. Вам кажется, агент тупит; на самом деле диск работает вместо RAM.

Самое эффективное применение 8 ГБ — не «терпеть большой репозиторий», а резать большой репозиторий на мелкие задачи: открывать только подкаталог, MCP выкл., закрывать работу через codex exec и уходить. Длинные интерактивные сессии — естественный враг 8 ГБ: чем дольше сессия, тем охотнее остаются внутреннее состояние и дочерние процессы.

Какие проекты тянет 16 ГБ

16 ГБ — наша повседневная Web-ступень по умолчанию. P2 — средний фронт / fullstack плюс юнит-тесты — здесь уже не дерётся со свопом за время. Входной SKU облачных Mac mini у Nuvcloud тоже 16 ГБ унифицированной памяти и совпадает с этой ступенью: ультрабука мало — переносите сессию Codex вместе с toolchain на выделенный узел, а не мучайте ноутбук на 8 ГБ.

Где 16 ГБ комфортны

• средний Next.js / Nuxt / Rails / Django, юнит-тесты + локальный dev server;
• один контейнер БД или очень тонкий docker-compose (без Redis + Elasticsearch + браузера сверху);
• VS Code / Zed + Codex в терминале, 2–3 ГБ оставлены системе;
• средние Python-скрипты по данным (pandas, средние таблицы, без полного локального LLM);
• ненадолго один MCP (Git или поиск по доке), сразу после — выключить.

Что 16 ГБ вывезут — если соблюдать правила

P3 на 16 ГБ «доводит», если вы готовы к жёлтому давлению памяти и не поднимаете второй стек контейнеров параллельно. Мелкая правка iOS с одним target xcodebuild иногда протискивается; симулятор включили — снова «своп + зависание». Короткий сеанс Playwright MCP (десять–пятнадцать минут) можно; Ctrl+Z на сессию или цепочка spawn_agent оставляют сирот Node, которые пробивают 16 ГБ — в сообществе на 16 ГБ + 8 ГБ zram уже воспроизводили «вся машина мертва».

Одной фразой: 16 ГБ — это «один главный проект + один набор тестов»; не «главный проект + полный набор контейнеров + браузерный агент + индекс IDE».

Для каких проектов нужны 32 ГБ

32 ГБ — не понты, а входной билет для проектов ниже. Общее у них: Codex — узкая строка счёта, компилятор и рантайм — основная сумма.

• Монолит / мультипакетный репозиторий: один npm test или turbo run test поднимает линейку Node-воркеров;
• Проекты iOS / macOS: xcodebuild, DerivedData, индекс кода — пики спокойно уходят за десяток ГБ; сверка UI с симулятором планируйте на 32 ГБ;
• Codex + несколько Docker-сервисов: приложение, БД, очередь одновременно, агент меняет миграции и перезапускает стек;
• Браузерный MCP / E2E: Playwright или Chrome DevTools копируют ещё одно дерево процессов; короткие сессии 32 ГБ тянут, длинные всё равно требуют ручной зачистки;
• Параллельные сессии: два Codex на два репозитория или интерактив плюс пакетный codex exec.

32 ГБ не останавливают уже известный безграничный рост. Если у самого репозитория рабочая область порядка 1 ГБ, поставьте Codex потолок памяти: лучше упавшая задача, чем замёрзший рабочий стол. На Linux оберните так:

# На машине 32 ГБ: 20G Codex, остальное системе / IDE / контейнерам
systemd-run --user --scope \
  --same-dir \
  --unit="codex-$(date +%H%M%S)" \
  -p MemoryMax=20G \
  -p MemorySwapMax=2G \
  -p CPUQuota=300% \
  codex

У macOS нет столь же удобного пользовательского cgroup. Реалистичнее: тяжёлую работу — на выделенный облачный Mac, локально оставить редактор и браузер. Сейчас у Nuvcloud наружу идут bare-metal ступени 16 ГБ и 24 ГБ — 24 ГБ закрывают большинство P3; если P4 должен держать симулятор, Xcode и Codex живут на постоянно включённой удалённой машине, а не на ноутбуке 16 ГБ, который жонглирует обоими. Отдельный счёт на узел агента удобно сверять со стоимостью hosted и своих macOS-раннеров GitHub Actions: CI на одноразовых runner, интерактивный Codex на Mac mini по дням — две книги, не один забитый ноутбук.

Выбор ступени по репозиторию и toolchain

Не начинайте с «купить 16 или 32». Спросите, что разбудит репозиторий. Таблица в порядке решения: первая подходящая строка — и стоп.

Переменная, которую часто забывают: диск и файловые дескрипторы. При утечке MCP мягкий лимит macOS в 256 дескрипторов может первым выдать Too many open files — выглядит как «сломался Codex», на деле пайпы и сироты съели квоту. Прежде чем спорить про RAM, смотрите ulimit -n и в ps — сколько ещё живых npx / mcp.

Конфиг выживания на малой памяти

Если пока только 8 ГБ или тесные 16 ГБ, сначала меняйте поведение, потом апгрейд. Список отсортирован по «польза / боль».

1. По умолчанию ноль MCP. Браузер или инструменты Xcode — только когда нужны, потом убрать из ~/.codex/config.toml. xcodebuildmcp и Playwright не должны жить в глобальном дефолте.
2. Интерактив коротко, пакеты через codex exec. Разовому патчу не нужен TUI; пакет экономит слой состояния интерфейса.
3. Не вешайте Codex через Ctrl+Z. Дочерние MCP после этого часто продолжают жить. Выходите или detach в tmux.
4. Сузить рабочий каталог. Стартовать в подпакете, не в корне монорепозитория на 40 000 файлов; держать dist, coverage, .next вне чтения.
5. Ограничить вывод инструментов. На практике ставят потолок tool_output_token_limit, чтобы полный лог не раздул сразу контекст и локальный буфер.
6. Смотреть процессы, а не только «тормозит». Если в ps aux | egrep 'codex|npx|mcp|node' десяток одинаковых деревьев MCP — сначала убить сирот, потом продолжать.

ps aux | egrep 'codex|npx|playwright|mcp-server|xcodebuildmcp' | grep -v egrep
# После сессии: если ещё живы — сначала зачистка, потом следующий круг
# На macOS в «Мониторинге системы» сортируйте по «Память» и следите за node и Codex

Это не сделает P4 проектом для 8 ГБ. Это превратит P1 / P2 из «запускается» в «доводится». Апгрейд памяти лечит пик; конфиг лечит утечки и параллельность.

Когда выносить Codex на облачный Mac

Любые два пункта — и Codex вместе с тяжёлым toolchain пора снимать с ноутбука:

• локально только 8 ГБ или 16 ГБ, а задача уже P3 / P4 / P5;
• ту же сессию нужно продолжить в дороге, на Windows-хосте или общем компьютере;
• версия Xcode должна быть изолирована от повседневной разработки на ноутбуке (особенно недели SDK и беты);
• кто-то в команде прописал MCP глобальным дефолтом, и общая машина к обеду забита сиротами.

Облачный Mac mini — это не «более дорогой Codex». Это выделенная унифицированная память, нативный Unix-toolchain и грязная среда, которую можно выбросить по дням. Ноутбук на 8 ГБ пишет почту и читает документы; удалённый узел на 16 ГБ или 24 ГБ гоняет Codex, тесты и Xcode. Apple Silicon в простое тянет ночные задачи; SSH / VNC честнее, чем смотреть на крутилку ноутбука, который уже в подкачке.