Масштабировать Codex CLI — не значит покупать одну огромную машину. Это значит держать каждого агента скучным, изолированным и легко останавливаемым, если он уходит не туда.
Мы обычно видим один и тот же сбой: одна удачная сессия Codex превращается в три, потом в шесть, и внезапно один VPS заполнен полуготовыми ветками, спрятанными tmux-панелями и логами, которые никто не читает. Исправляет это форма масштабирования, а не героизм.
Начните с единицы масштаба
Единицей масштаба должен быть один agent runner: один рабочий каталог, одна ветка, одна задача, один поток логов. Если два агента делят один checkout, они рано или поздно перезапишут друг друга или запустят тесты на смешанном состоянии.
# 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=90Это выглядит просто, потому что так и должно быть. До добавления VPS-мощности каждый runner должен отвечать на четыре вопроса:
- где checkout репозитория?
- какая ветка владеет этой задачей?
- куда идут логи?
- кто может его остановить?
Добавляйте параллельность постепенно
Самая дешёвая ошибка масштабирования — запускать слишком много агентов до понимания узкого места. Работа Codex CLI обычно упирается в один из четырёх лимитов: CPU во время тестов, RAM во время сборок, диск при установке зависимостей или человеческую способность ревьюить после завершения агентов.
| Stage | Good default | Watch first |
|---|---|---|
| Маленький репозиторий, лёгкие тесты | 1-2 агента на 2GB VPS | RAM и swap |
| Web app со сборками | 1 агент на 2GB VPS | время сборки |
| Тяжёлый monorepo | 1 агент на 4GB+ VPS | CPU и disk IO |
| Review-heavy workflow | меньше агентов, чем reviewers | очередь PR |
Office Claws показывает это в desktop app, а не заставляет помнить, какой терминал относится к какой задаче. Self-Hosted остаётся $4.99/месяц, если вы используете свой аккаунт DigitalOcean; Managed начинается с $14.99/месяц, если хотите, чтобы мы управляли VPS-частью.
Делите работу по риску
Не масштабируйтесь копированием одного prompt в пять агентов. Масштабируйтесь тем, что даёте каждому агенту отдельный профиль риска.
Рабочий шаблон:
- Safe lane — документация, тесты, небольшие refactorings, чистка зависимостей.
- Medium lane — feature branches с понятными acceptance criteria.
- Risky lane — migrations, auth, billing, deploy scripts, всё, что требует медленного review.
Поместите рискованную дорожку на самый тихий runner. Дайте ей более длинные timeouts, меньше concurrent-соседей и человеческий checkpoint до касания production-shaped кода.
Понимайте, когда нужен ещё один VPS
Более крупный VPS полезен до тех пор, пока не становится общим blast radius. Мы предпочитаем добавлять ещё один маленький runner, когда изоляция важнее чистой скорости.
Добавляйте capacity, когда:
- тесты стоят в очереди за несвязанной работой
- одна сломанная установка dependencies блокирует всех агентов
- логи слишком шумные для быстрого debug
- очередь review здорова, но агенты ждут
Не добавляйте capacity, если люди уже отстают с review. Больше агентов создадут только больше stale branches.
Что дальше
Если вы сравниваете agent frameworks, начните с нашего сравнения OpenClaw vs Codex. Если уже понятно, что работа имеет repo-shaped формат, путь Office Claws for OpenClaw users даёт persistent Codex runners без превращения масштабирования в археологию терминалов.
Наша рекомендация проста: масштабируйте Codex CLI по одному runner-у, держите каждую ветку изолированной и прекращайте добавлять агентов, как только review становится узким местом.